Arduino for STM32

Posted: **Wed Jul 24, 2024 9:40 am**

So I've just ran into an issue on a work project.
Were still trying to migrate over to a vscode setup but were not there yet, and I'm currently using sloeber on eclipse.

The odd issue is I'm getting an unusually large binary being built.

At the moment I'm just trying to build the framework of a program that can have features added to it over time. But even with this fairly simplistic framework, I'm getting a 114kb binary.

For reference, my old tricorder project has about 14 thousand lines of written code. And that fits on an f103 128kb. Though that was on Roger Clarks core.

Here using the official Arduino_STM32 core a few hundred lines of code (if that) is 114kb...

Something isn't right. Also while the vscode side of things is still being worked on, it appears to compile and it makes a 60kb binary. Though to be honest even that seems large at this stage.

This is using a custom variant for the STM32F030RCT6
U(S)ART Support : Enabled (no generic 'Serial')
Optimize : Smallest (-Os default)
USB Support: none
Debug Symbols : none
Upload Method : SWD
C runtime : Newlib Nano (default)

Just did an empty program, that came to 27kb...

Main libraries I have added (other than my own modular classes in their headers ect...) Is FreeRTOS and Blues Notecard and Arduino Json.

Maybe those libraries are adding a huge bulk... Still think 114kb is A LOT.

Posted: **Wed Jul 24, 2024 10:54 am**

You can do some optimizations:
https://github.com/stm32duino/Arduino_C ... tes-of-ram

And also:
https://github.com/stm32duino/Arduino_C ... nmap-array

You can also try to:
Enable LTO
Create system core clock config using only LL API.

Posted: **Wed Jul 24, 2024 11:23 am**

not tried the other things yet... but enabled LTO... its not made any difference.

Whats the LL API?

Also why would changing clocks or the pin map significantly change binary size?

Posted: **Wed Jul 24, 2024 12:14 pm**

If you removed useless pins from the array you save space. LL is for Low Layer. It consumes less than HAL.

Posted: **Wed Jul 24, 2024 5:43 pm**

this is sometimes a dark art
try using Amap or such utilities to examine the map files
https://www.sikorskiy.net/info/prj/amap/
that'd give you a good idea of what is in the elf (and possibly bin) file.

As I used makefile builds
viewtopic.php?t=183
^ note this is outdated and may no longer works
use the cmake builds instead if you can

I experimented with flags during the link phase

Code: Select all

-nostdlib
-nodefaultlibs
-nostartfiles
-Wl,--gc-sections
--specs=nano.specs
-Xlinker --gc-sections

these flags can *break* the build or your binaries (e.g. just crash, don't run) if some dependencies are not linked

I think cmake builds may partly solve the issues, but it'd still be difficult if one wants to make efforts to exclude the dependencies.
the thread about cmake is here
viewtopic.php?t=1648

some stuff / reading materials here
https://cmake.org/
https://cmake.org/cmake/help/latest/gui ... index.html
the idea about cmake is to explicitly include/exclude dependencies and swap libraries / includes at built time
it is why it works and is difficult
i.e. the idea/concept about 'configuring' the build, and then followed by the build

I think cmake is a more mature build system than arduino, for that matter arduino-cli, it (cmake) is after all used to build huge projects the likes of many very large projects etc that possibly has millions of codes and thousands to hundreds of thousands of dependencies.

there are also various other sophisticated call graph apps in an attempt to address this problem
https://en.wikipedia.org/wiki/Call_graph
as one thing links to another, chances are that some #includes can pull in dependencies which you may not intended to include them.
i.e there is possibly limits for the compiler to figure out and trim unused dependencies.

Posted: **Wed Jul 24, 2024 5:57 pm**

Note that we support cmake within the core

Posted: **Thu Jul 25, 2024 1:28 pm**

fpiSTM wrote: Wed Jul 24, 2024 5:57 pm Note that we support cmake within the core

So you mean the core auto uses cmake? or will sloeber try to use a version of arduino cli?

Posted: **Thu Jul 25, 2024 1:29 pm**

ag123 wrote: Wed Jul 24, 2024 5:43 pm this is sometimes a dark art
try using Amap or such utilities to examine the map files
https://www.sikorskiy.net/info/prj/amap/
that'd give you a good idea of what is in the elf (and possibly bin) file.

As I used makefile builds
viewtopic.php?t=183
^ note this is outdated and may no longer works
use the cmake builds instead if you can

I experimented with flags during the link phase
Code: Select all
-nostdlib
-nodefaultlibs
-nostartfiles
-Wl,--gc-sections
--specs=nano.specs
-Xlinker --gc-sections
these flags can *break* the build or your binaries (e.g. just crash, don't run) if some dependencies are not linked

I think cmake builds may partly solve the issues, but it'd still be difficult if one wants to make efforts to exclude the dependencies.
the thread about cmake is here
viewtopic.php?t=1648

some stuff / reading materials here
https://cmake.org/
https://cmake.org/cmake/help/latest/gui ... index.html
the idea about cmake is to explicitly include/exclude dependencies and swap libraries / includes at built time
it is why it works and is difficult
i.e. the idea/concept about 'configuring' the build, and then followed by the build

I think cmake is a more mature build system than arduino, for that matter arduino-cli, it (cmake) is after all used to build huge projects the likes of many very large projects etc that possibly has millions of codes and thousands to hundreds of thousands of dependencies.

there are also various other sophisticated call graph apps in an attempt to address this problem
https://en.wikipedia.org/wiki/Call_graph
as one thing links to another, chances are that some #includes can pull in dependencies which you may not intended to include them.
i.e there is possibly limits for the compiler to figure out and trim unused dependencies.

funny you mention some strange include causing programs to hang... Im am running into such an issue too, and ive narrowed it down to blues notecard and freertos being together.
Not sure why though.

Posted: **Thu Jul 25, 2024 1:32 pm**

Mangy_Dog wrote: Thu Jul 25, 2024 1:28 pm
fpiSTM wrote: Wed Jul 24, 2024 5:57 pm Note that we support cmake within the core
So you mean the core auto uses cmake? or will sloeber try to use a version of arduino cli?

No. But it is cmake ready. See the wiki to know how use it. You can also load the cmake project with cube ide.

https://github.com/stm32duino/Arduino_C ... esentation

Maybe one day we will use it as based even with Arduino

Arduino for STM32

Unusually large binary after build...

Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...

Re: Unusually large binary after build...