Version 7 flash usage is much higher than in previous version


I have been working on the Zephyr port of LVGL version 7 and it seems that ROM usage is much higher in version 7 than with version 6 using similar defaults. It seems that ROM usage almost doubles to run a minimal demo. One big jump in ROM usage seems to come from lv_draw (7.8 -> 20K), other areas also observe an increase.

I have posted detailed ROM analysis for multiple configurations (see notes below, can’t include links). Is such ROM usage expected on version 7? Is there anything that can be done to optimize it?


Zephyr PR:
GitHub Gist with ROM analysis:

Hi @gmarull , what compiler (and which) and linker flags did you use?

The code size in v7 is expected to be larger than v6 as a result of the new style and rendering system. They’re a lot more flexible but do come with the caveat of needing extra Flash space.

It would be worth running nm --print-size --size-sort on the binary to find out what code is using the most space (I think it might be faster to find the largest functions this way than with the tree-based graph you posted). You should also confirm that optimization (-O2, -Os, or -O3) is enabled, and that unneeded functions are being removed from the final binary (-ffunction-sections and -fdata-sections should be passed to the compiler, and --gc-sections should be passed to the linker).

I’m using Zephyr SDK 0.11.3, which includes GCC 9.2.0. The optimization level is set to -Os. @embeddedt The Linker options you mention are activated. The ROM reports given in the initial post provide detailed flash analysis (lib/gui/lvgl section)

On the note of reducing flash usage, you can try turning off these settings.

@embeddedt These are already disabled in the reports I have provided (Zephyr defaults are really minimal).

Looks like most of the cost is coming from the lv_draw subsystem, which has nearly tripled in size between v6 and v7. I do notice that some of the blending code is not being removed from the build if LV_USE_BLEND_MODES is disabled, so there may be some opportunity for size reduction on our end.

@embeddedt just opened an issue for it. Investigating.