ILI9341_2_DRIVER versus ILI9341_DRIVER quality issues

[infrafast]

Hello, I am using a TFT 2.8" ILI9341 based screen without touch feature

This model:

https://fr.aliexpress.com/item/4000832671813.html?pdp_npi=2%40dis%21USD%21US%20%242.02%21US%20%241.78%21%21%21%21%21%40211b5dec16538326276142269e8f8b%21%21im&gatewayAdapt=glo2fra

I have been provided two variant : GMT028-01 and GMT028-05

During COVID and after the whole component supply chain has been screwup with the consequence we know, The variant 01 was provided which works perfectly with the ILI9341_DRIVER

They have changed to this 05 version which is uncompatible with the ILI9341_DRIVER and by doing some research I saw that the ILI9341_2_DRIVER does the job.

Here is the problem:
using ILI9341_2_DRIVER , there is really a difference with the colors and contrast rendering. I suspect a HW chip problem or screen matrix but this may be due to the driver , for instance they way it manages colors depth? (some document mention that the ILI9341 can works either 65K or 262K colors , see : https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf)

I post pictures so you can see the difference.

My code render alternatively a jpeg test screen and to be sure that this is not due to the jpeg decoding library, I also do a test by displaying raw pixels, results are the same.

Issue is indpendant from the IDE (tested and occurs both with Arduino IDE and PLatform IO)

Library and setup as following:
PLATFORM: Espressif 8266 (4.0.1) > WeMos D1 R2 and mini
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES:

• framework-arduinoespressif8266 @ 3.30002.0 (3.0.2)
• toolchain-xtensa @ 2.100300.210717 (10.3.0)
• TFT_eSPI @ 2.4.76

I have contacted the chinese provider (TZT) from ali express but obviously there is nothing we can expect from them as they even do not want to recognize the problem, keepiing replying that they dont see the quality problem.

Thanks for your support

[Bodmer]

It appears that -05 screen requires a special init setup, this defines the pixel voltages and gamma settings that affect the pixel colour.

If you can get the init sequence from the supplier then I can look at adding it.

[infrafast]

Ok, I found the fix

in the ili9341_init.h the second Set Gamma of ILI9341_2_DRIVER (Line 211) which is 0XE1 should be changed to 0XE0

writecommand(0XE0); //Set Gamma

this fix the problem for chip where you need to have both ILI9341_2_DRIVER and call tft.invertDisplay(1);
if you apply this patch for case where you need ILI9341_2_DRIVER without having to call tft.invertDisplay(1) , you will face the issue as well.

So in order to cover all cases and be able to instantiate drivers dynamically at run time (because my soft operate different TFT screen), the best workaround I found would be to to change line 220 to the following:

if (INVERTED_SCREEN) writecommand(0XE0); //Set Gamma when tft.invertDisplay
else writecommand(0XE1); //Set Gamma for other cases

My tests were done on v2.4.76 and v2.4.77, I didn't check for the very latest but presumably the driver init should be equal.

Unfortunately, the INVERTED_SCREEN condition would require the test of a private boolean which should be set by the invertDisplay() , which requires the library to be updated. Is it something you can consider ?

Thank you very much.

ps: alternative as there are 2 consecutive call to writecommand(0xE0); //Set Gamma I assume that only the second one would make sense for the case where screen is inverted....

[Bodmer]

This change works, but it is rather odd. This means the values intended for the Negative Gamma Correction registers are being loaded into the Positive Gamma Correction registers, over-riding the previously loaded values. This probably works more by luck.

I suspect the gama control registers may already be pre-loaded with sensible values after reset. In this case commenting out all lines from 193 to 227 may have the same effect.

[infrafast]

OK thanks I will test and post any usful outcome here

[infrafast]

Hello Bodmer, I will implement my fix in my local environment but I'd be grateful if you could trigger me if and when you implement a fix so I can hook again my dev platform to the GitHub repo and stay up to date. Thanks!

[Bodmer]

Given the bespoke nature of this change I would rather not make any changes to the library at this time.

[infrafast]

Ok thanks I will live with that and monitor the library update to sync.

[infrafast]

Just to add : I recently made some test and found out that

• the problem I initially describes happens only when having RST Pin connected to VCC and using TFT_RST = -1
• using the fix I proposed, you can completely switch off the screen (using a MOFSET for instance) , it obviously turn black and when you put back the power, the screen continues to work without to have it to reinit. It means it could be a way to implement a very efficient "sleep" or "power saving"