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.
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.
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
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…
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.
Some unwanted memory modifications.
False LVGL coordinate/colour setting caused by the UART or filesystem
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.)
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.
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.
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.
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
Hi,
i had the same issue and @Hermit pointed out. I specify LVGL Core to 1 and all other stuff is made on Core 0.
In lvgl_port_v8.h change LVGL_PORT_TASK_CORE to (1).
And made sure that all your other long taking task is on core 0.
I have encountered the same issue. If double buffering and full-screen refresh are used, this problem can be solved. However, it will also bring new problems. Using the sep32s3 driver to refresh an 800*480 resolution screen at a rate of about 10 frames per second will affect the touch sensitivity.
It’s an interesting assumption, how the sensitivity of the touch could be affected by the CPU utilization. I guess it’s not the sensitivity, but the serious lowering of the input-device request-rate due to the higher drawing demands. To sense the average human touch reliably the inputs should be polled in at least every 10…20 ms, with 10FPS you have it as high as 100ms. If there’s some buffering in the touch-driver it might not be that big problem, but if not, I think you’ll need to prioritize on the touch-driver and processing its input in a separate thread than LVGL’s drawing theard. Or somehow optimize the display part of the code to get at least about 30FPS.
