[LVGL] Add options to improve memory usage of LVGL projects

[fietser28]

Current implementation creates all LVGL screens, widgets and corresponding flow states and variables at startup and keeps them active in memory. This requires a large LVGL memory pool if the amount of screens/widgets grows, even if the screen is only showed once or rarely. Even for simple screens the LVGL memory is considerable.

The same applies to the flow states, but I'm not sure if there is much to be gained here in effort vs. memory usage reduction.

• [ ] I would like to have an option to delete LVGL screens resources when they are not active. A screen will have a checkbox to ' optimise LVGL memory usage'. E.g. have studio create deletescreen functions and make sure the needed delete/createscreen functions are called when switching screens instead of just calling all the createscreen* functions at startup. This is for just the LVGL objects not the flowstate. I think the implication is that if a screen with this property is not active properties can not be changed (from the LVGL action) and when switching to the screen all the initial LVGL settings are loaded. the flow state (e.g. local variables) are still retained. It is up to the user to set the LVGL states upon re-entry.
• [ ] Also implement the dynamic creation and deletion of corresponding flow states. This will make local variables non-persistent when a screen is deactivated.
• [x] Nice to have: Make the Flow QUEUE_SIZE (queue.cpp) user configurable. Allowing for more memory tuning.
• [ ] To reduce required queue size, do not queue widgets that do nothing during flow execution procedure/process.
• [x] Store assets as uncompressed data inside FLASH, so it can be accessed from there and doesn't require additional RAM.

Example use case: Raspberry Pi Pico with 264KBytes of RAM and 2MBytes of FLASH. The flow has 7 screens (of 320x240) with around 100 widgets, 50 native variables and 25 local variables in total. Static memory allocations are now:

• the LVGL memory pool (LV_MEM_SIZE + overhead) is already around 100Kbytes and I need to keep increasing it when adding screens/widgets.
• The eez::flow::g_queue is 11.7KB.
• the LVGL display buffer is set to 6300 bytes. This is working fine and a constant size. This is outside of the flow code and can be tweaked already.

I suspect this is a common issue with a lot of MCU's where RAM is limited.

Point of attention: Will the LVGL memory pool implementation keep the fragmentation low to keep functioning properly with a limited pool size?

[mvladic]

I implemented support for uncompressed assets data.

Until now, so called assets data (pages, flows, global variables, ... definitions) was stored in compressed (LZ4) form in FLASH memory and decompression of that data was done during startup in RAM or SDRAM and after that used from there. This was done in that way because it was wanted to optimize the consumption of FLASH memory with the assumption that there is a large SDRAM memory. Since it is mainly read only data (i.e. only global variables are read write) it makes sense to keep it all the time in the FLASH memory if one wants to optimize RAM consumption. In order to achieve this, assets data must be written to flash in uncompressed form. To store assets data uncompressed inside FLASH memory following changes are required:

• In flow_def.h replace line //${eez-studio GUI_ASSETS_DECL_COMPRESSED} with //${eez-studio GUI_ASSETS_DECL}
• In flow_def.c replace line //${eez-studio GUI_ASSETS_DEF_COMPRESSED} with //${eez-studio GUI_ASSETS_DEF}

There is also some changes in eez-framework to support this, so pull the latest version.

[mvladic]

Flow execution queue size can be adjusted also. By default, memory for 1000 entries is reserved. You can change this to some smaller value by putting the following line in eez-framework-conf.h that you can place next to lv_conf.h:

#define EEZ_FLOW_QUEUE_SIZE 250

But, you must determine value that works for you empirically. You can get the max. value used so far by calling eez::flow::getMaxQueueSize().