I’ve been developing a race car dashboard (not commercial!) based on the esp32-s3 CYD, 800x480 RGB and generally it’s OK, with basic RPM bar it runs at about 20fps. I know I’m pushing the limits with this resolution and depending what’s happening on screen with other gauges it can go down to maybe 5fps. I may want to expand it’s scope but it has very little GPIO connectivity.
so - I’ve seen the P4 based DSI “version” of my screen is now available for fairly reasonable cost (about £25 UKP) from aliexpress and was wondering if anyone can share their experiences with it e.g. is it a mission to get LVGL working or straightforward? Is performance good without heavy “tweaking”? Any other tips?
The DSI displays on P4 run much faster than the RGB displays on S3s. It helps that the P4 has 16 bit wide PSRAM running at 200MHz compared to 8 bit wide at a max of 120MHz on the S3.
I’m running LVGL on P4 displays with resolutions like 1280x800 and it’s very smooth (using RGB565.)
On S3 if you enable code execution from PSRAM it does help a lot. Can also do that on P4.
you can further improve performance by running the driver on one core and having LVGL on the other core. To do that the driver allocates the 2 full sized buffers and then you allocate 2 partial buffers that LVGL uses. When a partial buffer gets flushed that buffer gets handed off to a task you have running on the other core that handles copying the data from the partial buffer to the idle full buffer. when the copying is taking place you also perform software rotation and dithering if you want to smooth out RGB565 so it looks better. Once LVGL has completed a frame update (which can consist of multiple partial buffers) then you swap the buffers in the driver. Once the driver has swapped the buffers you copy the data from the now transmitting buffer to the now idle buffer to keep them in sync. All of the copying that is being done takes place on the other core so LVGL is free to render to the partial buffers. This eliminates LVGL stopping because of interrupts from the display driver when it needs to create another DMA transaction and it also allow the buffer sync to happen outside of LVGL. You also get another speed boost because you will be able to allocate the partial buffers in the internal ram due to them being small enough so they fit. The internal memory is a lot faster than the external and that will allow LVGL to render faster.
I wrote a driver for the S3 that does this and it makes a noticeable improvement in the speed. It also eliminates artifacts and tearing from occurring.
as a note with the S3, you can overclock the SPI so you can get an effective clock speed of 240mHz on the external memory. You need to use a version that has octal SPIRAM and octal flash in order to do that. It’s still not going to be anywhere near the speed of the P4 but it is a definite boost in performance.
That’s great, is the driver you wrote generally available? And, is it “drop in” or does it need engineering to work?
Btw - I’m currently using the smartdisplay driver by rzeldent as I couldn’t get the usual alternatives to work without lots of glitches.
it’s not a drop in replacement and in it’s current form it is written to only work with the RGB bus. If I had someone willing to test I could write it so it would work as an ESP32 component
I would definitely be interested in testing. However - be aware that my coding skills are ancient (from Pascal and COBOL era) and I lean heavily on AI to program this modern gear.
For my race car I have managed to build a gearbox control & ancillary “ECU system” with 5 nodes: Main logic (esp32s3), Display (esp32s3 CYD LVGL), gearbox actions node (esp32s3 + tft), Sensor node (stm32h5 +tft), GPS + accelerometer node (stm32h7 + tft). All connected with custom CANbus.
So - I can get stuff done but it might take a while
