ESP32 Forum

I haven't seen any thread that would show some spi overclocking tests - particularly for LCD.
I have managed to run spi_master example included with esp-idf at 60Mhz for ILI9841 320x240 TFT.
The example uses spi transactions and I changed host to VSPI at native IOMUX pins.
Matrix non native setup only can go as far as 33MHz
Just interesting observation. I wonder if it pertains to different models of ESP boards.

Hi Deouss,

The SPI frequency is not limited by the ESP32, rather the LCD controller you are using.
The max SPI clock is 80MHz, which is veeeery fast.

Most controllers can only go to 30MHZ max. The ILI9488 for example can do 20MHz reliably.
Before trying, please make sure to check the timing diagrams in the LCD chip's datasheet.

Interesting. I thought those popular TFTs have vertical refresh rates at least 60Hz. I am not sure how to calculate spi frequency into pixel and frame bandwidth. What parameters should I be looking for in datasheets?

it's a completely different interface.
Several different clock speeds apply for paralle RGB24, MIPI-DBI (which is like a 8bit to maximum 24bit wide SPI for TFTs).

MIPI-DSI is usually has the fastest clocks amongst all, usually around the 100Mhz range, but that requires a dedicated PHY.
Although I have to add, that DSI is the fastest and most used protocoll, and it is used in most modern equipent (with 4data lanes the speed can be 1000Mbits/sec, to be speedy enough for phone and laptop screens.

Just always check the timing diagrams and tables for the controller.

The fastest refresh rate you can achieve is with a 16Bit wide MIPI-DBI (as far as I remember)

Yes, I noticed MIPI DSI is on many Raspberry Pi boards. The cheaper TFTs use parallel interface which I must look at much closer how to program it. As far as I understand RGB lines are parallel input and independent and can be 'swiped' with shift register ICs or some serial converters. What also got me thinking is if CPU has high clock rate then it is possible to design quite fast protocol on lower machine language e.g direct assembler. Or maybe some kind of direct memory bus so you could just write 32bit words directly to controller

For the ESP it is in theory possible.

Keep in mind that the standards parallel RGB (24bit or 16bit wide) bus (the one that has HSYNC and VSYNC signal) are not possible with the ESP32, as in this case you have to keep a full frame buffer in the ESP RAM at all times, and send the frame buffer out completely for every frame.
Plus, this one needs a lot of GPIOs on the ESP.
Additionally, most screens - specially the low-res ones need an additinal SPI interface for configuring the TFT screen for this mode...
So this one sux...

I would recommend using the MIPI DBI Type B - 8bit specification.
You can use the I2S periferial, as 8Bit wide data stream. You will need additionaly a CS line, D/Cx for signaling that the data you send is either Command or Data, and a WRX and RDX line for signaling a read or write operation and these guys are the actual clocks (here the WRX and RDX lines can be done with only 1 GPIO with an external logic gate).

With this one there is no need for a frame buffer, it works like the SPI only more parallel Data lines. The image is strored in the controllers GRAM, which you can also read from using the same 8bit wide bus, and with this one you can configure registers, etc.

Here is a number crunching for the speed comparison (In case of an ILI9488, which is 480x320).

Max SPI clock is 20MHz, in case of 24bit pixel data (You will need more CPU work to make an R8G8B8 color value into an R5G6B5 16Bit data) - the max pixel clock is 840Khz, which is pretty sheit.
If you use only 16bit color data the max pixel clock is 1.25Mhz... this is pretty sheit too

With MIPI DBI Type B, the max clock (WRX) is 33MHz. With this the max pixel clock is 10MHz!!! (much quicker).
This guy can refresh the screen in 60FPS easy.

Alternatively you can use the SPI BUS of the ESP32, and an external shift register. Here you would need a 24Bit wide register. (on the MOSI line)
You use the SPI to push data into the shift-reg and latch it out parallely. The clock of the shift reg is the SPI Clock (80MHz max).You can control the latching operation shift-reg operation with the CS, WRx line. (1 WRx clock cycle is 1 latchout).
However you will need an additional shift register for reading data back (MISO line), you control the latching on this one with the RDx line.

After reading this you would think "Damn what the hell did I got into"

I went though the same though process and dilemma, and figured that the ESP is far from optimized for this work. (I even started writing an assembly based RGB and alpha channel color mixing algorythm )

But I can tell you a completely different thing.
I would suggest you to take a look at the FT81x family, peak into the data sheet, and you will never use anything else for srceen control.
I'm using this in my next project.

Hit me up with a PM if you have questions.

You mentioned that FT8 chip. It is FTDI up to 800x600. Well, I am not so concerned about speed of displaying the image but about resolution. I want to display image on HD LCD panel and speed is not an issue. Not sure how to achieve it with ESP.
I haven't messed with MIPI yet and just learning about those interfaces)
Very helpful would be a circuit connecting MIPI to HDMI/DP

HDMI in your case is pretty hard to do. Buying all the interface and bridge ICs you will need will cost as much as a native HDMI MCU in the first place.
Additionally most HDMI bridge tech supports parallel RGB24 only, which the ESP simply can not do.

HD displays don't support most MIPI protocolls, mostly DSI and parallel RGB24 is used.
DSI is a no-go with the ESP, parallel RGB24 is a no go because of the lack of RAM and the speed is not too goot either (you need to render and send a pixel within just 25 instruction cycles to achieve about 10FPS.

If you want to go HD anyways, I suggest you go with an STM32F469 or simillar that has a MIPI DSI and graphics acceleration.

I have STM32F407VET6 however few people told me that it has very little memory and flash despite some extra peripherals.
We need like next gen of ESP to get all that features)
When it comes to RGB parallel interface - maybe it is possible to address 3 lines separately with 3 parallel SPIs/clocks and gain the display speeds.

Check out this doc for the usage of STM32F-s.
In the case of such a big screen, most STM32-s use external SDRAMs which are very fast.

Regarding the ESP implementation:
You can push the I2S to it's limits, by using the 24bit LCD mode. Here the max clock is 40MHz as far as I know.
But then again you need torender the pixels, etc.
Theoretically with this mode a 40Fps speed is possible, but you must experiment with this one.

The one thing you can do is to use the SPI RAM as frame buffer. The size of this is 4MB.
The 720p screen has 921kpx, if you have 24bits/pc you will have a 2.7MB sized buffer. This will fit inside the RAM.
If you have a gazzilion amount of time to write the driver, once you have rendered the screen and stored it into the SPI RAM, DMA will do the work.
Remember that a maximum size of a DMA buffer is 4kBs. You will need 2 of these, so while your transmit the first you can fill the 2nd.