Open itavero opened 2 years ago
Created a new issue on the ESP-IDF repository as well, as I noticed that their RGB panel example also seems to use a suboptimal integration: espressif/esp-idf#9121
Hi itavero, I too have been experimenting with this board and I read your ESP-IDF post. You may be interested in a couple of other dev boards which now use the ST7701s and ESP32-S3 RGB peripheral:
https://www.makerfabs.com/sunton-esp32-s3-4-3-inch-ips-with-touch.html https://github.com/Xinyuan-LilyGO/T-RGB
The Sunton is a nice board but the single USB C connector interfaces to the ESP via the ubiquitous CH340 to UART. For native USB a header is provided. Support code is based on Arduino_GFX (https://github.com/moononournation/Arduino_GFX).
The Lilygo is also a great board but uses a port expander to drive some of the display lines (reset etc) so more extensive code changes from your current dev board code could be a marginal inconvenience. Provided support code is 'Arduino wrapped' ESP-IDF.
I hope to see more kits and libs supporting these terrific displays. I still long for a good non-mipi AMOLED to work with the ESP32-S3. SPI-MIPI bridge seems too cumbersome and the flip-flop mipi-dsi hack floating around is only tested (and not yet by me) with a specific small display.
Know you of a ST7701 style AMOLED? :)
When going through the LVGL widgets demo as well as my own LVGL demo, I can see visible "tearing" / glitches. In other words, you can see which parts of the screen are being updated.
I went through the code supplied in this repository and I noticed that the LVGL display driver was not configured to use Direct mode, which I think it should given that it has an RGB peripheral and you typically only want to update the buffer once the entire frame has been updated.
I changed
lv_port_disp_init
incomponents\lvgl\porting\lv_port_disp.c
to:LCD_WIDTH * LCD_HEIGHT * sizeof(lv_color_t)
bytesMALLOC_CAP_SPIRAM
) as it wouldn't fit in the internal RAM ** also usedheap_caps_aligned_alloc
instead ofheap_caps_malloc
(with 64 byte alignment), but that doesn't seem to make a real differencedisp_drv.direct_mode = 1;
before callinglv_disp_drv_register
For my own demo code this improved the experience quite a lot, but the framerate dropped for screens that only had a little animation going on. For the LVGL widgets demo, the tearing itself became less noticable, but I got a lot of other glitches.
I think both issues might have to do with both LVGL and the RGB peripheral having to access to PSRAM.
Probably it would be better if the frame buffer would only be updated at most once "in between" frame transfers. I've also posted a question on the Espressif forum related to this.