Display glitching while connecting to WiFi: ESP32S3+8048S043

Whow,
Many thanks Pete.
Will do that. Will let you updated. Because of holidays, it might take 1…3 weeks.
Greetings from the Netherlands

1 Like

Hi @Ernst ,

Enjoy your holiday!

Kind Regards,

Pete

To go this way with this very little effort, Thank you a lot. :smile:
It works great, including touch. On 16MHz and no glitching.
I’ll start analyzing what I have here.

The picture is the project with a changed ‘chart size’ to 600x400 px. Just to use the screen size. (This however, leads to using all cpu power. But thats ok.)

1 Like

Hello @pete-pjb

Using the demo, and getting acquainted with LVGL I have a few questions.
Overwriting a folder content might introduce some problems I have, you might recognize. Thats why I ask you these questions.

I want to introduce a different font on the screen in “rgb_lcd_example_main.c”. After the following things:

  • Create a lv_conf.h file ‘next’ to the lvgl directory. (That is for me a confusing description in the documentation.)

  • Enable another font in lv_conf.h, in my example: “#define LV_FONT_MONTSERRAT_20 1”

  • Add following rather non-fancy code at the end in “lvgl_demo_ui.c”:

    lv_style_init(&styleScrolltext);
    lv_style_set_text_color(&styleScrolltext, lv_color_make(255, 255, 0));
    lv_style_set_text_font(&styleScrolltext, &lv_font_montserrat_20);

    lv_obj_t *label = lv_label_create(scr);
    lv_obj_add_style(label, &styleScrolltext, LV_PART_MAIN);
    lv_label_set_long_mode(label, LV_LABEL_LONG_SCROLL_CIRCULAR);
    lv_obj_set_style_text_color(label, lv_color_make(255, 255, 0), LV_STATE_DEFAULT); // by EL
    lv_label_set_text(label, "This is a looong scrolling text. ");
    lv_obj_align(label, LV_ALIGN_TOP_MID, 0, 0);
    lv_obj_set_width(label, 100);

After this, the compiler can compile, but the linker can’t link. The message is "undefined reference to `lv_font_montserrat_20’ "

The not understood thing is that using the default font ‘lv_font_montserrat_14’ in the code above is working fine.
Any ideas?

Hi @Ernst ,

If you are using VSCode I believe you need to use the SDK Configuration Editor instead of editing lv_conf.h. From the command palette select ESP-IDF:SDK Configuration editor (menuconfig) and go to the LVGL Configuration->font usage->Enable Built-in fonts:

I hope that helps.

Kind Regards,

Pete

1 Like

Hi Pete,
Thnx again. It worked. The editor is confused as it does not recognize the new enabled fonts. But, I will find that issue.Still a lot to discover comparing this IDE with Arduino IDE.

Tip for others: Also here it is the place to switch off the performance indicator 'CPU usage and FPS count.

Greetings
Ernst

1 Like

After days of struggling with VS Code it is somehow impossible for me to understand the project setup, to reproduce the project or to create a new project. Is there a step by step manual for what you did?

LilyGo supply their own partially modified LVGL library with a few more functions for display. Unfortunately I’ve forgotten what exactly, it would have to be compared. In a nutshell, they resolve conflicts there between SPI Wifi running in the background vs Display and some SPI_ready function. So with their modified LVGL library, finally wifi and display run even at Wifi.begin time.

link GitHub - Xinyuan-LilyGO/T-Display-S3-Long

LVGL has not been modified in any way that would do anything with the screen flickering.

The ONLY thing I can see that might make a difference is they are running the SPI at a pretty slow speed of 32Mhz. I do not know how much the WiFi uses the SPIRAM but if it is a lot then yes it could cause screen flickering issues if you have the frame buffers stored in SPIRAM and the WiFi is accessing the SPIRAM at the same time as the buffer is being written to the display. This is due to the maximum speed the RAM is able to be accessed at. So if you have SPIRAM running in quad at 80Mhz when 2 things are accessing the memory at the same time that would cap out the transfer at 40Mhz each. If the SPI for the display is being driven at say 80Mhz there is going to be lapses in the data that is being transferred because the data is not able to be pulled from RAM fast enough. This would result in a flicker or corruption on the display. By lowering the SPI frequency for the display this problem would not occur. It comes at a cost of it taking longer for the display to update.

1 Like

Thanks for explaining - that makes sense. What is strange though, is that the flickering only occurs momentarily while connecting. Once connected, sending/receiving over WiFi doesn’t cause any flickering…
Maybe it would be possible to reduce the SPI speed just ahead of Wifi.begin() and increase it back up after the connection :thinking:

1 Like

it’s worth a shot. I would have to dig into the esp-idf code to see what is being done when the wifi is connecting to know exactly what could be happening.