TFT spi at 60MHz

[ESP_Sprite]

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.

Note that you can chain-link DMA descriptors in order to automatically send buffers >=4KiB. For instance, the SPI master code does this.

[Deouss]

Note that you can chain-link DMA descriptors in order to automatically send buffers >=4KiB. For instance, the SPI master code does this.

You mean using spi_device_queue_trans() and spi_device_get_trans_result() will sync and wait for DMA to finish?
So referring to DMA - the spi transaction tx_buffer length cannot exceed 4kb ?

I intended to try to allocate full memory for lcd image there (320*240*2)

[ESP_Sprite]

I mean that the SPI driver will happily allow you to send a chunk of >4K (in your case 150K), given you tell it beforehand you need transfers that large by setting max_transfer_sz in the spi_bus_config_t struct you use to initialize the bus.

[Deouss]

That's awesome

[preafixed]

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.

Can you explain more?

[Vader_Mester]

Can you explain more?

This post is kinda irrelevant, since we have the ESP32-S3.

What's exactly you wish to do?