ILI9XXX component no longer works with Waveshare Pico-ResTouch-LCD-3.5 or Waveshare 3.5inch RPi LCD (C) boards #5324
Comments
|
Speed up (and fix) ili9xxx display component. #5406 appears to be when the problem started. There were major changes made to the ili9xxx driver. |
|
please send me the changes you made when it worked before. And i make sure that it will be included in a next release. |
|
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.In display.py add to MODELS = {In ili9xxx_display.cpp added: (forcing initialisation to 320x480)In ili9xxx_diplay.h add: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:
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:
The displays I am using:
|
|
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." |
|
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. |
|
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). |
|
I have finally been able to rebuild my displays to working order (at least for now, until the drivers are fixed). Steps to recreate a working display, with touch.
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. |
|
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.... |
|
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. |
|
Sorry to read your issues @illigtr. |
Could you mind creating a new Issue and add the following test: https://esphome.io/components/display/#troubleshooting |
|
Yes, I can try that today and return the results. |
|
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. |
|
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 ;) |
|
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. |
|
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. 20240111_114449.mp420240111_115203.mp4 |
|
the videos dont working sorry |
|
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
<#5324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A4UNTTXF2WWEP3HDW3JJZHTYOAMMVAVCNFSM6AAAAABBIRU2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXGYYDEMBZGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
ha yes, after page reload the video's work indeed. 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 |
|
The results are the same. Grey background screen. Included is the minimal YAML as well as the logs. |
|
can you please remove |
|
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.... |
|
Test run without version setting in framework. Same grey screen results. Photo of backside of Pico LCD hat included.
|
|
This morning I have been reading into the esp32-S3R2 and the used display. Reading the display documentation it states it used the 16Bit RGB565 interface. I do not see any other thing that could be wrong. |
|
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: #5324 (comment) |
|
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? |
|
Could you ping me on Discord: https://discord.com/channels/429907082951524364/1119046373543780363 |
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. |
|
Further testing using Pi Pico W & Waveshare Pico Res-Touch 3.5 (ILI9488). Under ESPHome 2023.11.6, using customised component (#5324 (comment)) , 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... |
|
This issue is NOT resolved! All tests with new drivers and new parameters fail. |
|
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. |
|
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.) |
|
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. |
That's already the case, I have progressed to the stage of getting data on the display, there is one remaining issue with partial redraw. Interestingly it works in 16 bit mode as well as 18bit (Pico ResTouch 3.5) which makes it a lot faster. |
|
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... |
|
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. |
|
The problem right now is that the CASET and PASET commands don't seem to be working - yet other commands are clearly working. |
|
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." |
|
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. |
|
Ah yes, understood. Have tested your github://clydebarrow/esphome@i9488 and finally do have some display results, albeit, mangled. Nice progress. :) |
|
I have a workable display, albeit reversed. Switching from rotation to transform (all possible combinations) results in an unreadable font display. Attached YAML |
|
Can you attach an screenshot of the mangled version? There is something wrong there still. |
|
Here are the results of dozens of tests using various combinations of parameters. Environment
Two tests, with YAML and video. Test 1 - Hardware Rotation
Test 2 - Software Rotation
OTHER OBSERVATIONS 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.mp4test2.mp4 |
|
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. |
|
can you share the changes so other people could use it as well? |
|
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. |
|
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. |
|
Ok, That's great. Further tweaking and I have the display fully working in software rotation mode. Colours are correct, orientation is correct and fonts working. I will test my other Waveshare RPi LCD version C as well. |
|
Tested ESP32-S3-PICO with Res-Touch 3.5 LCD. Also working well with software rotation. I forced these 2 initcmds: ILI9XXX_MADCTL, 1, 0x48, ILI9XXX_PIXFMT, 1, 0x66, Colours are correct, orientation is correct and fonts working. |
|
This is now all working nicely, with full functionality. The main issue was that "this is an ILI9488, but not as we know it, Jim." The Waveshare board does use an ILI9488, contrary to my previous conclusion, but it does not use the ILI9488 SPI interface. Instead it has a 16 bit shift register (using 74HC logic!) that drives the ILI9488 16 bit parallel interface. This is presumably to achieve higher speeds than the native SPI can manage. This makes a difference in the way the registers have to be programmed, but also means that 16 bit mode is supported (which apparently the native SPI does not.) Also, the ILI9488 does not behave in the same way as other ILI series chips when it comes to hardware mirroring and rotation - it requires two separate registers to be programmed in conjunction. Anyway, all the problems are solved. Waveshare say the interface will run at up to 70MHz, but I found that on my ESP32 setup with DuPont wires 20MHz was the maximum that worked - above that there were colour artifacts in the display. I did successfully test it on a PICO-W supposedly at 80MHz but I have no idea if the SPI was actually running at that speed (it did not seem particularly fast.) ESP32 config: |
|
Thanks Clyde. I tested the your latest source: github://clydebarrow/esphome@i9488 I was not able to test with my Waveshare RPi 3.5 inch LCD version C. I may have scrapped the display as it only shows a white screen even under a known, good, Arduino code test using Bodmer's TFT_eSPI driver. I also appear to have scrapped one of two ESP32-S3-PICO boards in the process. At least these components are relatively inexpensive. From my end I think we can confidently close this issue. Many, many thanks for your persistence is resolving this issue. I am hoping it resolves other related open tickets and HA/ESPHome forum comments on display issues since 2023.11.06 release. Hope these new changes make it release status in the future. One final note, perhaps off topic: Considering the growing community of HA and ESPHome users, it is possible for changes to drivers to be tested by opt-in participants prior to release? It appears that many changes are pushed to dev and/or release with simply not enough real world tests, especially where hardware may have mutliple minor, but important, variances. Direct me to the right person/subject if this exists. Cheers. I think we can consider this issue closed now. |
|
Thanks for confirming the results, and for all your testing.
It certainly is, and it would be extremely useful. The question is how to identify and notify the relevant people that some new code is proposed. The PR stage (i.e. where we are now with these changes) is when this should happen. In your case of course the particular display was never supported in the first place, and even with your changes it's surprising it worked at all. Anyway, it's now properly supported. |
|
FWIW My suggestion is the following:
|
|
Discussion continues here: https://discord.com/channels/429907082951524364/1199099072582266880 |
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
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.
The text was updated successfully, but these errors were encountered: