gdisp_lld_ILI9341.c: Hardware reset not working properly in gdisp_lld_init

[Paul Christopher]

See https://forum.arduino.cc/index.php?topic=473378.0 . I had quite some trouble getting a cheap Chinese ILI9341 based display work with µGFX, ESP32 on Arduino IDE.

The code compiled fine, the program ran fine, but I only got a white screen. No startup logo, no drawings, just a white screen.

It took me quite some time to figure this out: For some of these cheap displays, its seems to be crucial to get a proper hardware reset in the beginning. Otherwise they won't output anything.

To make it work, I had to change µGFX core, i. e. gdisp_lld_ILI9341.c.

I replaced the given code in gdisp_lld_init for the hardware reset

// Hardware reset
setpin_reset(g, TRUE);
gfxSleepMilliseconds(20);
setpin_reset(g, FALSE);
gfxSleepMilliseconds(20);

with this piece of apparently well tested code from the adafruit_ili9341 library https://github.com/adafruit/Adafruit_ILI9341/blob/master/Adafruit_ILI9341.cpp#L326 :

// Hardware reset
setpin_reset(g, TRUE);
delay(100);
setpin_reset(g, FALSE);
delay(100);
setpin_reset(g, TRUE);
delay(200);

All in all, this might raise some fundamental design issue for driver and board files, since resetting the display seems to be display/board specific -- although the driver / display chip might be the same.

Or to put it in other words: Wouldn't it be better, that the board file exposes a simple "void hardware_reset (void)" function which is just called from the driver's gdisp_lld_init function (instead of doing the pin toggling with the MCU / board dependent delays in the driver)?

[inmarket]

First note that the sense of the parameter between uGFX and the adafruit code is reversed.

Second, the startup reset delays for a controller chip are normally documented in the controller data sheet is. It is a controller specific property once the power supply is stable (which it definitely should be by this code stage).

So, in this case there are three possible problems...

1. Whoever wrote the board file didn't notice the parameter is logical level not pin level and was therefore holding the controller in the reset state, or

2. The driver writer did not include delays as per the dataset, or

3. The controller is a cheap Chinese equivalent with significantly different speed properties.

 

Nevertheless, your idea of making it a single board level routine has some merit. I will look at how it can be used in V3 which uses a gBus module for all io of this type.