Refactoring the STM core code

The official STMicroelectronics Arduino core
User avatar
RogerClark
Posts: 6131
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Refactoring the STM core code

Post by RogerClark » Fri Sep 16, 2016 11:14 pm

I've started to refactor the code uploaded by Frederic, so that each series has its own separate repo e.g. STM32F1xx, STM32L4xx etc

The Tools are now also in their own separate repo.

At the moment each board "variant" is still inside its parent folder e.g. the Nucleo_F103RB source is inside the STM32F1xx folder, however if we expect a lot of different boards to be created by the community and my STM, it may be worthwhile making each board into its own small repo and then referencing them as submodules


What does however seem to be a problem at the moment is that the system/libstm32f1 folder is really the source for a specifc variant not the whole series

I was able to rebuild the Nucleo variant, on WIndows, just by changing the path to gcc (as the dev's must have used linux and had gcc installed in usr/bin)

So I think the quickest solution is simply to rename the libstm32f1 folder to lib_nucleo_f103rb, and then copy duplicate this folder to make other variants

It may be possible to move the variant source to the variant folder to speed up debugging of a new core, but I've not had time to investigate that.

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

Re: Refactoring the STM core code

Post by Slammer » Fri Sep 16, 2016 11:39 pm

libstm32f1 must be remain common (in source level) for all F1 members otherwise the development and support will be a nightmare, of course each variant will have its own binary version of library in variants directory. Any source differences must be implemented in variants directory.
It is possible to move some functions from system/lib to variant if it is necessarily but to maintain almost the same copies of sources so many times it is not wise.
Just my opinion....

PS: I did not study the code yet....

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

Re: Refactoring the STM core code

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

@slammer

I think libstm32f1 will need to be split up, it contains both variant specific code as well as code thats common to the stm32f1 core :-(

e.g. the variant initiation, in variant.cpp
calls hw_config_init() which is in libstm32f1 (in hw_config.c)

But in hw_config.c, hw_config_init() calls SystemClock_Config() which is variant specific e.g. in the case of the Nucleo it sets up the HSI clock etc

So I think inside libstm32f1 there would need to be a common and a variants folder, then inside the variants folder would be source, include and build_gcc folders.

Or perhaps have a variants folder under the system folder and that has subfolders for each board

I'm not sure how the development company planned on releasing more than one variant per MCU series, perhaps this wasn't part of their remit :-(

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

Re: Refactoring the STM core code

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

Maybe just make the hw_config_init() function a weak reference .. put a default one in the lib and let boards override in variant
-rick

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

Re: Refactoring the STM core code

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

Good idea

Where will hw_config.c for each board go ?

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

Re: Refactoring the STM core code

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

in the variant folder
-rick

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

Re: Refactoring the STM core code

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

OK. So its compiled by the IDE..


Of course the USB CDCACM stuff is current not in the source code at all because that Nucleo board doesnt use it ;-(

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

Re: Refactoring the STM core code

Post by RogerClark » Sat Sep 17, 2016 3:07 am

Rick

I'm not sure about the weak reference idea

Isn't there an issue that libstm32f1 could be compiled without some HAL functions which the individual variant needs, or could possibly burden some variants functions that are not used

e.g. the Nucleo doesn't use USB CDCACM but the blue pill needs it

Well, perhaps USB CDCACM would end up in all variants's lib file but would not then get linked into the binary if it was not called in the real (strong) hw_config_init function

It still seems more flexible to me, to have variants within system folder.

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

Re: Refactoring the STM core code

Post by Slammer » Sat Sep 17, 2016 9:26 am

The initialization of the clock, normally happens in HALMX in function SetSysClock in file system_stm32f1xx.c. This file must be specific for each board and thus must be in variant directory.
It is not possible to have a generic function in system library as weak, because of arduino build system, the system library is in archive form during linking, the same thing happens for all files of core and variant (arduino builds everything in a temporary library). It is not possible for the linker to select which function must be resolved because both versions are on different libraries. I cant see a reason to define anywhere the generic version (actually empty, that means that MCU will run at default internal clock), this function must be defined in variant directory of any variant.

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

Re: Refactoring the STM core code

Post by RogerClark » Sat Sep 17, 2016 10:28 am

Slammer wrote:The initialization of the clock, normally happens in HALMX in function SetSysClock in file system_stm32f1xx.c. This file must be specific for each board and thus must be in variant directory.
It is not possible to have a generic function in system library as weak, because of arduino build system, the system library is in archive form during linking, the same thing happens for all files of core and variant (arduino builds everything in a temporary library). It is not possible for the linker to select which function must be resolved because both versions are on different libraries. I cant see a reason to define anywhere the generic version (actually empty, that means that MCU will run at default internal clock), this function must be defined in variant directory of any variant.
So would the solution just be be to move hw_config.c into the variant folder ?

Note. I suspect some boards will need a lot more setup, e.g. some need USB CDCACM some done't

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest