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.
Unusually large binary after build...
Unusually large binary after build...
Just a dogs body developer, mostly making props and stuff...
Re: Unusually large binary after build...
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.
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.
Re: Unusually large binary after build...
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?
Whats the LL API?
Also why would changing clocks or the pin map significantly change binary size?
Just a dogs body developer, mostly making props and stuff...
Re: Unusually large binary after build...
If you removed useless pins from the array you save space. LL is for Low Layer. It consumes less than HAL.
Re: Unusually large binary after build...
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
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.
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
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.
Last edited by ag123 on Wed Jul 24, 2024 6:03 pm, edited 3 times in total.
Re: Unusually large binary after build...
Note that we support cmake within the core 

Re: Unusually large binary after build...
So you mean the core auto uses cmake? or will sloeber try to use a version of arduino cli?
Just a dogs body developer, mostly making props and stuff...
Re: Unusually large binary after build...
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.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 phasethese flags can *break* the build or your binaries (e.g. just crash, don't run) if some dependencies are not linkedCode: Select all
-nostdlib -nodefaultlibs -nostartfiles -Wl,--gc-sections --specs=nano.specs -Xlinker --gc-sections
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.
Not sure why though.
Just a dogs body developer, mostly making props and stuff...
Re: Unusually large binary after build...
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