[Deprecated: old core]Proposal: move system/libstm to core folder

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.

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

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).

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

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 ?

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

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 ?

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.

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

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

Thank you danieleff for all this work.

Our preliminary tests are conclusive in spit of some regression for the Nucleo variant.
We will now work on this new architecture for the STM32F103RB Nucleo board.
Our tests will be limited to the Nucleo variant. Thank you for your understanding.

BR

danieleff wrote:
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.

fpiSTM wrote:danieleff wrote:
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.