ESP32-S3 RGB LCD maximum throughput

[kmatch98]

I actually want to control the display refresh, so I want my CircuitPython code to call for the screen redraws. Now that it’s basically working with your constant refresh mode (I think your code constantly refreshes after each VSYNC interrupt), I want to see if it is possible to turn off the interrupts and build a redraw command using the “restart_transmission”.

Or you have some other variables in there that maybe I can use to trigger the screen to refresh. I have a bit of exploring to do.

Why: I want CircuitPython to control the refresh so I can eliminate tearing without having to use double framebuffers.

You’ve given me something that works, Now I have to understand your code a bit better to see how I can best use it. I have some other requests/suggestions but once I understand everything better I’ll create an issue on the ESP-IDF on GitHub.

[ESP_Sprite]

Huh, so you're effectively using variable refresh? That's an interesting concept... doesn't that lead to flickering on the LCD as the TFT pixels gate charge deteriorate when you don't refresh?

[kmatch98]

Yes, I'd like to be able to control the refreshes.

Why:
1. If my code is updating the framebuffer and then the screen refreshes before it is finished, I will get an image that is only partly updated. I think this is called "tearing".
2. If the LCD update requires the processor to use the bounce_buffer, that could slow down overall processing of my other work.
3. The CircuitPython has internal mechanisms for setting a target display update frame-rate.
4. The display I'm testing on seems to have a fairly long "memory" time. If I can update at 10 Hz, I think it would look fine, but I need to verify that it won't flash or flicker.

In reading through the code options, it appears that the idea of "stream_mode" is for continuous refreshes, but if "stream_mode" is off, I assume there would be a mechanism to request the LCD peripheral to refresh.

I've tried setting the esp_lcd_rgb_panel_config_t with .flags.relax_on_idle = 1, which eventually sets stream_mode = False, but I can't figure out how to trigger a refresh in this mode. Based on the option of "stream_mode", I simplistically assumed there is a "non-stream mode" too! Suggestions welcome.

[ESP_Sprite]

I can see if I can make this work. I mostly disregarded this as a 'special snowflake' option if you somehow had a display that has built-in memory but which still needs to be updated using a RGB interface (not that I know any of those, but still).

[kmatch98]

I have now achieved a “non-streaming” trigger-by-code method. I turned off the VSYNC interrupts and call the lcd_rgb_panel_start_transmission function to trigger each redraw. Using this modified code, in my program I finish updating the FrameBuffer, and then trigger the LCD peripheral to redraw to the display. This eliminated the “tearing” that occurs when using the “stream_mode” with continuous refresh. I’ve been able to use this up to 24 MHz pixel clock frequency.

I will clean up my code to make it easier to set stream_mode on or off with the relax_on_idle input variable and then will post my updates here. Again, many thanks ESP-Sprite for your support. Let me know if I can help with other testing related to the RGB dot clock mode.

Note: There is one bug in the lcd_rgb_panel_start_transmission function, the bounce_box_pos should be initialized to zero before filling the bounce buffers.

Code: Select all

 	
 	//pre-fill bounce buffers if needed
	if (rgb_panel->bounce_buffer_size_bytes != 0) {
        rgb_panel->bounce_pos_px = 0;
		lcd_rgb_panel_fill_bounce_buffer(rgb_panel, rgb_panel->bounce_buffer[0]);
		lcd_rgb_panel_fill_bounce_buffer(rgb_panel, rgb_panel->bounce_buffer[1]);	
	}

[kmatch98]

I pushed my modifications to the ESP-IDF for the RGB LCD peripheral here:

https://github.com/kmatch98/esp-idf/tre ... 4.4_rgblcd

This uses the "bounce-buffer" code to tie up the processor so there aren't DMA memory collisions that starve the LCD peripheral.
Also, my code adds the ability to trigger when the screen refreshes occur. This prevents the RGB display from auto-refreshing, and I can prevent any "tearing" of the screen by triggering display refreshes only when I am not in the middle of writing to the framebuffer.

My fork of the CircuitPython code that uses this is located here:
https://github.com/kmatch98/circuitpyth ... ockdisplay

Thanks again to the ESP team for support on this new peripheral.

[tushar@esp]

I believe the changes disussed in this thread are already available in IDF master branch as I am able to see below config option in the RGB panel example,
CONFIG_EXAMPLE_AVOID_TEAR_EFFECT_WITH_SEM
CONFIG_EXAMPLE_USE_BOUNCE_BUFFER

I am working on 5" (800X480) RGB LCD. I am using the latest idf master branch,
Commit ID: fde4afc67a2035a1f461dc511cd85dde1ef90368 Date: 29-July-2022.

We are observing glitches while the entire screen changes i.e one screen to another screen, scrolling in such a way that the entire screen area is being changed/updated.

As per the LCD datasheet, the typical clk is 25MHz.
When I set 25 MHz, the UI is continuously moving. I changed it and fine-tuned it to 18MHz, then the screen UI is stable, but still, these glitches on the entire screen change are there.

Is there any limit of the LCD clk interface from MCU while using the PSRAM octal mode? Please suggest any configuration that helps to remove the glitches on the screen change.

[enitalp]

Did any of you advance on the subject?

[weili_an]

My fork of the CircuitPython code that uses this is located here:
https://github.com/kmatch98/circuitpyth ... ockdisplay


can this（https://github.com/kmatch98/circuitpyth ... ockdisplay） CircuitPython support RGB TFT LCD？

[kmatch98]

Yes, this fork of CircuitPython does work with ESP32-S3 and dot clock displays.

See details for the “HACKtablet”.

https://hackaday.io/project/185831-hack ... wn-rebuild

https://github.com/adafruit/circuitpython/issues/6049