SPI Flash Data Compression and Optimisation

[rhapsodyv]

Description

The LVGL UI use up to 2.9MB of icons plus 500kb of fonts. So, the board needs a big SPI Flash to hold all its assets.

This PR add a SPIFlashStorage class, that optimise and compress data stored to spi flash on the fly. To do it, it uses a simple but really fast compression method: RLE.

The compression method works with both 1 and 2 bytes buffers. In the current code, I'm using 2 bytes, because the LVGL images are 16bits. So, it benefits from the repeated colours in the background.

Restriction I followed: the uncompression code must not be slower than just loading the uncompressed data from SPI Flash.

Benefits

• With this code, all the 2.9mb icons fits in less than 400kb!!
• The LVGL draw rate became faster. Each icon have 32kb uncompressed.
  Before this PR, in a screen with 5 icons, it did need read 163840 bytes from SPI Flash (32kb*5). Now, it only reads in average 5K per icon, summing up to 25.600 bytes reads!! The uncompression method is O(n) - n=>uncompressed length, so its really fast, its just a memory copy.
• Chitu boards (and other boards with tiny 2mb spi flash) will support the new LVGL UI with no modification
• Other Marlins resource could benefit from this compression method and SPIFlashStorage class. It could be used, for example, to compress/uncompress data in program memory, or even in eeprom.

Related Issues

[thisiskeithb]

This is great. Also:

[thinkyhead]

compress/uncompress data in program memory, or even in eeprom.

For EEPROM it's better if the data (while it fits) is uncompressed, and we only write the changes, and each piece of data has a definite position. It is still a future plan to make the EEPROM data more structured and to have each feature manage its own persistent settings without affecting other settings.