TFT_eSPI VS gfx_demo

Bodmer's TFT_eSPI is a graphics library for drawing to various displays, like the ILI9341, which is supported. It can be used with the Arduino IDE to program a Pico to interface with an ILI9341 using SPI, 8 bit parallel or 16 bit parallel interfaces.

For example, the electropeak link you posted showed a TFT LCD with the ILI9341 chip, and if you are using the TFT_eSPI library, this file needs to be configured https://github.com/Bodmer/TFT_eSPI/blob/master/User_Setup.h , the default configuration looks correct in this case.

Example Setup70b_ESP32_S3_ILI9341.h

Discription /* * Esp32 WROOM with iLi9341_TFT display * TFT_eSPI Library // https://github.com/Bodmer/TFT_eSPI * * ESP32Encoder Library // https://github.com/madhephaestus/ESP32Encoder.git * * DIGITEN G3/8 Water Flow Hall Sensor * Red - VIN(5v) * Black - GND * Yellow - D2 * * */ Enable TFT_eSPI Library #include // Hardware-specific library #include TFT_eSPI tft = TFT_eSPI(); // Invoke custom library ESP32ENCODER Setup ``` #include

``` /* * Esp32 WROOM with iLi9341_TFT display * TFT_eSPI Library // https://github.com/Bodmer/TFT_eSPI * ​ * ESP32Encoder Library // https://github.com/madhephaestus/ESP32Encoder.git * ​ * DIGITEN G3/8 Water Flow Hall Sensor * Red - VIN(5v) * Black - GND * Yellow - D2 * ​ * ​

My favorite Arduino compatible graphics library is https://github.com/Bodmer/TFT_eSPI

I was under the impression that since this display uses a ST7789V, I'd be able to use the TFT_eSPI library which has support for this controller with ESP32 board. Is that a correct assumption on my part?

GFX Library Documentation: https://www.codeproject.com/Articles/5302085/GFX-Forever-The-Complete-Guide-to-GFX-for-IoT

GFX is a feature rich graphics library that does jpg loading, truetype fonts, alpha blending, etc.

starting at line 573 here: https://github.com/codewitch-honey-crisis/gfx_demo/blob/master/lib/gfx/include/gfx_palette.hpp

basically draw to a bitmap and then blt that to the display. you can do the latter asynchronously, so you can load, then display, and while displaying, load the next one. it won't help immensely, but it will speed things up slightly. In GFX you'd use draw::bitmap_async. There's full documentation linked to from the link I gave you above - look in "Properly doing asynchronous draws" https://www.codeproject.com/Articles/5302085/GFX-Forever-The-Complete-Guide-to-GFX-for-IoT

I queue a variable number of transactions, either polling or non depending on context, using this code I wrote: https://github.com/codewitch-honey-crisis/gfx_demo/blob/master/src/esp-idf/drivers/common/spi_master.hpp

In case the OP doesn't respond, I'll field your question as best as I can: You can do the rendering using a bitmap flipping algorithm along with DMA. I also know it's possible to keep the framebuffer for that display in ram, with memory left over to do bitmap flipping because I do that very thing in https://github.com/codewitch-honey-crisis/gfx_demo - that device is a Lilygo-TTGO and I have several. The above code can run on it.