Horizontal jitter on display Waveshare ESP32-S3-Touch-LCD-7 800 x 480, 8MB PSRAM, 8MB Flash, ST7262, GT911 #22553
Replies: 11 comments 20 replies
-
|
Multiple problems here. Unfortunately I don't have such a large display, I have only 480x480. Is it possible to have a short video. There are at least 2 possible causes for glittering, and visible artifacts are very different in both cases |
Beta Was this translation helpful? Give feedback.
-
|
Also there seem to be a RGB mapping problem which makes the gradients look so bad |
Beta Was this translation helpful? Give feedback.
-
|
Can you try this: Details:
|
Beta Was this translation helpful? Give feedback.
-
|
Do you have the parameters of ST7262 from Micropython for this display? This would help a lot because there are MANY parameters |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much @s-hadinger , I'll try tonight after work. I note the SPI initialization, but an SPI port doesn't appear to be used for display on this board at all. ST7262 timing from datasheet Waveshare pin assignments. From the datasheet max DCLKP is about 25MHz, my/our clock frequency is about half that. Following on from this I believe that all the figures in this table which have the 'Unit measure' as DCLK should be doubled to reflect this. In micropython I tried both the min and max of these new values for all porch widths and pulse widths. Bottom line no effect, same as the idle_low settings, no impact at all. If I pushed past some of these limits there was failures. DCLKP is definitely active low (falling edge) The following appears to work perfectly under lvgl_micropython on the same board. If I used exactly the same data pin assignments on Tasmota the RGB (565) displays as BRG, (556) so I needed to swap the bytes around. Obviously not entirely correct. |
Beta Was this translation helpful? Give feedback.
-
|
Small glitch example, always to the right. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at schematic there doesn't appear to be any I2C or SPI connections between ESP and ST7262 which would allow for configuring registers. Only the RGB interface is exposed. I would have to assume that the default startup register configuration is suitable, as is, for the lvhl_micropython rgb_driver on this particular board.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks. The glitch does look like an interrupt that breaks the flow of data from PSRAM. Let's address this later. From the pinout and the Micropython, your first line should be (pinout was mixed up): |
Beta Was this translation helpful? Give feedback.
-
|
To make it more explicit, to our understanding, the glitter happens when the SPI bus is saturated and the RGB logic cannot push the data fast enough to the display. The way it works: the actual frame buffer is in PSRAM, and the RGB logic scans PSRAM via SPI (octal ideally) to push data to the display lines. What can saturate the SPI bus is mainly: 1/ other accesses to PSRAM from code (although I'm not sure it's any relevant since PSRAM access by code may not be prioritized), 2/ access to Flash memory to load code in instruction cache. This is why we enables a compile option to push Flash code into PSRAM and get 2x more bandwidth for code, costing PSRAM memory. What is you available PSRAM memory from the Information page? |
Beta Was this translation helpful? Give feedback.
-
No, I used a pre-compiled binary: tasmota32s3-qio_opi.bin. Should I try to build my own?
|
Beta Was this translation helpful? Give feedback.
-
|
Not sure if it is relevant, but using the lvgl-micropython firmware there is no glitching, the display is rock solid. I've tried scrolling charts with 200 points updated every 300ms to load it up without an issue. It is my understanding that the frame buffer mechanism used here is similar (or the same) as Tasmota's? Whilst first trying to get lvgl_micropython going on this board I needed to engage with the developer, Kevin, and he provided the following explanation regarding the maximum clock speed. For this device 12.5MHz is the sweet spot. Below 11.8Mhz crashes and above 12.8Mhz, over time the UI starts to walk horizontally - exactly what Kevin told me would happen.
|
Beta Was this translation helpful? Give feedback.
-
I'de say that is spot on: When there is not much activity, the display is less likely to gitter, but as soon as I access/use any functions in the WebUI or via serial I get a few glitches and then in stabilizes. |
Beta Was this translation helpful? Give feedback.
-
|
After a few (frustrating) days or so I managed to build my first firmware successfully using VS Code and Platform IO plugin. I compiled with |
Beta Was this translation helpful? Give feedback.
-
|
Hello there. Same im allready 3 days struggling to get this display work with TASMOTA. Here is my berry driver: Adding :B parameter solves big/little ending problem, so the colors are now allright. The only problem is still glitching same as described by Mark. Did many tests, but the only option for this display to stop glitching with tasmota is to force it work somehow with lower DCLK, usually under 10 mhz, but i had no success with tons of configs to run it under 12 MHz. I have another 7ich display with EK9716 driver (Sunton), runing same resolution, but there i was able to run it on 8Mhz stable without glitching. But same for this display when set over 10Mhz. Anyone some idea to fix this mess with hi-res displays in Tasmota? |
Beta Was this translation helpful? Give feedback.
-
|
Have you measured the relevant clocks? |
Beta Was this translation helpful? Give feedback.
-
|
Will measuring the actual clock frequency help in solving this problem? If so I'll borrow an oscilloscope and measure. |
Beta Was this translation helpful? Give feedback.
-
|
It will rule out (or not?) that the clock is in the specs. |
Beta Was this translation helpful? Give feedback.
-
|
From my post two weeks ago, max clock frequency from spec is 27 MHz. It also shows a minimum of 23 - not sure why there is a minimum. So as far as I can tell we are only clocking at about half that max. Under lvgl_micropython I have a stable display as long as the clock is between 11.8 and 12.8. Below 11.8Mhz it crashes and above 12.8Mhz, over time the UI starts to walk horizontally - exactly what Kevin told me would happen. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Developer/s, Is it likely that this issue can be fixed at some point in the nearish future? Or is such a large displays (800 x 480) not really compatible with Tasmota, due to the size of the frame buffer? I have managed to get the display stable with lvgl_micropython, however I've now really embraced the Tasmota framework for many of my projects rather than MicroPython on ESP32 devices. I'm guessing that not many people are using such a large display (with RGB) , and as such might be at the bottom of your already busy lists. If possible I would just like an idea of where this sits so I can plan accordingly. Many thanks, for all your assistance so far. |
Beta Was this translation helpful? Give feedback.
-
|
Clock testing has been done with a 2GSa/s 12bit oscilloscope. The ST7262 DCLK frequency was not very stable so I've also shown min, max and deviation (I think it's 1 standard deviation, but the manual is not clear on this) taken over 1000 samples. Nothing, or just solid colours display at 11MHz or below. Between 12MHz and 23MHz the jitters get increasingly bad. At 24MHz I can no longer make out screen objects, I pushed it beyond the ST7262 max of 27MHz, all the way to 29MHz and dispaly was still working. Above 27MHz however the web GUI becomes very very slow to respond, almost to the point that I needed to reflash to get it going again.
I also looked at GPIO36 on the ESP32-S3-WROOM-1 module which I think is the SPI clock for on chip PSRAM and on module flash. The bursts were all exactly 40MHz. |
Beta Was this translation helpful? Give feedback.
-
|
Top waveform is the SPI CLK (GPIO36) the bottom is display clock (DCLK). I also tried the tasmota32s3-qio_opi_120 build, with exactly the same waveform results, although some haspmota content was not being displayed properly with this version
|
Beta Was this translation helpful? Give feedback.
-
|
I also tested many custom builds with same result. I saw a little deviation in default flash chip mode on arduino website. For every Waveshare ESp32 S3 board there is mentioned as default and only mode of flashing as DIO, not QIO. Even when tested with DIO, nothing changed in result. Also tryied to change LVGL os different ones including rtos, but this has nothing to do with jitters (tasmota build with rtos for lvgl is slowing tasmota core). I remember i had few similiar issues when using Openhasp and the problems with jitters at higher clocks were caused when WIFI was on, but turning wifi off has no effect there. PS: i dont think that driving display trought TTL-RGB interface is the best way to do it with ESP32+tasmota for many reasons. It consumes almost all gpio pins - custom display board developers solve this with adding cheap expanders with limited gpio abilities. And offcouse, ESP32 is multipurpose mcu, not only a display driver, so there are many possible points of failure. By my opinion, the best way to drive the large resolution display with esp32 is to use displays with QSPI interface, which is more than enough. If there is someone to try to integrate QSPI in tasmota, i will send him a display for free, just PM me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, on the bright side, I have two devices with 480x480 RGB (esp32s3) displays without any flicker. So maybe the frequency required is just too high. Any recommendation for a cheap and fast to deliver (in France) display with 800x480? |
Beta Was this translation helpful? Give feedback.
-
Send me your address, phone and mail on hexamaster@icloud.com , ill send my ESP32-S3-Touch-LCD-7 . https://www.waveshare.com/wiki/ESP32-S3-Touch-LCD-7 Yes, these displays cant work stable under 10mhz (most of the did not even start), but 7mhz+ is the area where jitters are starting. |
Beta Was this translation helpful? Give feedback.
-
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
The display gritters and tears to the right - maybe a few times per second when displaying static HASP widgets or lvgl widgets. The color wheel also displays wrongly. And the round gauges look very doggy.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
autoexec.be:
pages.jsonl:
display.ini:
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
A steady display, working color picker and better looking gauges
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
It is hard to show the gittering without video.
In this pic, LEDs look correct but color wheel does not (page1)
In this pic the gauges are rendered really poorly (page2)
ADDITIONAL CONTEXT
Add any other context about the problem here.
I've read through the ST7262 datasheet and have tried many combinations of pclk frequencies, porches and pulse widths. If set the pclk frequency to above 12MHz the screen artifacts get worse. If I set it too low, the entire device locks up and I need to refresh. Other than that there are no crashes and functionality all seems there.
It took me a while to get the 16 data pins correct for color, but I believe this is verified correct by the 5 red, 6 green and 5 blue virtual LEDs. Each one changed by one significant bit.
I have also tried flashing the device with lvgl-micropython. I've used the same display parameters here, as I did in the lcgl-micropython rgb_display driver. Under that framework there is no glitching, the display is rock solid even with fast data charting and all the widgets I've tried so far display properly.
(Please, remember to close the issue when the problem has been addressed)
Beta Was this translation helpful? Give feedback.
All reactions