LV_ARC causes a full-refresh when set to LV_ARC_MODE_NORMAL

General discussion
,
1

Hi all,

I’m currently working with two Waveshare 7" displays using LVGL and ESP32:

  1. LCD7-ESP32N8R8 – 800×480, ST7262 controller
  2. LCD7B-N16R8 – 1024×600, controller unclear (ST7262 or ST7701)

The first display works fine. I had some strange behavior (screen shift after hours or days), but enabling double buffering, directmode and pin it to core 1, resolved it.

Now I’m using the B-version (LCD7B-N16R8) and ran into several issues.

Controller Confusion
The product page references the ST7262 datasheet, but the FAQ mentions ST7701. I’ve heard both are similar and use the RGB interface, but it’s unclear which one is actually used. Has anyone confirmed this? (https://www.waveshare.com/wiki/ESP32-S3-Touch-LCD-7B)

Pixel Clock and Display Shift
With direct_mode = 1, double buffering, and bounce buffer, I get a perfect image and smooth animation below 17 MHz pixel clock, but there is slightly flickering of the display to see.
However, going above 17 MHz causes a leftward shift of the image, with the removed portion wrapping to the right.

Waveshare’s sample code uses 30 MHz, so I tried matching that. After extensive tweaking (porch, sync width, offset_x, flush callback), nothing helped—until I increased the physical width in the driver to (1024 + 30). That fixed the alignment, and the display now works at 30 MHz.

I also tried their examples, but the same behavior occurs. The only thing I haven’t tried yet is using the Espressif IDE instead of PlatformIO.

Arc Animation Glitch
I use LVGL’s arc widget as a second counter in a clock:

  • Animate in NORMAL mode to fill the circle
  • Switch to REVERSE mode to subtract
  • Then switch back to NORMAL

This works well, except when switching back to NORMAL: LVGL seems to trigger a full refresh, causing a misalignment (~1 frame) before returning to normal.

Questions

  1. Can I disable or suppress the full refresh when switching arc modes?
  2. Has anyone else seen this behavior with arc animations?
  3. Any insights on the controller type or how to confirm it?
  4. Is there a better way to handle the pixel clock issue without faking the resolution?

Thanks in advance for any help or ideas!

2

It seems that the timing setup wasn’t proper paramterized.
After tweaking the esp32 by adding some experiemental features.

What I did:
Changes in ESP SDKConfig/Menuconfig for PIO:

CONFIG_FREERTOS_HZ=1000
CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_240=y
CONFIG_ESPTOOLPY_FLASHMODE_QIO=y
CONFIG_ESPTOOLPY_FLASHFREQ_120M=y [Need to be consistent with PSRAM]
CONFIG_SPIRAM_MODE_OCT=y
CONFIG_IDF_EXPERIMENTAL_FEATURES=y and CONFIG_SPIRAM_SPEED_120M=y [Need to be consistent with FLASH]
CONFIG_SPIRAM_FETCH_INSTRUCTIONS=y
CONFIG_SPIRAM_RODATA=y
CONFIG_ESP32S3_DATA_CACHE_LINE_64B=y
CONFIG_COMPILER_OPTIMIZATION_PERF=y

Use double drawbuffer
drawbuffer size: ScreenWidth * 100 instead of 10 or 600.
bounce buffer: from 0 to ScreenWidth * 10
changed

esp_lcd_rgb_panel_event_callbacks_t cbs = {
        .on_vsync = onVSyncEvent,
    };

callback to

esp_lcd_rgb_panel_event_callbacks_t cbs = {
        .on_bounce_frame_finish = onVSyncEvent,
    };

Unfortunely, the bounce buffer had introduced a shift of 10 pixel to the left.
The modification of the callback to on_bounce_frame_finish ensures that the screen shift does not appear.