Jump to content

Code size estimation


Hilco

Recommended Posts

Hello,

We have hardware with an STM32F070RBT6 with 16kB SRAM and 128kB flash of which we have used 32kB for a bootloader, so only 96kB flash available.
Also a SPI-flash memory of 32Mbit (4MByte) is available for storing information, only a small part of 256 kByte of this 4MByte is reserved for other purposes.

The libraries I need for this project are added, see the gfxconf.h wich is attached.

I even do not have any application yet, but compiling these librarys I already use about ~50kB of flash, so only 46kB remaining.
I need to implement a big menu-structure.
My worry's are that we run out of flash-memory before I finish the project.

Can we have mail-contact about this?

I can send then some confidential information about the planned menu-structure for this project.

gfxconf.h

Link to comment
Share on other sites

That is likely to be sufficient for most applications. Some general helpful hints...

To minimise your code space: keep your list of fonts small as they can only be used from flash. Use filtered fonts eg of the two UI fonts one is filtered and one is not. Don't use anti-aliased fonts as they take considerably more space. Make sure you turn off uGFX modules and options you don't need. Similarly with the ST HAL (that is huge). Play with your compiler optimization levels - too high and you get things breaking die to optimiser bugs (particularly with gcc), too low and the code expands. You can also play with link level optimisation. It can again yield some good gains at the risk of some strange compiling problems. With a minimal application it is useful trying turning uGFX options off and on to see what affect they have on code size. Be careful with images in flash and ROMFS because they can very quickly chew up available code space. Different image formats have different compromises between size, ram required to decode,  and speed of decoding. Often simple images can be replaced by polygons in code leading to significant speed and code size improvements even though polygon support itself takes space.

In the end a graphics library has a lot of work it needs to do and unfortunately that takes a fair chunk of code space. The advantage however is that application code can be corespondingly smaller because most of the heavy lifting has been done.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...