Proposal: move system/libstm to core folder

The official STMicroelectronics Arduino core
danieleff
Posts: 106
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Proposal: move system/libstm to core folder

Postby danieleff » Sat Nov 05, 2016 10:12 am

I belive it is there to make compilation faster. Here are my test results:

Current:
  • compiling the static library (after clean) takes 11 seconds, 57 .o files (45 from stm32f1xx_hal, 12 from system/libstm)
  • compiling arduino sketch for the first time takes 6 seconds, 23 .o core/arduino files + sketch
  • compiling arduino sketch again takes 3 seconds, only recompiles the sketch
If I move all the files from system/libstm32f103c/source and system/libstm32f103c/include to cores/arduino/libstm (with the exception of stm32f1xx_hal_conf.h) (also note: no need to change the makefiles/platform.txt):
  • compiling the static library (after clean) takes 9 seconds, 45 .o stm32f1xx_hal files
  • compiling arduino sketch for the first time takes 8 seconds, 35 .o files (23 core/arduino + 12 libstm files) + sketch
  • compiling arduino sketch again takes 3 seconds, only recompiles the sketch
Advantage:
  • Working on the libstm files, no need to set up a gcc make environment (in windows/linux), execute the makefile+compile every time. Just compile as always.
  • The static library needs to be created only once, as the stm32f1xx_hal files rarely change.
  • VECT_TAB_OFFSET will just work, as it will be used arduino-compile time, not static library compile time.
Disadvantage:
  • Slightly slower first sketch compilation.
  • Only one libstm. Although I see this as an advantage.

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

Re: Proposal: move system/libstm to core folder

Postby RogerClark » Sat Nov 05, 2016 7:44 pm

I does this work if we support other F1 variants e.g. F101 and F105?

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

Re: Proposal: move system/libstm to core folder

Postby danieleff » Sat Nov 05, 2016 9:11 pm

Yes.
In both versions the staticlib makefile has to support it(currently "CFLAGS += -DSTM32F103xB" etc...); move SystemClock_Config from hw_config.c to variant.cpp; (and move the peripheral variables to variant, if they greatly differ between chips).

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

Re: Proposal: move system/libstm to core folder

Postby RogerClark » Sat Nov 05, 2016 9:38 pm

Could you put your test code / file refactoring somewhere e.g. github so I can take a look ?

User avatar
Vassilis
Posts: 291
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Proposal: move system/libstm to core folder

Postby Vassilis » Sun Nov 06, 2016 12:56 am

According to your tests, the current core needs 11+6=17 seconds to compile a sketch and the proposed needs 9+8=17 seconds also.

Did you compile a large (complex) sketch or just a simple blink sketch ?

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

Re: Proposal: move system/libstm to core folder

Postby danieleff » Sun Nov 06, 2016 6:53 am

RogerClark wrote:Could you put your test code / file refactoring somewhere e.g. github so I can take a look ?

https://github.com/danieleff/Arduino_Co ... tm_example

  1. Fix compilation error
  2. Move libstm32f103c files to cores/arduino
you can already test after these.

To compile both bluepill and nucleo:
  1. Modify static library makefile to support multiple chips, accidentally the clean target row was left in, should be removed
  2. Add nucleo to static library makefile, now make will create both files
  3. Clock config for bluepill, copy from its hw_config.c
  4. Clock config for nucleo, copy from its hw_config.c
Now both should compile.

Some cleanup:
  1. Cleanup, move chip.h to cores/arduino
  2. Cleanup, remove old libstm32f1 folder
  3. Cleanup, rename libstm32f103c to staticlibstm32f1, This is important! Fixes platform.txt include.

And here is how you would add for example the STM32F100 VLDISCOVERY:
  1. Create STM32VLDiscovery variant by copying Nucleo
  2. Modify STM32VLDiscovery linker script to 8K ram
  3. Generate STM32VLDiscovery clock config using STM32CubeMX
  4. Create STM32VLDiscovery static library
  5. *EDIT: Add STM32VLDISCOVERY to boards.txt
This wont compile as analog.c calls __HAL_RCC_DAC1_CLK_DISABLE() instead of __HAL_RCC_DAC_CLK_DISABLE() (well its a macro but anyway)

Unfortunately I cannot test as I only have F103

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

Re: Proposal: move system/libstm to core folder

Postby danieleff » Sun Nov 06, 2016 7:44 am

Vassilis wrote:According to your tests, the current core needs 11+6=17 seconds to compile a sketch and the proposed needs 9+8=17 seconds also.

Did you compile a large (complex) sketch or just a simple blink sketch ?


It was blink.
Compiling a sketch with 1 .ino, 6 .cpp, 6 .h, that uses SPI, NewliquidCrystal, Wire, Serasidis_EtherCard_STM (copied from maple repo):
before: first time 13 seconds, subsequent 6 seconds.
after: first time 16 seconds, subsequent 6 seconds.

I did not time the static library compilation, as it is not needed to be recompiled.

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

Re: Proposal: move system/libstm to core folder

Postby danieleff » Sun Nov 06, 2016 9:40 am

And here is USB Serial merged from https://github.com/Serasidis/cbp_HALMX_2

Ironically I had to put part of it into static lib, as usbd_conf.h is included from Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_def.h .

Also because the example STM32F100 does not have USB, it fails to compile for that board. BluePill works.

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

Re: Proposal: move system/libstm to core folder

Postby RogerClark » Sun Nov 06, 2016 9:56 am

danieleff wrote:before: first time 13 seconds, subsequent 6 seconds.
after: first time 16 seconds, subsequent 6 seconds.


For a Blank sketch
I'm seeing just under 6 seconds for first time and about 2 seconds for subsequent compiles, which is pretty much in line with what you are seeing.

This seems to be marginally slower than in the existing repo, but only marginally slower - and on my machine the difference is so little its hard to measure by hand using my stopwatch ;-)

PS. I'm sure some people will get even faster compiles, experientially on Linux, or if they have an even more souped up machine

User avatar
GrumpyOldPizza
Posts: 166
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Proposal: move system/libstm to core folder

Postby GrumpyOldPizza » Mon Nov 07, 2016 12:17 pm

RogerClark wrote:
danieleff wrote:before: first time 13 seconds, subsequent 6 seconds.
after: first time 16 seconds, subsequent 6 seconds.


For a Blank sketch
I'm seeing just under 6 seconds for first time and about 2 seconds for subsequent compiles, which is pretty much in line with what you are seeing.

This seems to be marginally slower than in the existing repo, but only marginally slower - and on my machine the difference is so little its hard to measure by hand using my stopwatch ;-)

PS. I'm sure some people will get even faster compiles, experientially on Linux, or if they have an even more souped up machine


Just my 2 cents here. For the STM32L4 core I ended up compiling the system code 3 times, once for stm32l432, stm32l433 and stm32l476. The USB code still gives me grief, as the USB descriptors should live somewhere else, so that variants could use different setups. A simple makefile can do the job of compiling multiple variants while still keeping dependency checking alive. The reason I feel this strategy is better is that if all the system code is compiled ahead of time, you can make sure that there won't be compile errors (and hence functional problems) for chips other than the one you are currently working on. Details like changed peripherals, modified DMA assignments, missing GPIOs and such.


Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest