Refactoring the STM core code

The official STMicroelectronics Arduino core
User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Refactoring the STM core code

Postby Slammer » Sat Sep 17, 2016 10:41 am

Maybe it is time to make some changes in the repository, I will have some time during the weekend. The first target is to support 2 variants (eg. Nucleo and BluePill) by separating the needed functions. As Rick is working in his own repository we need some way to work better, what is your suggestion?

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

Re: Refactoring the STM core code

Postby RogerClark » Sat Sep 17, 2016 11:02 am

Probably the best approach is to clone the repo, like Rick did.

I have the master version cloned to my local machine, but I may also fork the repo to my own personal github account (not the stm32duino account), and try some approaches

Ricks original approach was just to use #ifdef's to select different code in hw_config, but I think that will get very messy

We then briefly discussed using a weak definition of hw_config_init() but I have concerns about this.

So I was going to probably just add a variants folder somewhere in the system folder, e.g. inside libstm32f1, and separate the common code from the variant specific code

I think that solution would work OK, and I may have time tomorrow (sunday) to try it (I am UTC +10 so its already 21:00 local and Saturday is almost over)

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

Re: Refactoring the STM core code

Postby Slammer » Sat Sep 17, 2016 2:00 pm

OK Roger I will fork the F1 repo stm32duino for the beginning.... and we see, it is a bit tricky now.... but as I understand this repo must be connecting link of all of us.

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

Re: Refactoring the STM core code

Postby Rick Kimball » Sat Sep 17, 2016 6:21 pm

I was kind of surprised at the amount of ram used so I did a little digging.

$ arm-none-eabi-readelf -a BlinkNoDelay.elf >/tmp/a
$ sed -e 's/ \+/ /g' /tmp/a | sort -t' ' -n -k 3,3 | grep -v ' 08' | grep -v ' 0 '
Num: Value Size Type Bind Vis Ndx Name
455: 20000d0c 1 OBJECT GLOBAL DEFAULT 7 g_rx_data
438: 20000004 4 OBJECT GLOBAL DEFAULT 6 SystemCoreClock
468: 20000b58 4 OBJECT GLOBAL DEFAULT 7 ledState
504: 20000000 4 OBJECT GLOBAL DEFAULT 6 interval
537: 20000b54 4 OBJECT GLOBAL DEFAULT 7 previousMillis
86: 20000b98 4 OBJECT LOCAL DEFAULT 7 uwTick
423: 20000b70 20 OBJECT GLOBAL DEFAULT 7 Serial1
477: 20000b5c 20 OBJECT GLOBAL DEFAULT 7 Serial
566: 20000b84 20 OBJECT GLOBAL DEFAULT 7 Serial2
180: 20000b9c 128 OBJECT LOCAL DEFAULT 7 g_UartHandle
548: 20001080 140 OBJECT GLOBAL DEFAULT 7 g_anInputPinConfigured
226: 200001a8 208 OBJECT LOCAL DEFAULT 6 g_timer_config
228: 20000c1c 240 OBJECT LOCAL DEFAULT 7 g_TimerHandle
287: 20000278 320 OBJECT LOCAL DEFAULT 6 gpio_irq_conf
178: 20000008 416 OBJECT LOCAL DEFAULT 6 g_uart_config
391: 20000ec8 440 OBJECT GLOBAL DEFAULT 7 g_anOutputPinConfigured
409: 20000d10 440 OBJECT GLOBAL DEFAULT 7 g_digPinConfigured
526: 200003b8 1920 OBJECT GLOBAL DEFAULT 6 g_analog_config

1920, 440, 440 416 bytes in ram

seems like g_analog_config, g_digPinConfigured, g_anOutputPinConfigured might be some structures to take a look at to see if they can be optimized

Code: Select all

typedef struct {
  GPIO_TypeDef  *port;
  uint32_t pin;
  void (*alFunction)(void);
  ADC_TypeDef *adcInstance;
  ADC_ChannelConfTypeDef adcChannelConf;

#if defined (STM32F100xB) || defined (STM32F100xE) || defined (STM32F101xE) || defined (STM32F101xG) || defined (STM32F103xE) || defined (STM32F103xG) || defined (STM32F105xC) || defined (STM32F107xC)
  DAC_TypeDef *dacInstance;
  uint32_t dacChannel;
  DAC_ChannelConfTypeDef dacChannelConf;
#endif

  TIM_TypeDef *timInstance;
  uint32_t timChannel;
  uint32_t useNchannel;
  TIM_OC_InitTypeDef timConfig;
  TIM_HandleTypeDef timHandle;
} analog_config_str;

... a sample of an entry ...

analog_config_str g_analog_config[NB_ANALOG_CHANNELS] = {
  {
    .port = GPIOA,
    .pin = GPIO_PIN_0,
    .adcInstance = ADC1,
    .adcChannelConf = {
      .Channel = ADC_CHANNEL_0,
      .Rank = ADC_REGULAR_RANK_1,
      .SamplingTime = SAMPLINGTIME
    },
    #if defined (STM32F100xB) || defined (STM32F100xE) || defined (STM32F101xE) || defined (STM32F101xG) || defined (STM32F103xE) || defined (STM32F103xG) || defined (STM32F105xC) || defined (STM32F107xC)
    .dacInstance = NULL,
    #endif
    .timInstance = NULL
  },



The g_analog_config structure is a combo of const data and dynamic data. Seems like that could be better optimized.
-rick

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

Re: Refactoring the STM core code

Postby Slammer » Sat Sep 17, 2016 8:38 pm

HALMX is making extensive use of large structures as arguments for functions. Nobody expects that HALMX core will be the smaller....

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

Re: Refactoring the STM core code

Postby RogerClark » Wed Sep 21, 2016 9:29 pm

I think we can probably discuss this for ever and not do anything

The safest option is probably to duplicate the whole of libstm32f1 and call it libBluePill, then we can hack about without doing any damage to the Nucelo version.

We can determine what is common and what changes, after we have produced a few board variants.

Note. I am waiting or STM to get back to me about how we can go forward and modify the code without any risk of breaking their official Nucleo board(s) functionality.

duplicating libstm32f1 seems to do this, unless we also need to change files in the cores folder


Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest