ESP32 Forum

Much of what I do involves using LCD's. Sadly I have put off learning how to use DMA.
I saw this great post by ESP_Sprite: https://esp32.com/viewtopic.php?f=17&t=3188, that got me thinking...
It seems to me this is the only way to go for LCD's is to have the processor update the screen in the background. The LCD's we use have a 8-bit interface. I don't want to chew up I/O pins to drive the LCD, so I was thinking maybe I could use the I2S to feed a 8-bit shift register to give me my 8-bit data lines. The only thing left is how to deal with the CS & WR signal on the LCD.

The other thing that may be an issue is ram. I may be wrong but I think i need to create an array in ram the same size as the LCD panel (800x480) for the DMA to burp all this data out. That may why this would not work. If i use the ESP32-WROVER with its external 4MB ram, can I use this ram to feed the DMA?

Is there something wrong with my concept of this?

At the moment, the only valid way to use an LCD with the ESP is using SPI, or external grapich controllers.

I know this cause I wanted to the same thing as you with the same display size, but I ended up scrapping the idea of using just the ESP for screen size above 480x320.
You can always try though, but it's a bit hard to program, and will need to use assembly for some functions to run fast enough (such as RGB alpha blending).
You can use an external 4MB RAM for storing a frame buffer, or data for the displayed layers, but that will mean dubble work for the ESP DMA, since you first need DMA to store it to the external RAM, and you will need a DMA transaction again to send it out to the screen. Plus you need to chunk up your buffers cause the maximim buffer size for DMA is usually 4K, so you need to read from your buffer twice (1 for sending to the screen, and 2 for sending to the frame buffer in external RAM).

Some things to be avare of:
- The 8-bit wide line must be bidirectional (I get to this below)
- I guess what you use is MIPI-DBI TYPE B 8-bit. If you use a shift register to deserialize data, you will need a very fast one.
Keep in mind that the maximum theoretical speed for SPI is 80MHz from the ESP.
The maximum speed for DBI is usually 30Mhz, in case of 8Bits, this is a 10Mhz pixel clock, if using a 24bit format, or 15Mhz with 16bit format.
If you want to use shift register, use a 32bit one, because you can then use DBI 24bit (Not confused with RGB24 which is called DPI).
You can use 24bits of the shift reg for display data, the other remaining 8 bits can be used for DCS, CS, CLK, RW WR, etc.
- If you use the SPI interface for your display, the maximum freq you can normally use is about 16MHz limited by the screen controller. Check the timing tables of your controller IC in thedatasheet.
This is with the SPI interfaced directly to the screen. This is about 10Mhz pixel clock using 16bit format (R5G6B5), or about 6MHz sending 24bit format.
This is good, cause there is a library for it already for the ESP32 here

- WHY BIDIRECTIONAL: most screens have registers to be configured, info to be read. Also they have an internal GRAM, which contains the stuff that is actually displayed on screen. This eliminates the need for a framebuffer in your ESP. If you want to use for example Alpha blenging onto the screen, you can read back the area from the screen you want to place your stuff to, into a buffer of the ESP, do the blenging calculation, and send back the data. Keep in mind that reading from the LCD is slower than writing.
Since there is an internal RAM in the screen itself, you don't need to update the entire screen, you just update the part that is changed, which is much faster.

Just 1 tip: If you want to use the least amount of pins but do graphic intensive stuff, you should use an FT81x chip. This is what I'm experimenting with at the moment.
It's a SPI or Quad SPI external chip (think of it as a grapichs card for Microcontrollers). It has in-built touch engine, so you connect your touch screen to it directly over I2C. It can play video, etc. Max resolution for this chip is 800x800, 24Bit RGB.
http://www.ftdichip.com/Products/ICs/FT81X.html
Arduino library you can convert to ESP32 lib is here (Working on my own ESP32 lib for this chip veeery slowly: https://github.com/RudolphRiedel/FT800-FT813).

Thank you for the great reply. I worked for this company years ago, and wrote the graphics lib, and designed the board for them years ago.
http://www.versamodule.com/Video/VM7/VM7.html

On that board I am using a RA8875 graphics controller. It has both spi and parallel interfaces. As i am sure you already know, pumping data via parallel is far faster then what the SPI can handle. For this IC there is no need to ever read from it. Just simply write to the config registers to set it up and after that you can just keep pumping in the 6-5-6 RGB data.

This is why I thought since that I could pump I2S data at such a high rate I would then get parallel data faster then SPI would allow me to on the RA8875. We tried FTDI's graphics chip many moons ago, and for graphics stuff you cant beat its speed, but when it comes to displaying images or video it offers no speed advantage, as you have to pipe the data in the same way on it as everything else i have tried. Pixel by pixel. However, having said that it is a super low cost and very flexible IC. I loved the fact that you can re-map the LCD pins on it. Was very handy when it came to the PCB layout.

My plan was to create a virtual LCD in ram, and have the DMA use that to pump the data to the LCD. this way instead of writing to the slow LCD, I could write to RAM as if it was the LCD and let the DMA get it out in the background. Sadly this will not work as I read this last night in the docs: External RAM cannot be used as a place to store DMA transaction descriptors or as a buffer for a DMA transfer to read from or write into.

Ok, now I get it, so you would use an external chip, which is actually a Graphics controller, which in turn would interface the LCD.

You can use I2S as you said for parallel data, the max speed would be 40Mhz.
That said, if you do so, it's great.
There is a parallel I2S driver around, which you can get from this thread.

For SPI, the max is 80MHz as said. So if you manage to parallel the data that stream, would give you a 5Mhz pixel clock, which is 77ms for a full screen refresh.
I'll take into the datasheet of this guy much further cause it's interesting.
However at first glance, this pretty much does that the FT does.
If only they designed it with QSPI in mind

The FT81x is actually QSPI, with a max SPI freq of 30MHz, so in theory it's 120Mbits/s.
It can play m-jpeg coded .avi files, supplying first the .avi header, then just jpeg frame data to the IC. (the chip has now 1MB of ram to store such data, with scaling and other jazz).
Video proof: https://youtu.be/s4b2-XyCpsY?t=1m1s
And capacitive touch support embeded inside the chip, which I would prefer, since desiging I2C driver for capacitive drivers is such a pain in the ass.

OR just scrap the ESP32 idea all together for grapichs (Only use it for BT and wifi), and use an STM32F469 which has a MIPI-DSI periferial and internal DMA alpha blend engine No need for external IC-s
https://www.youtube.com/watch?v=2fuCQoY4CLU

I might have to take another look at the FTDI controller. We tried it when it first came out. The data sheet was terrible, along with the command structure. I just never looked back at it since then. But the increase in SPI speed seems worth another lookse.

Vader_Mester wrote:Ok, now I get it, so you would use an external chip, which is actually a Graphics controller, which in turn would interface the LCD.
.....

For SPI, the max is 80MHz as said. So if you manage to parallel the data that stream, would give you a 5Mhz pixel clock, which is 77ms for a full screen refresh.
I'll take into the datasheet of this guy much further cause it's interesting.
However at first glance, this pretty much does that the FT does.
If only they designed it with QSPI in mind

The FT81x is actually QSPI, with a max SPI freq of 30MHz, so in theory it's 120Mbits/s.
It can play m-jpeg coded .avi files, supplying first the .avi header, then just jpeg frame data to the IC. (the chip has now 1MB of ram to store such data, with scaling and other jazz).
Video proof: https://youtu.be/s4b2-XyCpsY?t=1m1s
And capacitive touch support embeded inside the chip, which I would prefer, since desiging I2C driver for capacitive drivers is such a pain in the ass.

OR just scrap the ESP32 idea all together for grapichs (Only use it for BT and wifi), and use an STM32F469 which has a MIPI-DSI periferial and internal DMA alpha blend engine No need for external IC-s
https://www.youtube.com/watch?v=2fuCQoY4CLU

I just have a question related to LCD/SPI/MIPI
There are some 'transmitter' chips that can drive very crazy resolution LCD panels and I saw video once of Russian guys that designed their own cheap board and connected it to cheap STM32. Maybe that is the way to go with the displays and LCDs.
Those ICs are LVDS transmission based dedicated to all kinds of displays.
Maybe you could experiment with such ICs
Here is a video in Russian:
https://www.youtube.com/watch?v=JoTnDFIqpSo

The FTs received an upgrade. Previously it was FT80x, not it is FT81x.
Programmers guide:
LCD selection and touch compatibility

The QSPI looks compatible with the ESP32.
The datasheet and programming guide is OK, the examples are fine, most are for FTDI's own microcontroller, but there are some arduino libs out there too.

There are all sorts of apps also for picture and font conversion, on the site.
There are a few unknown things, I have to try when I build my prototypes, but it's not bad.

The mjpeg support is pretty cool, cause you can stream camera through wifi with this guy (in theory), because the mjpeg doesn't have interleaved frames, it's encoded as a series of jpeg pictures for each frame. Although the file is larger, it's better for streaming and involves less number crunching. You first supply the FT with the AVI header, and after that it's just pushing the jpeg frames into the FT, which handles decoding and stuff.

It has 4 variants.
FT810, FT811 - These output 18bit RGB, both has a max res of 800x800, the FT810 has integrated resistive touch engine, the 811 has capacitive touch.
FT812, FT813 - There guys output 24Bit RGB, The 812 here is the resistive guy, the 813 is the capacitive.
Digikey, Mouser all have it, but in larger quantities, the only the FT811 is available from stock.

You can find pre-built LCD modules online with this IC (Riverdi, Microelectronica, etc).
Not all of these are designed with QSPI, so check the schematics before ordering.
I'm currently designing (only in planning phase yet), my own dev-board for the FT813, and planning to convert the arduino lib I linked to ESP compatible.)

What about bigger resolutions like FHD ?

Deouss wrote:What about bigger resolutions like FHD ?

Nooooo way man. Not enough clock and not enough memory. For that you better off buying a Rasberry Pi Zero which costs almost nothing and can do amazing stuff

Vader_Mester wrote:

I'm currently designing (only in planning phase yet), my own dev-board for the FT813, and planning to convert the arduino lib I linked to ESP compatible.)

Did you get QSPI to FT8xx working ?
I guess SPI is easy, as there are code examples, but I cannot see very much information about using QSPI on ESP32 ?