cancel
Showing results for 
Search instead for 
Did you mean: 

Save flash when using printf and floating-point on STM32F0

istepne
Associate III

Originally a reply to this thread:

https://community.st.com/t5/stm32-mcus-embedded-software/how-generate-hex-file-without-link-files-hal-drivers/td-p/723141

Split as it seems to be a different issue.


Hi,

I have same issue too

I am using STM32F051R8 with STM32CubeIDE Version: 1.18.0

There is limited Flash memory. So when I am checking the memory I found some library names etc definition strings on my hex file. I tried to change some setting according to topics above but no success at all

Please let me know which settings is this. Also I am using optimization "Optimize for size -s"

Regards

Murat

1 ACCEPTED SOLUTION

Accepted Solutions

@istepne wrote:

if it possible to remove this textures (sic?) from flash makes more space for me.


You mean text ?

As @KnarfB said, the space taken by the text is insignificant - it's the use of floating-point and printf that's really eating the flash space!

 


@istepne wrote:

This is an old project and old electronic board desing.


So why are you adding floating-point at this late stage?

View solution in original post

13 REPLIES 13

@istepne wrote:

Please let me know which settings is this. 


This one:

https://community.st.com/t5/stm32-mcus-embedded-software/how-generate-hex-file-without-link-files-hal-drivers/m-p/723990/highlight/true#M55354

 

PS:

It will be in your stm32xxxx_hal_conf.h file:

 

/* ########################## Assert Selection ############################## */
/**
  * @brief Uncomment the line below to expanse the "assert_param" macro in the
  *        HAL drivers code
  */
/* #define USE_FULL_ASSERT   1U */

 

As shown above, it is not defined.

@Andrew Neilthank you for the answer.

I realized that it comes from the floating library. I need to use printf with floating point operations enabled.

I made a new project and just compiled it, it tooks 2,99 kbyte memory. After than I enabled the floating feature on settings and compiled again (either debug or release mode) . Then it tooks 23,52kbyte (huge increase). I see the texture on the hex file again with a blank project.

I need Flash memory space on this the older board (can not change the MCU). 
Is there a way to disable this strings from hex file to get more space?

Or any other solution like lightweight floating point library etc

Regards

Murat

This doesn't sound like the same problem as the OP - which was solved as described.

Edit: So split to a separate thread.

 


@istepne wrote:

I see the texture on the hex file again with a blank project


What, exactly, do you mean by that?  How are you viewing it?

Please give full details of the tools & procedures used, and show what you're seeing.

 


@istepne wrote:

I need (sic?) to use printf with floating point operations enabled.


Do you really need to?

Both Floating Point and printf can use a lot of flash - so, when flash space is limited, maybe try to avoid both?

KnarfB
Principal III

Look into alternative printf implementations like GitHub - charlesnicholson/nanoprintf: The smallest public printf implementation for its feature set. and avoid using the printf provided in newlib.

hth

KnarfB

@Andrew Neil  I was trying to find this topic..

istepne_0-1741794056500.png

I used ST-LINK Utility to display hex file and as you see there is some link names. Tihs is a complete blank project and compiled with floating feature enabled as shown below pictures.

istepne_1-1741794136787.pngistepne_2-1741794154717.png

 

I also compiled as "debug" and "release" modes, the result is same on the hex file output.

istepne_3-1741794250386.png

Flash usage also looks like too much

 

I could reproduce this behaviour.

- STM32CubeIDE 1.18.0 clean install on Win  11, no upgrade

- new empty STM32F051R8 project

- added your settings

- release config

- added code in main to force printf inclusion 

volatile float x = 3.14159f;

printf("x=%f\n", x);

The created .bin contains "few" strings which are probably from assert statements in newlib:

KnarfB_0-1741852474915.png

But, the main contribution to the .bin file size is from the printf floating point support:

KnarfB_1-1741852562300.png

hth

KnarfB

 

 

Dear @Andrew Neil  I would like to thank you for your effort and taking time.
This is an old project and old electronic board desing. So we do not want to change the older boards (we consider to just firmware update to them)

As this IC has small flash memory, we are using many features of it, like DAC, ADC channels, EEProm evaulation on it, we need every bytes to recover if it can. So, if it possible to remove this textures from flash makes more space for me.

I will try to use without floating point operations like when 2000s with 8bit controllers :)
As you stated earlier, I will try to remove both printf and floating point usages (in many case, using the printf, just used to put dot point between integer values)

Regards,

Murat


@istepne wrote:

if it possible to remove this textures (sic?) from flash makes more space for me.


You mean text ?

As @KnarfB said, the space taken by the text is insignificant - it's the use of floating-point and printf that's really eating the flash space!

 


@istepne wrote:

This is an old project and old electronic board desing.


So why are you adding floating-point at this late stage?

Try use KEIL for fpu and omit printf float support.