STM32 Compatible Libraries

Post here first, or if you can't find a relevant section!
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: STM32 Compatible Libraries

Post by ag123 »

for cmake, my guess is it could live 'outside' as a 'different' (experimental) core at least for a while, maybe as it progresses, it may evolve differently.
GonzoG
Posts: 403
Joined: Wed Jan 15, 2020 11:30 am
Answers: 27
Location: Prudnik, Poland

Re: STM32 Compatible Libraries

Post by GonzoG »

pwrgreg007 wrote: Sat Jan 15, 2022 11:12 pm asking your opinion: Would I be better off going with a "Black Pill" that has more memory?
Definitely. 32kiB of flash memory is not enough for TFT_eSPI library in Arduino IDE.
I have F103C8 bluepills with 128kiB flash and that's minimum for most of my projects, even the simple ones as program size often goes above 64kiB.

That's the biggest "flaw" of stm32duino in Arduino IDE. Writing programs for MCUs is simple but this means that there will be a lot of overhead.
User avatar
fpiSTM
Posts: 1738
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 91
Location: Le Mans
Contact:

Re: STM32 Compatible Libraries

Post by fpiSTM »

ag123 wrote: Sun Jan 16, 2022 9:10 am for cmake, my guess is it could live 'outside' as a 'different' (experimental) core at least for a while, maybe as it progresses, it may evolve differently.
It could live together.
mrburnette
Posts: 633
Joined: Thu Dec 19, 2019 1:23 am
Answers: 7

Re: STM32 Compatible Libraries

Post by mrburnette »

ag123 wrote: Sun Jan 16, 2022 8:29 am i've a 'strange' feeling that we'd perhaps move to use more of 'cmake' or 'platform io' types of setups.
But that would break a lot of compatibility with 'Arduinoish' way of doing things.
...
Opinion: I have always thought of Arduino being an entry/intermittent approach to getting non-programmers and weekend programmers into microcontroller projects.

IMO, Arduino is a paradigm. Most users find a project on the Internet and they do a copy/paste/modify to create their project. Arduino libraries are numerous but are not all quality code, or code that does not function across all Arduino-compatible uC hardware. Libraries are a two-edged sword: easy to install but full of alligators that will bite you. Worst, few Arduino programmers dig into the libraries to understand how they function; black-box code: convenient but does not stimulate the gray cells of the brain.

I find Arduino a fun environment: I import all used libraries into my sketch folder and hack the crap to bend them to my need. Often, I rewrite or delete more than half of the library code. As the hacked library code is encapsulated in the sketch folder, my projects are immune from the whimsy of library-manager updates! Using libraries in this manner forces one to review and become familiar with the library code logic.

Many weekend programmers will be satisfied with Arduino and will have no desire to move into more professional developments. Others will find Arduino bloated and constrained and will migrate to more powerful environments; it's a personal choice. In the STM32 case, complete, powerful tools are readily available.

Ray
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: STM32 Compatible Libraries

Post by ag123 »

I think the challenge is partly that the stm32 portfolio is very large, the feature sets is literally huge across the different series.
Even though ST keeps some things between the series common, e.g. pa0-pa7 have rather similar pin functions mostly.
There are legitimate differences between the series f0, f1, f3, f4, f7, h7, mp1 etc. that accounts for the utility and merits of selecting a particular soc.
what has been achieved with stm core is 'pretty impressive' if you consider that it runs across many socs in the series.
it isn't simply that hal is used, but that some of the codes dynamically consider features to use to account for the differences.

This would in part contribute to some inevitable code bloat, but the *convenience* is there, one could literally for the same sketch, select a different board/soc and rebuild and it *just works*. that in part as many features are 'bundled' in the core, adc, timers, uart etc.

the other challenges as it happens are that for 'cramped' small mcus with very limited flash and sram, this convenience would be a big 'luxury'.
another thing is apparently the size and complexity of the codes means that the less 'smart' build tool chains would take more time to build and run through the huge set of dependencies (includes, etc) to narrow that down to a particular board, mcu and feature sets (pheriperials).
this still works generally ok, just that compile time tends to be longer at the initial build.

this can be partly alleviated by more 'advanced' build concepts such as the use of cmake, scons (used in platformio) etc.
strictly speaking, it isn't advanced, but that it means dependencies such as the board, soc (stm32fxxyy), and features/pheriperials
need to be selected up front.

in the 'big' languages such as java, it is called dependency injection and/or modules.in c/c++ it can be mimicked with cmake, scons etc.
the 2 concepts 'monolithic' vs 'modular' are not necessarily 'compatible'
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

Re: STM32 Compatible Libraries

Post by pwrgreg007 »

I found something interesting. First, the presence of hal_conf_extra.h didn't change anything, whether it compiled or not. The instructions at https://github.com/stm32duino/Arduino_C ... issues/228 may need some clarification.
The hex file size (for the blink example) compiled with the deprecated 1.3.0 STM library is 126KB.
I switched Arduino Board part number from "BluePill F103C6" to "BluePill F103CB (or C8 with 128k)" to see if it would compile if it thought the target has more memory. It did compile, and the hex size is now 40kb, which seems to indicate that some step, post-link, is removing unused libraries.
This may be an issue for the developers. Why not run the optimization anyway, even if link indicates a flash overflow, because it may fit after this optimization? (I may have answered my own question. I think I erroneously set the board to ...C6 but I have a ...C8 chip. And the toolchain is making a .bin file now instead of .hex.)
I wanted to state for the record that these tools available are great for many apps, making development very easy, especially for new users who don't want to dive into the complexities of HAL-level programming. And the power and flexibility of these STM32 chips is amazing!
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: STM32 Compatible Libraries

Post by ag123 »

normally c8 with 64k flash, would leave enough room to keep some of the 'extras'. it is inevitable that symbols are compiled into the binary as stm32duino bundles a commonly used feature set adc, usb-serial, serial(uart), timers, gpio, and maybe a couple more. if you add libraries like spi etc, it would add to it, and there are pinmaps other data structures (nvic interrupts), buffers, lookup data (e.g. device descriptors for usb) etc. and 'convenience functions' Serial.print() et.al.

I'd say timers is after all a feature of stm32duino, and stm32 itself.
one example use is it could be used to drive ADC samplings and it gives one fine grained control over the sample rate in the range 0 - 500khz.
This is otherwise 'impossible' on the adc alone. And that this isn't the only use case, i think marlin 3d printer firmware, literally use it to drive timings to run the stepper motors and temperature sampling.

the common bundle has advantages and disadvantages, it makes it a little 'OS' (operating system), by having that bundle.
this is so that codes linking against it could *just work* across different mcus. This can be important as I doubt everyone wants to keep using a small mcu, perhaps.

a modular approach by removing the dependencies would normally lead to smaller binaries, at the expense of the feature sets.
to get smaller binaries, one could examine the compiled elf file with tools like elf viewers
http://www.sunshine2k.de/coding/javascr ... iewer.html

i think the compiler bundled tool objdump can also be used to look at the symbols bundled into the elf file.
that would help one with the 'optimization' to reduce size if one really needs to reduce the bulk of the binary. As it may involve a modified core for that matter.
Last edited by ag123 on Mon Jan 17, 2022 11:00 am, edited 1 time in total.
GonzoG
Posts: 403
Joined: Wed Jan 15, 2020 11:30 am
Answers: 27
Location: Prudnik, Poland

Re: STM32 Compatible Libraries

Post by GonzoG »

pwrgreg007 wrote: Mon Jan 17, 2022 1:31 am I found something interesting. First, the presence of hal_conf_extra.h didn't change anything, whether it compiled or not. The instructions at https://github.com/stm32duino/Arduino_C ... issues/228 may need some clarification.
The hex file size (for the blink example) compiled with the deprecated 1.3.0 STM library is 126KB.
I switched Arduino Board part number from "BluePill F103C6" to "BluePill F103CB (or C8 with 128k)" to see if it would compile if it thought the target has more memory. It did compile, and the hex size is now 40kb, which seems to indicate that some step, post-link, is removing unused libraries.
Don't look at hex files size. Those aren't always final files.

When you look at your first post at the terminal output:
... region `FLASH' overflowed by 7820 bytes ...
This means that the program size was about 40KiB. (37268 + 7820 = 40588 = 39.6 KiB)
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

Re: STM32 Compatible Libraries

Post by pwrgreg007 »

This was due to an error on my part. I had selected 'BluePill F103C6 (32K)' instead of the correct 'BluePill F103C8 (64K).
Thanks to everyone for the helpful replies.
mrburnette
Posts: 633
Joined: Thu Dec 19, 2019 1:23 am
Answers: 7

Re: STM32 Compatible Libraries

Post by mrburnette »

ag123 wrote: Sun Jan 16, 2022 9:10 am for cmake, my guess is it could live 'outside' as a 'different' (experimental) core at least for a while, maybe as it progresses, it may evolve differently.
I you have a few minutes, I think you will find this interesting: Optimizing Arduino Code: no setup(), no loop()

https://www.youtube.com/watch?v=-XPrSScamXc
Post Reply

Return to “General discussion”