ILI9488 display on ESP32S3 initializes, but has no image

[phreakocious]

Using one of these ILI9488 based boards with this hardware_setup.py. After importing gui.demos.simple, the screen is definitely reset as the backlight will dim a bit, but no graphics are displayed. Touch does work, however. The 18bit versions of the ILI9486 drivers for Arduino seem to work, so possibly it's related to that? Any pointers on things to test would be appreciated.

[peterhinch]

It's hard to support hardware I don't possess.

Your SPI connections look correct, but it's always worth trying soft SPI. It's also worth trying the test script as it can indicate the cause of errors - however in your case this is a long shot as the display is blank. Another long shot is to issue

SSD.COLOR_INVERT = 0xFFFF  # Fix color inversion

in hardware_setup.py after instantiating SSD. This has proved necessary on some ILI9488 displays.

As a general comment, different display manufacturers connect the LCD to the display controller in different ways, requiring corresponding firmware changes. Implementing these can be difficult. However a completely blank display is uncommon and usually signifies a wiring error or other hardware problem.

[phreakocious]

Thanks for the feedback and totally understand on the supportability. I modifed the interface pixel format from 0x55 to 0x66 to match the Arduino driver and got partial functionality:

Now that there is actual output, it should be easier to make progress.

[phreakocious]

After fixing the screen dimensions and trying the test script, something is still amiss. Suspecting it has to do with the color format being RGB565 vs RGB666 causing not enough bytes being sent to fill the framebuffer, but still digging.

[peterhinch]

You definitely need to set the chip up for rgb565. 18-bit mode would involve substantial modifications to the driver.

The color errors where a single pixel is displaying as multiple is unusual - perhaps the display is in 18bit mode? As a general point, if you can get the test script to produce pixel-perfect results, you can be highly confident that everything else will work.

[phreakocious]

Yep, that would be best, but it seems the display will only fully come up when set for 18-bit. It is mostly working now with a much simpler driver, but the performance is awful since it writes directly. The viper code in your driver is much faster, but I haven't fully grokked how the color and framebuf lookup stuff is working to adapt it.

[phreakocious]

Added a function to convert the color layout before writing to SPI. Largely lifted from your style to keep it in viper. Some issues with colors not rendering properly, but this bodge has it pretty close.

[peterhinch]

Well congratulations on getting it working, but it's very odd that RGB565 doesn't work. I've never heard of this before - I wonder if the chip is a clone?

[phreakocious]

If I understand the datasheet correctly, the driver chip can work with a number of different displays, with various connection and configuration options to support them. I tried all of the different possibilities just to see what would work and with this module, only the one option does. In researching this issue, there are others running into it, so it will be nice to have a solution.

[peterhinch]

I find the failure to work in 16 bit mode very surprising.

If you find a full solution please let me know: I could put a link to this issue in the drivers doc.