First pass at a BluePill Variant

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

Re: First pass at a BluePill Variant

Post by Rick Kimball » Mon Sep 19, 2016 8:30 pm

I didn't see that post. Thanks.
-rick

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

Re: First pass at a BluePill Variant

Post by RogerClark » Tue Sep 20, 2016 8:28 am

Rick

I emailed Frederic and Laurent @ STM, and Frederic confirmed that they do not intend to make any changes to the cores which they have released.

And as you can see from Wi6Lab's post, they would only change the F1 code if a bug was reported.

But as I expect our changes will effect the files used to create the Nucleo, I doubt if any bugs could be referred back to them, unless it was part of the core and not the Variant.

Looking at the files, I think we're probably going to have to live with a certain amount of duplication, as the variants may need changes in virtually all the files in the libstm32f1/source folder

So we may have to put a variants folder inside libstm32f1 and copy the files into each variant.

Perhaps @Slammer and a few other people could look at it as well (perhaps @sheepdoll etc) as this will hopefully see any potential problems

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: First pass at a BluePill Variant

Post by danieleff » Tue Sep 20, 2016 9:01 am

What if you only put the periphery definition structs (g_analog_config, spi_init_info, g_uart_config, ...) to the variant file?

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

Re: First pass at a BluePill Variant

Post by RogerClark » Tue Sep 20, 2016 10:00 am

I took a quick look at analog.c and it does look as if its just that struct which contains the variant definitions, however in

HAL_DAC_MspInit()

There is this code

Code: Select all

  if(g_analog_config[g_current_init_id].port == GPIOA) {
    __GPIOA_CLK_ENABLE();
  } else if(g_analog_config[g_current_init_id].port == GPIOB){
    __GPIOB_CLK_ENABLE();
  } else if(g_analog_config[g_current_init_id].port == GPIOC){
    __GPIOC_CLK_ENABLE();
  }
Which implies that only ports A B and C are handled.

The same thing is in digital_io.c

Code: Select all

void digital_io_init(GPIO_TypeDef  *port, uint32_t pin, uint32_t mode, uint32_t pull)
{
  GPIO_InitTypeDef GPIO_InitStructure;

  if(port == GPIOA) {
    __GPIOA_CLK_ENABLE();
  } else if(port == GPIOB){
    __GPIOB_CLK_ENABLE();
  } else if(port == GPIOC){
    __GPIOC_CLK_ENABLE();
  }
And the V and Z series both have ports D,E,F and G

So all those core files will need to be updated to handle all ports.

Its not a huge change, but it would need to happen.

Interestingly, there are some ifdef's that enable code for some of the high density MCU's in the F1 series

Code: Select all

 #if defined (STM32F100xB) || defined (STM32F100xE) || defined (STM32F101xE) || defined (STM32F101xG) || defined (STM32F103xE) || defined (STM32F103xG) || defined (STM32F105xC) || defined (STM32F107xC)

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

Re: First pass at a BluePill Variant

Post by Rick Kimball » Tue Sep 20, 2016 1:05 pm

danieleff wrote:What if you only put the periphery definition structs (g_analog_config, spi_init_info, g_uart_config, ...) to the variant file?
This might be a better approach.
-rick

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

Re: First pass at a BluePill Variant

Post by Rick Kimball » Tue Sep 20, 2016 1:08 pm

RogerClark wrote:

Code: Select all

  if(g_analog_config[g_current_init_id].port == GPIOA) {
    __GPIOA_CLK_ENABLE();
  } else if(g_analog_config[g_current_init_id].port == GPIOB){
    __GPIOB_CLK_ENABLE();
  } else if(g_analog_config[g_current_init_id].port == GPIOC){
    __GPIOC_CLK_ENABLE();
  }
Maybe we should just dump all that conditional code and just enable all the clocks in hw_config_init(). It would be one initialization statement instead of 10s of lines of code doing it piecemeal.
-rick

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

Re: First pass at a BluePill Variant

Post by Slammer » Tue Sep 20, 2016 3:33 pm

Can be changed to something like that:

Code: Select all

 if(port == GPIOA) {
    __GPIOA_CLK_ENABLE();
  } else if(port == GPIOB){
    __GPIOB_CLK_ENABLE();
  } else if(port == GPIOC){
    __GPIOC_CLK_ENABLE();
  }
#ifdef GPIOD
  } else if(port == GPIOD){
    __GPIOD_CLK_ENABLE();
  }
#endif
#ifdef GPIOE
  } else if(port == GPIOE){
    __GPIOE_CLK_ENABLE();
  }
#endif
etc... for other ports (the same can be used for uart, adc, etc)
With this way it is possible to have a common library (in source level) for all F1 variants. If something is not so small and needs more code, then this must be moved to variant directory.
The same principle is used also in mbed widely.

rreignier
Posts: 17
Joined: Tue Feb 16, 2016 8:52 pm
Location: Toulon, France

Re: First pass at a BluePill Variant

Post by rreignier » Tue Sep 20, 2016 5:35 pm

Slammer wrote:Can be changed to something like that:

Code: Select all

 if(port == GPIOA) {
    __GPIOA_CLK_ENABLE();
  } else if(port == GPIOB){
    __GPIOB_CLK_ENABLE();
  } else if(port == GPIOC){
    __GPIOC_CLK_ENABLE();
  }
#ifdef GPIOD
  } else if(port == GPIOD){
    __GPIOD_CLK_ENABLE();
  }
#endif
#ifdef GPIOE
  } else if(port == GPIOE){
    __GPIOE_CLK_ENABLE();
  }
#endif
I personally like this approach. Ok it uses #ifdef statements but allows to keep the more code in the common section. So it will be easier to add a new MCU.

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

Re: First pass at a BluePill Variant

Post by RogerClark » Tue Sep 20, 2016 8:55 pm

I think libmaple has similar code, based on the MCU "density"

I guess we should start making these non invasive changes, as I dont think it will have any impact on the function of the Nucleo library

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

Re: First pass at a BluePill Variant

Post by RogerClark » Thu Sep 22, 2016 9:49 pm

Guys

Just to get the ball moving, I'm going to duplicate libstm32f1 to make libBluePill, I'll manually merge Rick's changes

I know this means there is a lot of duplication, but it means we are free to change any files without fear it will cause problems to the Nucleo.

We can always optimise the file duplication issue at a later date.

I also have to upload all the other tools e.g. stlink upload

I will post then its done (probably some time on Saturday,but I may have time to do it today)

Post Reply