ILI9XXX component no longer works with Waveshare Pico-ResTouch-LCD-3.5 or Waveshare 3.5inch RPi LCD (C) boards

[illigtr]

The problem

I had debugged and modified the ILI9XXX to work with these Waveshare colour touchscreen boards during the summer of 2023. I have these displays working flawlessly with text and graphics using the RPI PICO W, the Waveshare ESP32-S2-PICO and Waveshare ESP32-S3-PICO boards. These display boards use the ILI9488 driver with the XPT2046 touch chip. The main issue was the initialisation had width and height reversed. Also the init commands were modified to support 18bit RGB565 and reverse colours. I put these custom patches in the local my_components and every rebuild has worked flawlessly until Dec 2023. It appears major modifications for the ILI9XXX library was well as others have completely kiboshed a working configuration. I have spent days attempting to determine and debug the "release" code as well as the "dev" code, but to no avail. So now I am asking for assistance, especially from code owner @nielsnl68 on what exactly has changed and why this has caused so many issues. From the HA forum and I see numerous similar problems.

Which version of ESPHome has the issue?

2023.12.x

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.12.4

What platform are you using?

ESP32

Board

esp32-s3-devkitc-1

Component causing the issue

ili9xxx

Example YAML snippet

esphome:
  name: "console"
  friendly_name: House Console
  platformio_options:
    board_build.flash_mode: dio

esp32:
  board: esp32-s3-devkitc-1
  #board: esp32s3box
  framework:
    type: esp-idf
    version: recommended
  flash_size: 16MB
  variant: ESP32S3

sensor:
  - platform: internal_temperature
    name: "CPUTemperature"
    id: esp32temp
    update_interval: 10s

color:
  - id: my_black
    red: 0%
    green: 0%
    blue: 0%

  - id: my_red
    red: 100%
    green: 0%
    blue: 0%

  - id: my_magenta
    red: 100%
    green: 0%
    blue: 100%

  - id: my_cyan
    red: 0%
    green: 100%
    blue: 100%

  - id: my_yellow
    red: 100%
    green: 100%
    blue: 0%

font:
# gfonts://family[@weight] Google Fonts
  - file: "gfonts://Roboto"
    id: roboto
    size: 20

  - file:
      type: gfonts
      family: Roboto
      weight: 900
    id: font2
    size: 16

spi:
- id: spi_1
  clk_pin: GPIO35
  mosi_pin: GPIO36
  miso_pin: GPIO37   
  #interface: hardware

display:
#Waveshare PICO 3.5 DISPLAY with ESP32-S3-PICO board.
  - platform: ili9xxx
    model: ILI9488
    spi_id: spi_1
    dc_pin: GPIO33
    cs_pin: GPIO34
    reset_pin: GPIO40
    dimensions: 480x320 
    rotation: 90
    id: ws_tft
    lambda: |-
      it.fill(my_black);
      it.print(0,120,font2, my_cyan,"my_cyan");
      it.print(0,150,font2, my_yellow,"my_yellow");
      it.print(0,180,font2, my_magenta,"my_magenta");
      it.graph(100, 20, id(temperature_graph), my_red);

graph:
  - id: temperature_graph
    duration: 30min
    width: 240
    height: 160
    traces:
      - sensor: esp32temp
        line_type: DASHED
        line_thickness: 1
        color: my_cyan

Anything in the logs that might be useful for us?

No response

Additional information

I am quite willing to test any bug fixes on my various platforms and displays.

[illigtr]

Speed up (and fix) ili9xxx display component. #5406 appears to be when the problem started. There were major changes made to the ili9xxx driver.

[nielsnl68]

please send me the changes you made when it worked before. And i make sure that it will be included in a next release.

[illigtr]

Around August 2023, I started using this ILI9488 display ( https://www.waveshare.com/pico-restouch-lcd-3.5.htm) with the Pi Pico W. Because the Pi Pico is directly mounted on this LCD hat, I am forced to use specific GPIOs for SPI and the LCD. Initially it didn't work at all using ILI9488 as the model, but would work partially using the ILI9486 model. Colours appeared faded and were reversed, and the dimensions had to be set to 320x480 of the screen would not initialise.

I then made a local copy of the ili9xxx driver and began to modify the files.

Initially I created a new model called WSPICOLCD.

In ili9xxx.h I added the following, forcing PIXFMT to 0x66 to force 18 bit display, forcing INVON to 0x80 to inverse the colours, setting MADCTL to 0x48 for correct screen orientation.

static const uint8_t PROGMEM INITCMD_WSPICOLCD[] = {
  ILI9XXX_SLPOUT, 0x80,
  ILI9XXX_PIXFMT, 1, 0x66,
  ILI9XXX_PWCTR1,  2, 0x17, 0x15,  // VRH1 VRH2 -ok
  ILI9XXX_PWCTR2,  1, 0x41,  // VGH, VGL - ok
  ILI9XXX_PWCTR3, 1, 0x44,
  //ILI9XXX_VMCTR1, 4, 0x00, 0x00, 0x00, 0x00,
  ILI9XXX_VMCTR1,  3, 0x00, 0x12, 0x80,    // nVM VCM_REG VCM_REG_EN - not ok?
  ILI9XXX_IFMODE,  1, 0x00, // -ok
  ILI9XXX_FRMCTR1, 1, 0xA0,  // Frame rate = 60Hz -- seems to help the background! -ok
  ILI9XXX_INVCTR,  1, 0x02,  // Display Inversion Control = 2dot - ok
  ILI9XXX_DFUNCTR, 2, 0x02, 0x02, // Nomal scan -ok
  ILI9XXX_ADJCTL3, 4, 0xA9, 0x51, 0x2C, 0x82,  // Adjust Control 3
  ILI9XXX_GMCTRP1,15, 0x00, 0x03, 0x09, 0x08, 0x16, 0x0A, 0x3F, 0x78, 0x4C, 0x09, 0x0A, 0x08, 0x16, 0x1A, 0x0F,
  ILI9XXX_GMCTRN1,15, 0x00, 0x16, 0x19, 0x03, 0x0F, 0x05, 0x32, 0x45, 0x46, 0x04, 0x0E, 0x0D, 0x35, 0x37, 0x0F,

  ILI9XXX_INVON, 0x80,
  ILI9XXX_MADCTL, 1, 0x48,
  ILI9XXX_DISPON, 0x80,
  0x00                                   // End of list
};

In display.py add to MODELS = {

        "WSPICOLCD": ili9XXX_ns.class_("ILI9XXXWSPICOLCD", ili9XXXSPI),

In ili9xxx_display.cpp added: (forcing initialisation to 320x480)

//TFT Display - Waveshare Pico Touch 3.5
void ILI9XXXWSPICOLCD::initialize() {
  this->init_lcd_(INITCMD_WSPICOLCD);
  if (this->width_ == 0) {
    this->width_ = 320;
  }
  if (this->height_ == 0) {
    this->height_ = 480;
  }
  this->is_18bitdisplay_ = true;
}

In ili9xxx_diplay.h add:

//-----------   Waveshare Pico LCD 3.5 inch rotated display --------------
class ILI9XXXWSPICOLCD

 : public ILI9XXXDisplay {
 protected:
  void initialize() override;
};

This configuration worked perfectly. I also was able to test this configuration using 2 ESP models that Waveshare sells that have identical pins for the LCD HAT. They are the ESP32-S2-PICO and the ESP32-S3-PICO, although in both cases the GPIOs and LCD GPIOs need to be updated to match the LCD hat connections. Again, everything worked in both text and graphics mode.

The only necessary configuration in the YAML was to set orientation to 90 and ensure that the data_rate did not exceed 20 Mhz.

The configurations also worked whether or not PSRAM was enabled and/or even available. I have seen considerable commentary that PSRAM is required due to larger buffers, but I believe this should not be the case. I have been able to use these displays (inluding the Waveshare RPi 3.5 inch LCD version C) with a bareboard ESP32-WROOM (chip is ESP32-D0WDQ6 rev v1.0) under Arduino using the Bodmer's amazing TFT_eSPI library. No PSRAM is used and yet I can fully control the display text and graphics.

Further testing has allowed me to reducedthe absolute minimum necessary changes to the ili9488 to:

1. INIT string --> force INVON, force PIXFMT to 18bit, force MADCTL to 90 degree, 320x480 orientation.
2. In the initialize, ensure 320x480, 18bit
3. in YAML, set rotation: 90, dimentsions: 320x480, data_rate: 20Mhz

All of this worked UNTIL PR 5406 was merged.

In looking at the new driver code I can see that INVON is now configurable in YAML, as well as hardware orientation with transform: which appears to set the value of MADCTL. Also inversing colours is now in the initialize() of the display. Using ESP Home DEV for HA, I have tried to only change the parameters in the YAML without tinkering with the driver itself. However, no combination of settings will initialise the display.

I am quite will to provide additional log files, info, test YAMLs, Arduino sketches, etc. as required. My test setups include the following MCUs:

1. Raspberry Pi Pico W
2. Waveshare ESP32-S2-PICO (https://www.waveshare.com/wiki/ESP32-S2-Pico)
3. Waveshare ESP32-S3-PICO (https://www.waveshare.com/wiki/ESP32-S3-Pico)
4. diymore.cc ESP32 Dev Board (https://www.diymore.cc/collections/esp8266/products/esp32-esp-wroom-32-revision-1-rev1-development-board-wifi-bluetooth-breadboard-diy-electronice-kit)
5. Waveshare ESP32-S3-WROOM-1-N8R8 (https://www.waveshare.com/wiki/ESP32-S3-DEV-KIT-N8R8)

The displays I am using:

1. Waveshare Pico-ResTouch-LCD-3.5 ( https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5)
2. Waveshare 3.5inch RPi LCD rev C (https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(C))

[illigtr]

One additional note: The Pico-ResTouch-LCD-3.5 does require colour inversion, but the 3.5inch RPi LCD rev C does not. They both are ILI9488 based. As a suggestion, I think hard coding inversion into the initialisation sequence is not a good idea, if it cannot be overwritten by the YAML configuration. According to https://next.esphome.io/components/display/ili9xxx, "invert_colors (Optional): With this boolean option you can invert the display colors. Note some of the displays have this option set automatically to true and can’t be changed."

[illigtr]

Is there any possibility to roll back changes to prior to November 27th, 2023. ThIs is a MAJOR ISSUE as all my ESPhome touch displays are not working since that date. From what I can see there has NOT been any significant work on these drivers. All my development is at a standstill. One additional note is that these issues may be related to changed made around the same to SPI component. There are open issues out there that SPI is causing issues for other users around the same update. Issue #5678 committed one day prior, November 26th, 2023.

[illigtr]

An alternative stop-gap solution is giving an example of how I can compile with a version of ESPHome prior to Nov 26th from inside a YAML configuration as I use HA with the ESPHome plugins (main and dev).

[illigtr]

I have finally been able to rebuild my displays to working order (at least for now, until the drivers are fixed). This is the minimal configuration that works with the ESP32-S3-PICO and Pico-ResTouch-LCD-3.5

Steps to recreate a working display, with touch.

1. Install a local copy of Python and ESPHome (windows platform).
2. Do not install current version of ESPHome, instead install from archive 2023.11.6.zip
3. Create a config/my_components folder and copy the ili9xxx directory to it
4. Modify the ili9xxx_display.cpp section for ILI9488 a. swap the 320/480 around for width and height b. add -> this->preinvertdisplay = true;
5. Modify the ili9xxx.h section fof ILI9488 a. change ILI9XXX_MADCTL value from 0x28 to 0x48
6. In the YAML under plaform: ili9xxx a. model: ILI9488 b. dimensions: 320X480 c. rotation: 90 d: data_rate: 20 Mhz //do not exceed

This results in a fully functional display with touch support. Colours are corrected, display and orientation is correct. Graphics render correctly.

Hopefully this information helps to finally make the current DEV drivers once again fully compatible with these ILI9488 displays.

[yazz007]

I have dual displays 4inch TFT Touch Shield (ILI9486 driver) which worked fine in 2023.11.2 and when updated to 2023.12.x both shows white screens and I couldn't make it to work. I found this issue and I think #5406 is the root cause of my problem. I reverted back to 2023.11.2 and it's still works fine....

[illigtr]

The white screen behaviour is identical to my situation since merge of #5406. I am back at 2023.11.6 so I can continue to develop.

[nielsnl68]

Sorry to read your issues @Illigtr. I created a PR https://github.com/esphome/esphome/pull/6078 based on the changes you shown above. Would you mind testing it for me?

[nielsnl68]

I have dual displays 4inch TFT Touch Shield (ILI9486 driver) which worked fine in 2023.11.2 and when updated to 2023.12.x both shows white screens and I couldn't make it to work. I found this issue and I think #5406 is the root cause of my problem. I reverted back to 2023.11.2 and it's still works fine....

Could you mind creating a new Issue and add the following test: https://esphome.io/components/display/#troubleshooting

[illigtr]

Yes, I can try that today and return the results.

[illigtr]

Testing completed with PR6078. Issue not resolved, on reboot screen goes black, white, black, grey... and stays with a grey background. I have included my yaml and the debug log.

logs_console_run(1).txt console.yaml.txt

[nielsnl68]

can you please test it with https://esphome.io/components/display/#troubleshooting and show the the screenshot or better short video.

btw,: you need to use model: WSPICOLCD ;)

[illigtr]

I already added the troubleshooting lambda code to my yaml config. However, I did not use model WSPICOLCD. Will do that now and create a short video.

[illigtr]

Here is the result using WSPICOLCD . I tried swapping dimensions and rotation, no difference, always ends in grey screen. Attached is log file, video of display working under ESPHome 2023.11.6 with my mods per earlier post as well as video with current configuration under ESPHome DEV and PR6078. I am resetting twice with same end result.

https://github.com/esphome/issues/assets/120117710/bf4e4378-630a-4c19-a5c8-ed770d8afc6b

https://github.com/esphome/issues/assets/120117710/94eb2845-290c-454a-863f-dae77464095e

logs_console_logs.txt console1.yaml.txt

[nielsnl68]

the videos dont working sorry

[illigtr]

I just tried them after upload, works here. I could resize and rotate and reload.

On Thu, Jan 11, 2024, 12:11 nielsnl68 @.***> wrote:

the videos dont working sorry

— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5324#issuecomment-1887602093, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4UNTTXF2WWEP3HDW3JJZHTYOAMMVAVCNFSM6AAAAABBIRU2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXGYYDEMBZGM . You are receiving this because you were mentioned.Message ID: @.***>

[nielsnl68]

ha yes, after page reload the video's work indeed. What is the second video? Could you please create a new and clean YAML file with just the display, esphome, esp32 and noting else. Just to be sure that noting is interfering with the display.

EDIT: also please use the default settings for the esp32 and esphome components.

esphome:
  name: "console"
  friendly_name: House Console

esp32:
  board: esp32-s3-devkitc-1
  framework:
    type: arduino
  flash_size: 16MB
  variant: ESP32S3

[illigtr]

The results are the same. Grey background screen. Included is the minimal YAML as well as the logs. Could this be related to the changes in SPI component around the same time. SPI was changed to allow variable block transmission, and your code also has changes in the way data is sent via SPI...

console2.logs.txt console2.yaml.txt

[nielsnl68]

can you please remove version: latest Also can you show me how you connected the display to the esp32s3?
From the look of it you are using pin's that are used for the PSRAM.

[illigtr]

Ok, I will remove version: latest. I send a photo of the underside of the panel. Please see references to the Waveshare product wiki already described above.

As for PSRAM pins, I cannot control that, as I have already mentionned since this display is a HAT for the ESP32-S3-PICO board. In addition this board/display ran fine before Dec 2023....

[illigtr]

Test run without version setting in framework. Same grey screen results. Photo of backside of Pico LCD hat included. NOTE!!!! --> the GP assignments on the document in the photo are for the PI PICO W. GP assignments in YAML are per specs of the ESP32-S3-PICO. All links previously documented earlier in this issue.

[nielsnl68]

This morning I have been reading into the esp32-S3R2 and the used display. From my understanding now the pins are used correctly. The warnings are just for 8MB PSRAM's. So that is okay.

Reading the display documentation it states it used the 16Bit RGB565 interface. Did you try that already?

I do not see any other thing that could be wrong.

[illigtr]

Yes I did know it was 16Bit RGB565, that is how I started modifiying the existing drivers last August 2023. I used Bodmer's eSPI_TFT library, which works flawlessly with this display and then stepped through all the source code to get all the paramaters needed for initialisation. As I mentionned previously, I was able to subsequently boil down the changes to just a few tweaks mentionned here: https://github.com/esphome/issues/issues/5324#issuecomment-1884137020

[illigtr]

Question. Were the drivers prior to Dec 2023 using PSRAM exclusively? Or could the ILI9XXX use any RAM for the video buffer is enough was available? Is there a way to test if this is an SPI related issue, with the SPI component?

[nielsnl68]

Could you ping me on Discord: https://discord.com/channels/429907082951524364/1119046373543780363 Then we can discuss your question and possible fixes there.

[illigtr]

Could you ping me on Discord: https://discord.com/channels/429907082951524364/1119046373543780363 Then we can discuss your question and possible fixes there.

I'm a newbie to discord, had to ask my son for a crash course. I have an account and I'll try to figure out how to ping you on the channel.

[illigtr]

Further testing using Pi Pico W & Waveshare Pico Res-Touch 3.5 (ILI9488). Under ESPHome 2023.11.6, using customised component (https://github.com/esphome/issues/issues/5324#issuecomment-1884137020) , I have a working display. This is interesting, since there is no PSRAM, and Pi Pico W has only 2 MB flash, meaning OTA partitions are restricted to only 1MB, and the entire WiFi microcode has to be loaded to RAM...

[clydebarrow]

I'm the primary author of the recent changes to the ili9xxx driver so I would like to get this resolved.

Could you please clarify a few things - here's my understanding from reading the above, please correct and expand so I can understand the problem:

1. You have a customised ili9xxx component that works on your displays with ESPHome 2023.11.??
2. The standard ili9xxx component did not work with your displays at any time
3. The updated ili9xxx component in dev still does not work with your component
4. Does your custom component still work with ESPHome dev if you use it as an external component?
5. Do you have a repository somewhere with the complete code for your custom component?

A few points:

1. The MADCTL contents and display inversion are configurable in YAML - getting this wrong might cause colour or rotation issues, but not a grey screen.
2. The GPIO pins should be a non-issue - whatever used to work should still work (but see below about MISO)
3. Display height and width are configurable in the YAML. Note that these should be set to the final dimensions after transform.
4. SPI speed is configurable in the YAML I see you have set that to 20MHz so that should be a non-issue.
5. SPI mode is also configurable in the YAML - some displays need mode 0 (the default IIRC) and some need mode 3. Have you tried both?
6. You have a MISO pin configured in your SPI - you should remove that as it is not required or used, and can cause initialisation issues with ESP-IDF.
7. 18 bit mode is not currently configurable in YAML, so relies on it being set in the init sequence for a given display, but both ILI9488 model choices already set 18 bit mode.
8. You can't use rotation with transform but transform should be able to get the display to the right format.

At this stage I would suggest that removing MISO and trying SPIO mode 3 would be helpful, but I'm happy to look further if you can respond to my questions above (though it would probably be Monday before I can do much more.)

[nielsnl68]

@clydebarrow, @illigtr and i have moved the conversation to Discord. for faster communication etc. In pr#6078 i added the option to set the 18bit mode and added his display settings. He needs the MISO to communicate with the XPT2046.

[illigtr]

Hi Clyde, thank you for engaging on this topic. Since you have a list of questions, I'll answer them here and if we need a conversation, we can switch to Discord. Seeing as it is the weekend and I am in the northeast of NA with a snowstorm, I doubt much will happen until next week. Here are my answers

Q.You have a customised ili9xxx component that works on your displays with ESPHome 2023.11.??

A. Yes, but the customisation started earlier, August 2023. I was attempting to get my Waveshare Pi Pico W and Waveshare Pico-Restouch-3.5 display ( https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5) to work with ESPHome. No such luck. The combination works fine in Arduino IDE using earlephilhower library and Bodmer's excellent TFT_eSPI driver. I switched to the ESP32-S2-PICO (https://www.waveshare.com/wiki/ESP32-S2-Pico) and even the ESP32-S3-PICO (https://www.waveshare.com/wiki/ESP32-S3-Pico) which is pin compatible with the display HAT. I tested nearly every display model offered by the ili9xxx driver. I finally stumbled on a combination of model: ILI9486 with YAML resolution:320X480 and rotation:90. This wasn't perfect, the display colours were reversed and what I had for colours looked washed out.

I decided to review the ili9xxx code and compare it to the Bodmer code, especially the initialsation sequence sent to the display. I made a copy of the ILI9486 init sequences under a new model name. By tweaking the ILI9XXX_INVON, ILI9XXX_MADCTL, ILI9XXX_PIXFMT I was able to get the display fully functional. I also made a copy of the SPI component because I wanted to test more SPI frequencies that were actually available. Finally, however, it turns out that 20Mhz gave the best results. I kept my customised ili9xxx in a local my_components folder and somewhat forgot about until December when I want to recompile some additional code. It broke the working MCU/display combination. That's when I realised that significant changes had been made to both the spi and ili9xxx components.

Q.The standard ili9xxx component did not work with your displays at any time

A. Correct, except as mentionned I had partial success with ILI9486 model (August 2023).

Q.The updated ili9xxx component in dev still does not work with your component

A. Correct, I use ESPHome inside of HA (Pi4 host). I also keep an ESPHome (dev) in HA when something doesn't work quite right. However, no amount of testing, tweaking, paramter combinations has ever lead to the displays working since Dec 2023.

For what its worth, my tweaks have all been incorporated into the latest version of the drivers. This includes inversion control, 18bit display and MADCTL control via transform. So, in theory, I should be able to use the new display driver, but I have not been able to get the displays to work, other than a greyish background with no other activity. There are others in the ESPHome community who have similiar issues with ili9488 displays, all occurring after 2023.11.6 release of esphome.

Q. Does your custom component still work with ESPHome dev if you use it as an external component?

A. I tried, and no, and it can't. The init.py and display.py have changed dramatically as well, certain parameters have been pulled up higher in the chain, so I'd have to modify far more of the esphome code to get my old tweaks to work. Additionally the core code for the display handles the data stream via SPI in a different manner,

Q. Do you have a repository somewhere with the complete code for your custom component?

A. No, but the changes have been distilled to only this: (using the ili9xxx from 2023.11.6 release of esphome). https://github.com/esphome/issues/issues/5324#issuecomment-1884137020. I could copy my custom component to a repository if necessary.

You: The MADCTL contents and display inversion are configurable in YAML - getting this wrong might cause colour or rotation issues, but not a grey screen.

Me: Yes, I am aware of that in the current release, but this was not the case prior to Dec 2023. MADCTL was managed only in the init sequence. I have already tried several parameter changes (software rotation off, using only transform) with the latest drivers that should result in the same MADCTL value as I had hardcoded in my custom component. No combination proved succesful.

You:The GPIO pins should be a non-issue - whatever used to work should still work (but see below about MISO) Me: MISO used for touch XPT2046

You: Display height and width are configurable in the YAML. Note that these should be set to the final dimensions after transform. Me: Have tested as such.

Q: SPI speed is configurable in the YAML I see you have set that to 20MHz so that should be a non-issue. SPI mode is also configurable in the YAML - some displays need mode 0 (the default IIRC) and some need mode 3. Have you tried both?

A. I have tested all modes of SPI, all frequencies, even different SPI controllers on the S2 and S3, as well as the Pi Pico. No combinaation with esphome dev has resulted in a working display.

You: You have a MISO pin configured in your SPI - you should remove that as it is not required or used, and can cause initialisation issues with ESP-IDF. Me: Understood

You: 18 bit mode is not currently configurable in YAML, so relies on it being set in the init sequence for a given display, but both ILI9488 model choices already set 18 bit mode. You can't use rotation with transform but transform should be able to get the display to the right format.

Me: I am aware

You: At this stage I would suggest that removing MISO and trying SPIO mode 3 would be helpful, but I'm happy to look further if you can respond to my questions above (though it would probably be Monday before I can do much more.)

Me: Thanks. I have already tried these changes.

[illigtr]

This issue is NOT resolved! All tests with new drivers and new parameters fail.

[clydebarrow]

I have one of these displays on it's way to me, to add to my collection. Will be a few days before I have it, then should not take long to sort out.

[clydebarrow]

I have the display and have reproduced some of the results. I do get a grey screen with the latest code, but with the older code, even with the changes as above for "WSPICOLCD" I get nothing.

Will report again here when I get further (likely next week.)

[illigtr]

Thanks Clyde for the update. I wouldn't use WSPICOLCD, I never wanted or asked for this. @nielsnl68 created it for testing, but as I have mentionned I was able to reduce all my mods to a few tweaks in the existing ILI9488 init. In addition, since August 2023, all of the introduced tweaks are now part of standard code and/or YAML configuration parameters. I still have the display running under 2023.11.6 (including the original ili9xxx driver) release of esphome along with my minor tweaks.

The only thing I hope you take as a request, is that colour inversion NOT be hard coded to the display initialisation, or, if it is, that the YAML parameter can indeed override it. This will allow users, like myself, to use both the Pico ResTouch 3.5 which requires inversion and the RPi 3.5 LCD ver C which does NOT require inversion. Both are identical ILI9488 displays by Waveshare.

[clydebarrow]

The only thing I hope you take as a request, is that colour inversion NOT be hard coded to the display initialisation

That's already the case, invert_colors: controls that.

I have progressed to the stage of getting data on the display, there is one remaining issue with partial redraw. Probably won't have time for that until Monday.

Interestingly it works in 16 bit mode as well as 18bit (Pico ResTouch 3.5) which makes it a lot faster.

[illigtr]

Excellent, appreciated news. I look forward to testing the final driver. I'd be curious to know where the issue lies and how you resolved it once you have a final version. I was about to send you logic analyzer traces...

[clydebarrow]

The major issue seemed to be that the chip needs CS driven false between command and data writes.

Try this - not working right for me yet, but does show stuff on the display.

external_components:
  - source: github://clydebarrow/esphome@i9488
    refresh: 10min
    components: [ ili9xxx ]

[clydebarrow]

The problem right now is that the CASET and PASET commands don't seem to be working - yet other commands are clearly working.

[illigtr]

I'll test that. Would the old drivers have driven CS like that?

this from the their wiki page: "D/CX (LCD_DC): chip data/command control pin, writing command when DC = 0, writing data when DC=1."

https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5

[clydebarrow]

DC is a different control line (DATA/COMMAND), CS selects the chip for SPI. Most display chips will work with CS asserted once at the beginning of a sequence of commands, this one apparently not. Yes, that behaviour did change.

[illigtr]

Ah yes, understood. Have tested your github://clydebarrow/esphome@i9488 and finally do have some display results, albeit, mangled. Nice progress. :)

[illigtr]

I have a workable display, albeit reversed. Switching from rotation to transform (all possible combinations) results in an unreadable font display. Attached YAML console.yaml.txt

[clydebarrow]

Can you attach an screenshot of the mangled version? There is something wrong there still.

[illigtr]

Here are the results of dozens of tests using various combinations of parameters.

Environment

• Waveshare ESP32-S3-PICO
• Waveshare Pico Res-Touch 3.5 LCD display HAT
• ESPHome DEV inside of HA latest version

Two tests, with YAML and video.

Test 1 - Hardware Rotation

• transform: false, true, true
• dimensions: 320X480
• results: incorrect colours, except for black, screen orientation incorrect, but readable, text mirrored.

Test 2 - Software Rotation

• rotation: 90
• dimensions: 320X480
• results: incorrect colours, except for black, screen orientation incorrect, but readable, text mirrored.

OTHER OBSERVATIONS Using hardware rotation I tried all combinations of the 3 parameters, none resulted in anything better than test#1. Also to note that dimensions HAD to be 320X480, even though I expected the opposite. Trying to fix the reversed text with transform lead the image to only be partly display, regardless of dimensions set portrait or landscape.

Using software rotation produced the best results, EXCEPT text was reversed somehow. I couldn't fix transform as I was using rotation.

Attempting to fix colours with invert_colors: true resulted in no difference, trying with invert_colors: false fixed colours BUT NOT BLACK, which became WHITE?!

FILES:

test1.txt test2.txt

https://github.com/esphome/issues/assets/120117710/c46982a5-7f62-445e-a23a-1aa1980ed3f9

https://github.com/esphome/issues/assets/120117710/c300ac38-4f92-4635-8f41-ae9b9649be13

[illigtr]

I was able to determine the color issue. I believe you were testing 16it (ILI9XXX_PIXFMT), which works but renders the wrong colors. Putting back ILI9XXX_PIXFMT, 1, 0x66, renders all colours correctly. I made a copy of your github://clydebarrow/esphome@i9488 and put in into my local /my_components and started to test various mods. I now have the text colours and orientation corrected in software rotation... attempting hardware rotation next.

[nielsnl68]

can you share the changes so other people could use it as well?

[illigtr]

That would be premature... These tests are destined to assist Clyde in finalising the driver. Nonetheless, I continue to test hardware rotation. If I get anything working to at least the functionality we had before Dec 2023, then I'll post all details.

[clydebarrow]

I have come to the conclusion that the Waveshare display does not actually use an ILI9488. It appears to have a driver chip that resembles an ILI9488 but behaves differently (I have been testing against the ILI9488 datasheet.)

I can certainly restore the functionality that existed before the recent changes to the ili9xxx driver, but it will never work like a real ILI9488. In particular the swap_x_y is unusable (so requires software rotation for 90 and 270) and partial screen updates will not work. The good news is that the speed improvements the ili9xxx changes brought for 18 bit mode are applicable. Stand by for a proper fix.