Elecrow esp32s3 lvgl screen shifting error and flash data storage while uart0 in use

My projects
1

I am using an elecrow 5" ESP32 display, Arduino IDE to program, lvgl.h 8.3.6, esp32 2.0.3 version for one of my projects.

I’ve been running into some hurdles with my elecrow 5" ESP32 display project, particularly concerning the user interface (UI) stability. The issues seem to revolve around UART0 usage and data storage using the Preferences library & SPIFFS.

  1. UART0 Usage:

Using UART0 introduces a noticeable delay in UI screen rendering. This delay leads to a shifting error on the screen, resulting in a less-than-desirable user experience. This delay persists until the UART0 operation is complete, impacting the overall usability of the device.

  1. Preferences Library:

I’ve been utilizing the Preferences library for data storage. However, when writing data to preferences, the UI screen shifts abruptly, disrupting the user experience momentarily until the writing process is complete.

I’m seeking advice and solutions from the community to address these challenges effectively, especially considering the shift from SPIFFS to the Preferences library.

Has anyone encountered similar issues with UART0 and the Preferences library on the ESP32 platform? How did you manage to mitigate them? Any insights, tips, or alternative approaches would be greatly appreciated.

I have attached the zip file of my code images and video too.

My code/zips file along with video and images: Link

Tagged:

  • [#elecrowdisplay]
  • [#ESP32S3]
  • [#HMIdisplay]
  • [#ESP32display]
  • [esp32-s3]
    LVGL
2

It seems a low-level problem which has nothing to do with SquareLine Studio exported code in my opinion, and LVGL or Arduino/ESP forums will more likely give you a help. For the first time after reading your description I thought it’s related to the clash of UART vs TFT hardware-resources (memory/timing/ports) on your device, but seeing your video makes me think it might be some memory-overlapping/corruption or false LVGL coordinate/colour setting caused by the UART or filesystem operation in a way, as if your widget’s X coordinate was mistakenly set by a counter or the widget’s runtime variables were corrupted/overwritten by the UART/filesystem code… Just a feeling (maybe hit’n’miss), because the screen content doesn’t get corrupted and LVGL seems to render the object fine as if it was instructed by an unwanted memory-modification or call to move and recolor it… Maybe check the UART/filesystem operations whether they try to call interrupts without definitive routine-addresses or if hardware buffer-areas are not overlapping RAM areas used by LVGL. Thanks for the detailed description, and good luck…

1 Like
3

Thank you , I already pasted the same query on esp32 / lvgl / Arduino platform. what you told , is right. there might be some following issue and I have been going through each one of them.

  1. Some unwanted memory modifications.
  2. False LVGL coordinate/colour setting caused by the UART or filesystem
  3. ESP32 documentation (espressif-docs) : Why do I get drift (overall drift of the display) when driving an RGB LCD screen?

I working on them one by one.

Thank you :blush:

1 Like
4

Good to know about that shifting issue mentioned in the 3rd point. It’s strange if a shift in the display itself doesn’t show some issues in the first line or the left side of the screen. (Maybe setting the text and/or the screen to a color (not grey/white/black) would show if RGB-compound memory shifting is happening.)

1 Like
5

Hi,
I have the same problem too!
Were you able to resolve the problem?
Thanks.

1 Like
6

Arduino_RPi_DPI_RGBPanel lcd = new Arduino_RPi_DPI_RGBPanel(
bus,
800 / width /, 0 / hsync_polarity /, 210 / hsync_front_porch /, 4 / hsync_pulse_width /, 43 / hsync_back_porch /,
480 / height /, 0 / vsync_polarity /, 22 / vsync_front_porch /, 4 / vsync_pulse_width /, 12 / vsync_back_porch /,
1 / pclk_active_neg /, 9000000 / prefer_speed /, true / auto_flush */);

#endif

Previous Default : 16000000 /* prefer_speed /
modified :9000000 / prefer_speed */

This worked for me in some cases , and still trying to make my code more efficient for any memory leaks.

right now I am facing some issue with lv dropdown functions ,not working properly. that may be the variable I declared in different type other than needed one so I am making the changes.

Thank you

1 Like
7

I had the same problem with frame rate. At 16mhz mqtt pub sub did not work at all. When I lowered the frame rate to 14 mhz mqtt worked.

Reading to spiffs was ok but just open and closing a spiffs file caused jitter at 14 mhz . So I lowered the frame rate to 12mhz. At 9 mhz no jitter. So I decided to live with some jitter at12 mhz because I don’t like the flicker at 9mhz with the colors I am using.

1 Like
8

HSYNC VSYNC mode displays used with sw emulated drivers require precise multithread management. When your code is one thread = any blocking func disrupt your screen.

1 Like
9

Thank you Marian
Can this be accomplished with free rtos for the ESP32

I am also having a problem with mqtt pubsub at 16mhz - I tried to run rtos but it did not work until I lowered the frequency to 12hhz.

I was wondering if I could use the second core to do mqtt and send the data over?
Mark

1 Like
10

Yes RTOS or any other OS can handle this, but more simple is use displays with framebuffer and partial data streams.
Too you need check display driver code , maybe it use some threads… or choice other driver better suited

1 Like
11

A second MCU dedicated to handle GUI-code and drive the display with adequate timing might be a good idea in timing-critical systems like this.

1 Like