วีดีโอ

Plenty of pins can be used for whatever you like. All those IO pins on the left of the picture, and the camera pins too if you do not have a camera plugged in and the screen is not using the line.

@@peterwentworth8993 so we need to use alternative pins for the camera. Are they available or is there a SPI or I2C camera?

I've not tried it, but I think it unlikely. In this project most of the heavy lifting for the incoming video data is done behind my back by the I2C / DMA hardware 8 bits at a time, in parallel, which means we have buit-in hardware support to handle high-speed inbound camera data. Your data is likely to be a movie or something. The Iinput from the SD card is likely serial, and the video data is heavily compressed by CODECs (coder/decoder). If you don't do this compression the movie will be huge on the SD card, and you won't have the bandwidth to load 25fps.) So the big challenge is to write the movie decompressor that can read the SD card and produce frames to display. There are hardware chips for decompressing some formats, but not built into the ESP32. So I doubt you'll have nearly enough processing firepower to input the coded video data, decompress it, and display it at any kind of decent framerate. Please someone, let me know if I am wrong!

I get the point, my intention was to store image files in .h or .c format and by changing them create illusion of animation, 25 fps is just for making it smooth. Basicly it can be 4-5 img per second. That is too much for esp memory but it is small for any SD card. I tried TFT_eSPI but got tearing when I clear screen. Also I dont know c/c++ , know how to use loops etc, basic simple stuff.. That is way I asked you for help. Understand a concept but cant reproduce it :)

@@jedandecko5585 OK, my screen is not SPI, it is the older parallel one (can be faster, but uses up many more ESP32 pins, and doesn't make use of built-in hardware SPI support in the ESP32). So this technique is not going to drive your screen.

Ok, thanks for your time.

Hi David - both camera and LCD have setup registers supporting RGB565 format (two-bytes-per-pixel) format. (Both camera and LCD can also do other formats, but the RGB565 is the common one I use.) The camera also has some settings to swap the order of the bytes, swap the RED and BLUE channels in the RGB encoding, I think it can swap order of bits within the byte, it can invert the colours, suppress the pixel clock when there are no pixels, change the drive strength on the pins, invert its timing signals, etc. etc. And it has Auto Exposure, White Balance, gamma correction options, etc. So lots of generality, but badly documented. And the LCD has general ways about how to place the incoming pixels into the frame buffer (top-to-bottom, left-to-right, and so on). So no glue code required other than getting the options set up right in the first place (most of that work I inherited from predecessor projects). The pixel data itself does not come through the ESP32 for any processing.

Thanks. My cheaper LCD device has an 8-bit parallel bus, no serial SPI. So that brings the advantage of more wires to move data faster. If you look on the Adafruit web page their original LCD was parallel, then they discontinued that one in favour of a Serial SPI version which they admit is a bit slower. So it is a tradeoff: I need more pins and wires than I would for SPI, but I can get better throughput if I can write all 8 bits at the same time. I didn't look at the CPU usage.