Add RGB666 color format for ILI9488

[skerr92]

I have an ILI9488 SPI display that I've been working on a driver for. Unfortunately, I can't seem to get it to work with the standard bus device as it looks like the display driver is expecting each byte over SPI to be clocked individually rather than sending it all over one clock.

@bablokb has their own version of the ili9488 driver in which they use a custom build of circuitpython that employs the patch here bus core patch

I think it would be helpful to have an option to enable byte clocking if a display needs it while maintaining the current behavior by default.

[bablokb]

My patch does not operate on bytes, but on words (i.e. 16bit wide units). And this is only necessary if the SPI-bus on the MCU side is connected to two serial-in, parallel-out shift registers that translate 8bit-SPI to 16bit-parallel. The shift-registers themselves are connected as 16bit-parallelbus input to the ILI9488.

So a very special setup on the display-side. Many ILI9488 displays just connect the SPI-bus of the MCU directly to the chip. These types of displays do not need the patch. In fact, they won't even work with the patch.

My patch is not a solution, it is a bad hack for a very specific hardware setup. A real solution would be to introduce a new parameter to one of the core classes. But this would trigger changes on many board-files and introduce code that is of no use for most of the users.

[skerr92]

I mean, either way there seems to be something not working right with any init sequence when using SPI with the ILI9488 devices when using SPI. I've tried with an init sequence derived from the data sheet, from TFT_eSPI (Arduino works), with similar sequences from adjacent displays.

I still tend to think the issue might lay with how bus core is sending the spi data to the display. I've compared sending the same init sequence that works with Arduino, and it's not sending the same data. This is even comparing using ESP32, RP2040, and SAMD51.

[tannewt]

This looks like normal SPI to me:

I think there is a bug on your side. I'd encourage you to use a logic analyzer to compare what CP does to your working Arduino example.

[tannewt]

Now that I say it, this is normal SPI. However the pixel format isn't the normal RGB565 because this is three bytes. CircuitPython doesn't support this layout currently.

[skerr92]

Do you have an idea of what it might look like to support RGB565? I'd be willing to take a look at the addition.

[tannewt]

RGB565 is what we support currently. It is 16 bits.

You'll want something like RGB666 in 24 bits. I think the 3 bytes of 24 bits will be the hardest part because we usually only do power of twos 1, 2, 4 bits and 1, 2 and 4 bytes.

Most of the color conversion code is here:
https://github.com/adafruit/circuitpython/blob/main/shared-module/displayio/ColorConverter.c

You'll likely need to change

circuitpython/shared-module/displayio/TileGrid.c

Line 461 in c47f013

int16_t offset = row_start + (input_pixel.x - start_x + x_shift) * x_stride; // in pixels

too for the 3 byte offsetting.

[bablokb]

The ILI9488 also supports RGB565. That is what I am using. You will find that in the datasheet as well. It is command 0x3a (in the datasheet section 5.2.34. Interface Pixel Format (3Ah)).

I am not sure if RGB666 will make such a difference on these small displays.

[skerr92]

RGB565 is only supported in 8b and 16b data bus. SPI only supports RGB111 and RGB666.

[skerr92]

@tannewt did the PR that was merged 2 months ago that tagged this issue resolve this issue? Specifically, did this target RGB666 SPI mode? If so, can we close this?