First pass at a BluePill Variant

The official STMicroelectronics Arduino core
Post Reply
User avatar
Rick Kimball
Posts: 894
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

First pass at a BluePill Variant

Post by Rick Kimball » Sat Sep 17, 2016 1:00 am

https://github.com/RickKimball/Arduino_Core_STM32F1

This needs much more work. What is working. You can blink an led and the clock is using the XTAL and runs @ 72MHz

BlinkWitoutDelay HAL style for a BluePill:

Code: Select all

/* Blink without Delay

 Turns on and off a light emitting diode (LED) connected to a digital
 pin, without using the delay() function.  This means that other code
 can run at the same time without being interrupted by the LED code.

 The circuit:
 * LED attached from pin 13 to ground.
 * Note: on most Arduinos, there is already an LED on the board
 that's attached to pin 13, so no hardware is needed for this example.

 created 2005
 by David A. Mellis
 modified 8 Feb 2010
 by Paul Stoffregen
 modified 11 Nov 2013
 by Scott Fitzgerald


 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay
 */

// constants won't change. Used here to set a pin number :
const int ledPin =  PC13;      // the number of the LED pin

// Variables will change :
int ledState = LOW;             // ledState used to set the LED

// Generally, you should use "unsigned long" for variables that hold time
// The value will quickly become too large for an int to store
unsigned long previousMillis = 0;        // will store last time LED was updated

// constants won't change
unsigned long interval = 100;           // interval at which to blink (milliseconds)
const long i_low = 100;
const long i_high = 900;

void setup() {
  // set the digital pin as output:
  pinMode(ledPin, OUTPUT);

  volatile unsigned long clockfcpu = SystemCoreClock;
  (void)clockfcpu;
  __asm__ volatile("nop");
  
  HAL_RCC_MCOConfig(RCC_MCO, RCC_MCO1SOURCE_SYSCLK, RCC_MCODIV_1); // PA8 shows clock
}

void loop() {
  // here is where you'd put code that needs to be running all the time.

  // check to see if it's time to blink the LED; that is, if the
  // difference between the current time and last time you blinked
  // the LED is bigger than the interval at which you want to
  // blink the LED.
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    // save the last time you blinked the LED
    previousMillis = currentMillis;

    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW) {
      ledState = HIGH;
      interval = i_high;
    } else {
      ledState = LOW;
      interval = i_low;
    }

    // set the LED with the ledState of the variable:
    digitalWrite(ledPin, ledState);
  }
}
-rick

User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sat Sep 17, 2016 1:24 am

Thanks Rick

I was just posting about the best way to refactor the libstm32f1 folder to accommodate this sort of change

I see you did it using #ifdefs

But I wonder if it would be better to split out the hw_config.c / .h (and the build gcc ) etc into separate folders

e.g. system/variants/bluepill would contain source and include and build_cc and (with the hw_config files in those source and include folders)

Or perhaps put the variants folder inside libstm32f1

I'm not desperately keen on ifdef's as I have seen it get very messy e.g. for some Arduino libraries, where they try to support multiple platforms

User avatar
Rick Kimball
Posts: 894
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: First pass at a BluePill Variant

Post by Rick Kimball » Sat Sep 17, 2016 2:51 pm

I'm really just trying stuff out here to get a feel for the code base. With the latest changes, I moved the hw_config.c to each of the variants folder. This seems to be a workable approach.
-rick

User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sat Sep 17, 2016 9:08 pm

Thanks Rick

User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sun Sep 18, 2016 12:29 am

Rick

I tried your repo and it works fine, just with moving hw_config.c

I tried to also move hw_config.h, but that didnt work as its by some of the files in libstm32f1

I think perhaps we should go with this method as a first pass and see whether there are any issues with it, e.g. whether there will be any changes which require hw_config.h to be changed.


I suspect we'll find out very soon, as adding USB Serial (USB CDCACM) is whats going to be needed next, and I'm sure it will highlight any issues ;-)

PS.

I also copied all the tools from the libmaple repo so that I could directly upload from the IDE via STLink, and they worked OK (not surprisingly)

I know the tools probably need some tidying up, but I may still just copy them all over into the STM core, so that at least we have something.

But I will see if I can discuss all these changes with Frederic on Monday, assuming he's not gone on paternity leave yet.

User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sun Sep 18, 2016 11:34 am

Rick

Actually

Can you create a PR and I'll pull your version. (I'm not sure if I can pull without a PR.. I think I can just pull and merge, but as you did all the work on this, it would be better if you were credited)

Once I've pulled your changes, I am going to push all of the existing tools and update the boards.txt to allow the various upload selections for the BluePill

Well, not the bootloader upload as we don't have USB Serial yet.

User avatar
Rick Kimball
Posts: 894
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: First pass at a BluePill Variant

Post by Rick Kimball » Sun Sep 18, 2016 3:00 pm

I created a pull request. Note: This really needs its pin map sorted. I didn't do that yet. The only pin I actually tested was the LED.

https://github.com/stm32duino/Arduino_C ... 2F1/pull/2


I cancelled this request until I fix up the pin map
-rick

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: First pass at a BluePill Variant

Post by Slammer » Sun Sep 18, 2016 5:47 pm

IMO, we can live without arduino pinmap for now... let it roll...

User avatar
Rick Kimball
Posts: 894
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: First pass at a BluePill Variant

Post by Rick Kimball » Sun Sep 18, 2016 7:52 pm

Slammer wrote:IMO, we can live without arduino pinmap for now... let it roll...
OK, so broken pin map submitted and pull request restarted:

https://github.com/stm32duino/Arduino_C ... 2F1/pull/3

-rick
-rick

User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sun Sep 18, 2016 8:51 pm

Whats wrong with the pin map ?

I tried the standard blink and it seemed to work using PC13 ( but I better double check)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest