If it is you can try turning on the CONFIG_SPIRAM_XIP_FROM_PSRAM option in the ESP-IDF config. You are going to have a lot of psram use if you turn that option on because what it does is it loads the entire compiled binary into PSRAM when the ESP32 starts up. PSRAM on the ESP32-S3 is typically going to be double the speed of the flash memory. So having to load code from flash so it can run it while at the same time sending large amount of pixel data to the display while also rendering to a second buffer with both buffers being located in PSRAM that causes a really large slowdown in the ESP32’s ability to run code located in flash memory. The flash memory shares the same SPI bus as the PSRAM. the PSRAM is typically 8 lanes while the flash is 4 lanes. That reduction in lanes coupled with having to share access is what really puts a hurting on running the code from flash.
With RGB displays there is no internal RAM in the display so the ESP32 has to send the entire displays worth of pixel data in a loop as fast as possible. The shift you are seeing occurs when there is a bottle neck. WiFi on the ESP32 is very memory intensive so the bottle neck is going to be loading and running of code from flash while at the same time performing a read and a write operations to the PSRAM and then performing read/write operations to PSRAM from the second core.
Using that config setting will move the running code from flash to PSRAM where the code is able to be executed 2 times faster.
One other thing I recommend doing is not using a build framework other than the ESP-IDF. Frameworks like Platformio and the Arduino IDE add a lot of additional overhead because of wrapper code being used. The ESP-IDF that is used for build frameworks tend to be cut up modified versions of the ESP-IDF. Thing are done to the ESP-IDF to make it play nice with the build framework and those changes are done not with performance in mind, it is done only for the sole purpose of getting it to work with the framework. You will reduce the amount of compiled code which means the program is going to inherently run faster. and the reduction in code being compiled means less flash access to run the code.
Thanks Kevin, that’s really useful to know. Yes, it’s an RGB screen. I was not aware that it was possible to force execution from PSRAM.
Sadly, it does not seem to fix the problem unless I’ve not managed to get it to accept the change - is there a clear way to know it’s executing from PSRAM>
Currently I am still using Platformio with ESP-IDF - again, I didn’t realise that there was a negative impact of using Platformio. I’ve also go no optimisation selected.
I’ll experiment some more tomorrow but thanks so much for your thoughts.
Quick update on this - I got rid of Platformio and recompiled just with ESP-IDF, this didn’t help but I’m glad I did it as I actually really like the ESP-IDF option now, I forget why I went with Platformio in the past but I think I had too much trouble getting ESP-IDF build tools to work reliably then.
There I read about Bounce Buffer mode and that is what I have found works. I now have a single buffer in PSRAM with an additional 10 lines of pixel data in RAM. This is presumably enough to get over the SPI clash period when WiFi is hogging SPI.