I am starting with this amaizing lib, and I ported the library to my board
Hardware :
STM32F103VE, with an FSMC parallel 16 bits 320x240 TFT LCD 16 bits RGB 565 + touchscreen. So far, examples do compile, and I get the glue middleware working fine. Vscode+ platformio IDE.
Lvgl 6.1.2
I searched in the forum, but did not found a similar question.
I have 256Kb free flash, 32Kb of free RAM , and on top of this I have 2 buffers of 10 lines / 320 pixels, with the display flush function using the DMA.
What I try to achieve :
Decode a Jpeg image 320x240 stored in Flash ( about 25Kb) , displayed onto the LCD. Image is a still image that will remain on the screen for a few seconds. No expected graphics / buttons to go on top, no interactivity expected neither.
Issue : a single image 320x240 is 150Kb of data in raw format, and I cannot decode and store a full picture then send it to the LCD. However, as JPEG macroblocks is 8x8 pixels, it is possible to decode the picture by chunks of 8 lines, and flush this to the sceeen? A macroblock row fits nicely in the DMA buffers, and as I read the API, it is possible to decode images line by line. I would do that 8 line per 8 lines to optimize processing time.
Just found the app note about the png decoding in the blog. Too bad this is not included in the documentation pages!
It shows how to use a png decoder with compressed image in flash.
What remains not clear to me is what happens in my case with too little ram. Do we need to split the image in sub images that can fit in the ram, decode the data then display it, and do this until all sub images are displayed?
Here is a quite nice JPEG decoder SW running on Arduino. what could be nice is to actually cache not the full image in SRAM but the smallest decodable sub image. For Jpeg that would mean macroblocks, which are 16x16 pixels. If the caching mecanism in littleLgv could work on those macroblocks, eachtime a region on the screen gets dirty ( button overlap), to get the pixel data, only that macroblock(s) would need to be decoded.
@kisvegabor does this makes sense regarding the way littlelvg works and manages the data?
The TFT interface RGB565 indicate that you must store all data to display in the RAM(32024016/8 = 150K), and the MCU’ram is only 32kb. So I think the ram is not enough, or you have the wrong interface of TFT.
Flash is rom, that can not be used for store data when running.
Hi there.
The actual real lcd frame buffer, full image, is within the lcd module, So we can compute a macro block, send it to the display frame buffer, and go on to the next macro block . A macro block is only a few hundreds bytes
Unfortunately, that frame buffer is not memory mapped. I have to go through a 16bit wide data interface. Mapping is one command register, and than a data register replicated in a complete memory bank.
I asked the question because I understood that a compressed image needs to be fully decompressed and temporarily stored in cpu ram before being sent to the lcd frame buffer. This way it is also possible to manage overlays and objects going on top of the image easily . But in small systems the ram is a constrain and I am thinking than we could leverage they jpeg data structure.
By having only a few macro blocks in cache, object superpositions can still be calculated fast if the block is in the cache, and if not, decoding a macro block is way faster than decoding the full image.
That would Allow to still have a decent speed, with a small ram. Hope it clarifies