I have been doing some work on creating micropython drivers for an ili9341 display for another gui and one of the major limitations I cam across was the size of storage needed both DMA-able and for those devices without PSRAM. I have been looking at the ili9XXX driving in the lvgl binding and I can see that when the buffer is created the size has been reduced by a factor of 4 as default.
My question is, does this mean you are using 4bit colour (16 colours) or is there something more clever going on?
For the work I was doing this was all I could come up with but I would be intriuged if there was another method.
Secondly why is a default baud rate of 40MHz used when the ili datasheet only reccomends 10MHz, I know that many screens can handle it but I assume there will be some that cannot?
No.
The clever thing is not in the ILI9XXX driver, but in LVGL.
In LVGL you don’t have to allocate a buffer for the entire screen. Instead you can allocate a smaller buffer and LVGL would draw the screen in parts.
This can work because ILI9341 itself has an internal buffer for the entire screen and allows you to do partial updates.
From our experience the ILI9341 consistently works with 40MHz clock, although this might be out of spec.
If you must stay within spec, lower it to 10MHz.
Thank you for the very quick reply, that is very interesting to hear.
If you don’t mind that brings up a couple questions.
What are the speed implications of having different buffer sizes, I assume larger buffers means less having to write to them leading to an increase in speed, and with limited memory is having a single buffer as large as possible better, or should the size be decreased to allow for two smaller buffers?
And finally is there an easily calculable (even if based on free memory) maximum display size that could be used, although I understand even without memory limitations speed can become a limiting factor.
LVGL supports double-buffer so the display driver can DMA data in the background from one buffer in the same time LVGL renders into the other buffer.
Regarding buffer size, from my experiments factor of 4 gives good results.
It really depends on your use case. If only small areas of the screen are updated then smaller buffers would work well. If you refresh the whole screen (scrolling for example) then you’d probably need larger buffers.
Why don’t you just try and see what works best for you?
The speed you communicate with the display and the speed you render the pixels are the limiting factors, not the buffer size.
It’s a tradeoff between display size and refresh rate. You can have a display as large as you like, but you would need to tolerate the lower FPS. It’s very easy to calculate this according to SPI speed.