I have 3.5" display with SPI interface and ili9488 driver. On first look is this chip similar to ili9341 (small differences in init sequence), but only on first look. Main difference is that this display do not support RGB565 mode over SPI. This display supports only RB666 mode (which is “stripped” RGB888 - 2 lowest bits from each color is not used), so each pixel has 3 bytes instead of 2 bytes in RGB565 mode.
So, there is my question… As a first try I used ili9341 driver from LVGL, changed init sequence and nothing happened, then I noticed problem with unsupported RGB565 mode. Solution should be change color mode from 16 bits to 24, but this is not supported in LVGL.
Another solution is rewrite each pixel before send. I identified relevant code:
@kisvegabor / @embeddedt - does LVGL support RB666 color mode? If not, what does it take to support it?
Changing every pixel before writing it on every frame would be very slow in Micropython.
Micropython can be used in an efficient way for controlling the UI, but usually not for rendering pixels.
Even in C that would be less efficient that supporting RB666 color mode directly in LVGL.
(By the way, there is one place I’m using Micropython to convert pixels but I’m using Viper code emitter for that)
The code that you identified is only called when the ili9341 is used in non-hybrid mode.
In hybrid mode (which is the default) all flush functionality is written in C (while init and control is still written in Micropython).
Have a look at the C implementation of ili9341 flush if you plan to do any pixel-by-pixel conversion.
Anyway, I would suggest to first find out how to support RB666 color mode natively in LVGL.
It’s not supported directly. We’ve tried to avoid supporting formats thus far that don’t align nicely with standard word sizes (1 byte, 2 bytes, 4 bytes, etc.).
You’d have to translate the pixels at a bitwise level, so I’d recommend using C (or at least Viper) to do that.
Support for RGB666 is not necessary in this case, because of ili9488 uses 24 bits data transfer, where two lowest bits of each color are not used (display cannot show 24 bits colors). But in RGB666 SPI mode, you are directly transfering data in format RGB888 -> 24 bits colors.
So, there are two ways - 16bits colors to 24 bits or 32bit (ARGB) to 24 bits. First way uses less memory, but needs more calculations, second one uses more memory (2 times), but is easiest to calculate (just cut off highest byte).
I made ili9488_flush function (copied modILI9341.c -> modILI9488.c, with some minor changes like init sequence - not used but… and renaming 9341 to 9488). Flush function for ILI9341 dislay contains byte swapping (RGB -> BGR), so I changed code to:
there are two definitions of ili9341_flush. One is in modILI9341.c (for C-only driver) and second one is in espidf.c (surprisingly for hybrid driver). And guess what… Yes, I did mean that there is only one - in C-only driver. So my code used built-in-python-class flush function, which is faulty…
So, I have a functional hybrid ili9488 driver now. It uses same code like hybrid ili9341 driver, except flush function (and init sequence, of course)…
One question: are you going to change the existing ili9341 driver to support ili9488, or are you adding a new module?
If there’s a lot of common code between them, it would make sense to have a single module with two modes or inherit both modules from a common parent class, rather than duplicate the code.
Obviously the flush C function would be separate, I’m asking about the python code.
Real difference is only in flush callback and init sequence (init sequence is a list of commands, so no problem). So, it could be parent class and two display-specific.
Hi @RXX
Did you check the datasheet of your display? Does it support controlling the contrast?
Searching the word “contrast” on ili9341 datasheet yields nothing.
You might want to look into Positive and Negative gamma control on the ILI9488,
Commands 0xE0 and 0xE1. They have many parameters and I have never modified them, but you might want to review the datahseet and see if they can benefit you somehow.
Mentioned Gamma correction should help to improve colors. There are not widely usable values, it depends on display itself. But best colors for myself (and my displays) are used in my driver code (but this is very personal, I know).