Closed dmartauz closed 2 years ago
Hello @dmartauz,
Thank you for reporting this issue. I haven't got any problem on my example application with this display. I am sorry, I cannot try it now, I haven't got this display here. I will have it after a week at the latest.
I checked your code and compared it with my example code. I have never tried to put the LVGL buffer to PSRAM with this display, do you have enabled or disabled macro CONFIG_EXAMPLE_LCD_I80_COLOR_IN_PSRAM
?
Hi @espzav, thank you for your reply and greetings to Brno from Trencin, SK ;-)
Results posted above are with CONFIG_EXAMPLE_LCD_I80_COLOR_IN_PSRAM enabled.
When disabled, the code fails at
assert failed: app_main i80_controller_example_main.c:257 (buf2)
When line 257 assert(buf2);
is commented out the code runs but with all visual artifacts as when running in PSRAM.
Could you please share your code so I can make a test on my HW?
Hi @dmartauz,
greetings to Trencin ;-)
The internal RAM has limited size and the screen is big. I am using only one buffer (buf2 = NULL
). If it isn't enough, you can decrease the size of the buffer for example from 100
to 70
.
My code is a complex example and it is not public now. I am working on some more components to help using LVGL. After that, the example will be published.
@espzav I tried the single buffer solution, it now runs without assert error in the internal RAM but the artifacts are still present. I also tried different buffer sizes. Changing buffer size seems to have impact on how often and what artifacts are present but they are still there. Could you please run my code once you have the display available? When do you expect the public example to be available?
Hi @dmartauz, I tried now your example on HW and it is working after some modifications, which I told you before. Here is working project. I disabled PSRAM and disabled second buffer. I don't see any artifacts. I will test it with PSRAM later. i80_controller_ra8875.zip
Hi @dmartauz, same example is working with PSRAM too. Only added these three options:
CONFIG_EXAMPLE_LCD_I80_COLOR_IN_PSRAM=y
CONFIG_SPIRAM=y
CONFIG_SPIRAM_MODE_QUAD=y
I have ESP32-S3-DevKitC-1 v1.0 and it has only quad SPIRAM. I cannot use octal SPIRAM, because it has shared pins and it is problem for my PCB. Maybe, it can be same problem on your HW.
@espzav regarding to quad vs octal SPIRAM:
When using Octal Flash or Octal PSRAM or both, GPIO33~37 are connected to SPIIO4 ~ SPIIO7 and SPIDQS.
source: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/gpio.html
As you can see in my code, I am not using GPIO33~37 for display connection. Do you still think that the issue could be related to devices with octal SPIRAM? Which DevKitC version do you have exactly? I will order DevKitC with quad SPIRAM to test.
@dmartauz I know about pins connected to SPIRAM. My HW isn't good to use with octal PSRAM. I tried the display with PSRAM (QUAD) too and it is working. I can use a double buffer and more RAM. I used the example, which I shared with you before.
If you use my example, have you got same issue?
@espzav I tried your example with GPIO numbers modified to match my HW setup and the issue is still there. I even replaced GPIO19 and GPIO20 from my original configuration with GPIO2 and GPIO1 because according to the documentation GPIO19 and GPIO20 are used for USB-JTAG by default, but it did not help.
Tomorrow I will try to rewire everything to achieve the same GPIO configuration as you use with exception of GPIO37 which I cannot use because of octal SPIRAM.
Btw I noticed that you are not using CS signal -> #define EXAMPLE_PIN_NUM_CS -1
How do you have CS pin of your LCD wired? Or did you left it floating?
@dmartauz Here is my schematic. Hope, it helps. Schematic_ESP32S3_7inch_tablet_2022-10-20.pdf
@espzav Once I grounded CS pin of the LCD (as you have in your schematic) and set #define EXAMPLE_PIN_NUM_CS -1
everything is much more stable. I think that there are LCD CS pin timing issues in regards to timing requirements of RA8875.
@dmartauz I like to hear, that it is better. Do you need the CS line or is it ok use it in ground?
@espzav for me it is ok to ground the CS pin as I am not sharing the parallel bus between multiple devices. I propose to at least mention somewhere in the documentation that there are issues if CS pin is used with RA8875 and that it is recommended not to use it.
@dmartauz yes, we will check the CS line and fix it or add the note to the documentation. I only needed to know, if we have some time or is it blocking for you.
@espzav Now I only get artifacts when UART is connected to a PC but I think this is caused by some interference or ground loop. Right now my setup is on prototyping board. I will be designing proper PCB soon which should include isolated DC-DC converter so hopefully this issue will be resolved as well.
@dmartauz I am using my board with display only on USB (connected to UART) and using console. I haven't got any artifacts there. Have you got connected RD to Vcc?
@espzav The problem was I left RD pin of the LCD floating. When connected to Vcc everything runs ok. I even made short test with CS pin enabled (mapped to GPIO2) and there were no issues.
@dmartauz Great! Thank you for info. I will add note about RD pin to Readme.
I tried to adapt i80_controller demo to use esp_lcd_ra8875 component. It seems to work but there are artifacts and shifted image. It is most visible on LVGL FPS counter as it is redrawn periodically. Sometimes the artifacts are also visible outside of the FPS counter like on this picture:
LVGL FPS counter image shifts:
After pressing "Show again" touchscreen button the FPS counter is displayed correctly for 2-3 seconds, than it gets corrupted again. Everything is displayed correctly after hard reset until the logo animation is finished therefore I don't think this is a PCLK frequency issue or FPS issue.
My code can be found here: i80_controller_ra8875_20221012.zip
Hardware used:
Software components: