Hi,
I'm still working on a proof of concept with the ESP32-S3 to determine if the RGB LCD peripheral is suitable for our needs.
For the proof of concept, I'm now using the master branch of the ESP-IDF on a dev kit I got from AliExpress (which also includes some sample code).
When animations occur on the screen (especially if it's the entire screen that is being updated), we notice some "glitches" / "tearing".
After going through some of the documentation and the code provided, I noticed that LVGL was not configured to use Direct mode, which I think should be used for the LCD peripheral on the ESP32-S3, as well as the draw buffer for LVGL was only 1/4th of the screen (480x120, screen resolution is 480x480)
I've enabled Direct mode and switched to using a single buffer. This seems to improve the performance, but the glitches are not fully disappeared.
What I think is happening, is that the buffer gets updated while it is being "transferred" to the LCD panel.
I think I should "sync" updating the buffer with the on_frame_trans_done callback, but I noticed this was removed from the examples on the master branch.
Can it not be used for this, or why is it removed?
How would I go about syncing the update of the frame buffer to get rid of the "tearing"?
So far, our product development managers have not yet been convinced by the solution based on the ESP32-S3.
I'm trying to understand if this is just a software issue or if we really can't get it to work without tearing on this microcontroller.
If it can't be done, we'll probably have to go another route, using silicon from other vendors.
Kind regards,
Arno
ESP32-S3 RGB LCD peripheral: weird glitches
Re: ESP32-S3 RGB LCD peripheral: weird glitches
Arno,
I had the same issue with glitching and tearing. Thanks to some code from the Espressif, I found a working solution: https://www.esp32.com/viewtopic.php?f=1 ... =20#p95677
This method creates a “bounce buffer” that ties up the processor during the display refresh. This prevents simultaneous access to the PSRAM which could cause starving the LCD peripheral. Unfortunately this solution kills the value of using DMA but at least it is a solution.
The code that is provided by ESP triggers continuous refreshes. I want to have my code trigger the display refresh, so I added a function to trigger a redraw of the LCD peripheral.
Here is my project: https://hackaday.io/project/185831-hack ... wn-rebuild
Here is my related issue on the CircuitPython GitHub repo: https://github.com/adafruit/circuitpython/issues/6049
I still haven’t pushed a commit of my code anywhere yet, but please ask questions if you have any and I hope to push something in the next couple of weeks.
I had the same issue with glitching and tearing. Thanks to some code from the Espressif, I found a working solution: https://www.esp32.com/viewtopic.php?f=1 ... =20#p95677
This method creates a “bounce buffer” that ties up the processor during the display refresh. This prevents simultaneous access to the PSRAM which could cause starving the LCD peripheral. Unfortunately this solution kills the value of using DMA but at least it is a solution.
The code that is provided by ESP triggers continuous refreshes. I want to have my code trigger the display refresh, so I added a function to trigger a redraw of the LCD peripheral.
Here is my project: https://hackaday.io/project/185831-hack ... wn-rebuild
Here is my related issue on the CircuitPython GitHub repo: https://github.com/adafruit/circuitpython/issues/6049
I still haven’t pushed a commit of my code anywhere yet, but please ask questions if you have any and I hope to push something in the next couple of weeks.
Who is online
Users browsing this forum: Bing [Bot], egionet, Google [Bot] and 312 guests