8Bit Parallel Support on upper GPIO pins for ESP32-S3

[ddimensia]

The new LillyGo ESP32-S3 T-Display device uses an 8-bit parallel display with the data pins connected to GPIO 39-48 (43/44 are excluded as they are UART0). The current ESP32-S3 parallel support only reads from the lower 32 GPIO pins, so it won't support the new device.

Board: LillyGo T-Display-S3
Processor: ESP32-S3
TFT Driver: ST7789
Interface: Parallel

Display/device pinout

[ddimensia]

This post indicates that using a dedicated gpio bundle may get around the slowness added when using GPIO pins above 31. https://www.esp32.com/viewtopic.php?t=27963#p98194

[Bodmer]

Replace the library header TFT_eSPI_ESP32_S3.h with this one and it shoule work:
TFT_eSPI_ESP32_S3.zip

Let me know if it works.

[lbxhacker]

i also use ESP32-S3 with ESP-IDF,It's can't work PARALLEL_8_BIT ,

[ddimensia]

I should have the devices in a day or two and will give it a try. I've been playing with a non-parallel display I had floating around in the mean time.

[MartinNohr]

I have several of these being shipped. I'll test as soon as I get them.

[9Rune5]

LilyGO released their own patch: https://github.com/Xinyuan-LilyGO/T-Display-S3/blob/b12c08a3a121f8938aa08ca27ae44002d40119a8/lib/TFT_eSPI/micky_commit.patch

[9Rune5]

Replace the library header TFT_eSPI_ESP32_S3.h with this one and it shoule work: TFT_eSPI_ESP32_S3.zip

Let me know if it works.

I'm still getting acquainted with PlatformIO, so I may have missed something.

It looks like you've removed the definition of GPIO_DIR_MASK:

.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/TFT_eSPI.cpp: In member function 'uint8_t TFT_eSPI::readcommand8(uint8_t, uint8_t)':
.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/TFT_eSPI.cpp:993:10: error: 'GPIO_DIR_MASK' was not declared in this scope
   busDir(GPIO_DIR_MASK, INPUT);

readByte() is also struggling (one warning per TFT_Dx):

.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/Processors/TFT_eSPI_ESP32_S3.c: In member function 'uint8_t TFT_eSPI::readByte()':
<command-line>: warning: right shift count >= width of type [-Wshift-count-overflow]
.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/Processors/TFT_eSPI_ESP32_S3.c:106:16: note: in expansion of macro 'TFT_D0'
   b  = (((reg>>TFT_D0)&1) << 0);
                ^~~~~~

My defines:

              -DBOARD_HAS_PSRAM
              -DCONFIG_IDF_TARGET_ESP32S3
              -DUSER_SETUP_LOADED
              -DST7789_DRIVER=1
              -DTFT_BL=38
              -DTFT_CS=6
              -DTFT_DC=7
              -DTFT_RST=5
              -DTFT_WR=8
              -DTFT_RD=9
              -DTFT_D0=39
              -DTFT_D1=40
              -DTFT_D2=41
              -DTFT_D3=42
              -DTFT_D4=45
              -DTFT_D5=46
              -DTFT_D6=47
              -DTFT_D7=48
              -DTFT_PARALLEL_8_BIT
              -DTFT_WIDTH=170
              -DTFT_HEIGHT=320
              -DTFT_INVERSION_ON

[nicpottier]

Hi guys, just got this board and trying to get the TFT going in platformio. I target multiple boards so would love if I can stick to the mainline of tft_espi. Anything I can do to help?

[nicpottier]

I can make it work with the lilygo supplied fork they have here FWIW:
https://github.com/Xinyuan-LilyGO/T-Display-S3/tree/main/lib/TFT_eSPI

[ddimensia]

I've verified the LilyGo fork works as intended.

[9Rune5]

Yes, the lilygo fork works, but it would be nice to have this merged into the main library.

[h3ndrik]

please reopen this. it hasn't been completed.

[Bodmer]

Moved to new support request topic in discussions.

[Bodmer]

This replacement patch file (put in "Processors" folder) to the one posted above has been modifed to work with the latest Git master.
TFT_eSPI_ESP32_S3.zip

I have no means of testing it at the moment so let me know if it works OK with that board/display combination.

This looks like a suitable setup file, but again I have no means to test this.

// LilyGo T Display S3 8 bit parallel with high GPIO numbers
#define USER_SETUP_ID 0x4E54

#define ST7789_DRIVER

#define TFT_WIDTH 170
#define TFT_HEIGHT 320

#define CGRAM_OFFSET

// #define TFT_RGB_ORDER TFT_RGB  // Colour order Red-Green-Blue
#define TFT_RGB_ORDER TFT_BGR  // Colour order Blue-Green-Red

#define TFT_INVERSION_ON
//#define TFT_INVERSION_OFF

#define TFT_PARALLEL_8_BIT

// The ESP32 S3 pin allocation
#define TFT_CS 6
#define TFT_DC 7
#define TFT_RST 5

#define TFT_WR 8
#define TFT_RD 9

#define TFT_D0 39
#define TFT_D1 40
#define TFT_D2 41
#define TFT_D3 42
#define TFT_D4 45
#define TFT_D5 46
#define TFT_D6 47
#define TFT_D7 48

#define TFT_BL 38

#define LOAD_GLCD  // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#define LOAD_GFXFF // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

#define LOAD_FONT2 // Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
#define LOAD_FONT4 // Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
#define LOAD_FONT6 // Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
#define LOAD_FONT7 // Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:.
#define LOAD_FONT8 // Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.

#define SMOOTH_FONT

[9Rune5]

That yields a bunch of these warnings (and a blank screen upon reset):

.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/Processors/TFT_eSPI_ESP32_S3.c:` In member function 'uint8_t TFT_eSPI::readByte()':
<command-line>: warning: right shift count >= width of type [-Wshift-count-overflow]
.pio/libdeps/ESP32-S3-DevKitC-1/TFT_eSPI/Processors/TFT_eSPI_ESP32_S3.c:106:16: note: in expansion of macro 'TFT_D0'
   b  = (((reg>>TFT_D0)&1) << 0);
                ^~~~~~

(one warning per TFT_Dx define)

[Bodmer]

That is expected for the patch if you do not specify the pins TFT_D0-7 as above suggested setup file. The patch is ONLY for test with the LillyGo ESP32-S3 T-Display device as posted at the top.

[Bodmer]

Ah, OK, I don't get that error on compile. Will investigate.

[Bodmer]

I forgot I had changed TFT_eSPI_ESP32_S3.c

Edit line 97 to disable that code thus:

#if defined (xxxTFT_PARALLEL_8_BIT)

It is only for reading TFT and I will sort that later.

[MartinNohr]

Bodmer: I would be happy to send you a TTGO ESP32 S3 for testing if that would help. email me at mnohr247 (at) gmail.com.

[Bodmer]

Thanks but it is not needed. I have a few S3's in projects but not available for tests at the present time. I do not have a parallel ST7789 or any other parallel displays free at the moment either...

[h3ndrik]

that doesn't display anything. the display stays black (apart from the background lighting).
give me a few days and i'll see if i can dig into this.

just a few questions:
a) is the pin definition TFT_RD = 9 correct? lilygo defines that as not connected.
b) do i take the code from the zip file as a starting point and create a pull request with that? if i can figure this out? or: what's the copyright on the lilygo modifications? could i include them into a pull request?

[Bodmer]

Maybe you are using a different board or looking at a different setup? The pin diagram posted by @ddimensia above shows RD connected to GPIO 9 so it MUST be defined.

[h3ndrik]

my board looks almost identical to the one in the first post. although it has v1.2 and another date written on the silkscreen.

speaking of the RD: what's with the read function in the TFT_eSPI_ESP32_S3.c ? my compiler complains about all the right shifts in readByte() that now try to shift more than 32 places to the right in a uint32_t (as all TFT_D0..TFT_D7 are pins beyond 32.)

here:

TFT_eSPI/Processors/TFT_eSPI_ESP32_S3.c

Lines 106 to 113 in 421377e

	b = (((reg>>TFT_D0)&1) << 0);
	b |= (((reg>>TFT_D1)&1) << 1);
	b |= (((reg>>TFT_D2)&1) << 2);
	b |= (((reg>>TFT_D3)&1) << 3);
	b |= (((reg>>TFT_D4)&1) << 4);
	b |= (((reg>>TFT_D5)&1) << 5);
	b |= (((reg>>TFT_D6)&1) << 6);
	b |= (((reg>>TFT_D7)&1) << 7);

EDIT: for reference: a related bugreport to gpio_input_read_high() is here: espressif/arduino-esp32#7293
(or use something like GPIO.in1.data ??)

EDIT2: the .h file in the zip is also missing a few "WR_L;" which are prepended to several write commands (in the lilygo code).

[Bodmer]

You need to make the tweak mentioned here to avoid that warning:
#2134 (reply in thread)

Viz:
I forgot I had changed TFT_eSPI_ESP32_S3.c

Edit line 97 to disable that code thus:

#if defined (xxxTFT_PARALLEL_8_BIT)

It is only for reading TFT and I will sort that later.

Yes, well spotted, the write in the WR_L is in the wrong place because it TFT_WR is GPIO 8 so cannot be ORed into the mask of GPIO over 31.

I will update and post new patch files later.

[Bodmer]

I think the correct code for the mask definition at around line 373 in TFT_eSPI_ESP32_S3.h is:

  #if (TFT_WR >= 32)
    // Data bits and the write line are cleared to 0 in one step (1.25x faster)
    #define GPIO_OUT_CLR_MASK (GPIO_DIR_MASK | (1 << TFT_WR))
  #elif (TFT_WR >= 0)
    // Data bits and the write line are cleared sequentially
    #define GPIO_OUT_CLR_MASK (GPIO_DIR_MASK); WR_L
  #else
    #define GPIO_OUT_CLR_MASK
  #endif

[Bodmer]

I found a ProS3 board and wired up a parallel display with the data bus wired to the high GPIO pins. It is working fine with the two files below.

TFT_eSPI_ESP32_S3.zip

Replace the two files in the library "Processors" folder with those. Note this is a temporary patch to get the board working, the patch will only work if all data bus pins have high (>=31) GPIO pins. When I know it works for you I will automate the bus briver allocations.

[Bodmer]

Note that in my case I had to press the reset button after uploading the sketch to get the sketch to run.

[Bodmer]

Performance is not particularly good (320 x 480 screen) if the WR line if a low GPIO and data is a high range:

Benchmark,                Time (microseconds)
Screen fill (5 times),    309635  (16.15 fps)
Text,                     9229
Lines,                    114315
Horiz/Vert Lines,         31507
Rectangles (outline),     17487
Rectangles (filled),      471775
Circles (filled),         91066
Circles (outline),        37101
Triangles (outline),      25078
Triangles (filled),       303421
Rounded rects (outline),  25540
Rounded rects (filled),   941578
Total = 2377732us
Total = 2.3777s
Done!

When WR is also a high GPIO the results are:

Benchmark,                Time (microseconds)
Screen fill (5 times),    251569  (19.88 fps)
Text,                     7302
Lines,                    89430
Horiz/Vert Lines,         23655
Rectangles (outline),     13143
Rectangles (filled),      471773
Circles (filled),         69407
Circles (outline),        29889
Triangles (outline),      19691
Triangles (filled),       228398
Rounded rects (outline),  19667
Rounded rects (filled),   706569
Total = 1930493us
Total = 1.9305s
Done!

[h3ndrik]

i've fumbled around with the dedicated GPIO: 9af4164#diff-9326611b0edbbf2e287fc8486d4623388000ce4e8dd69e5454077d9c039cb7e8
(don't use this, it barely works, with the little time i put into this)

i'm not sure if we should try to implement it this way. it does without the differentation between ports >= 32 or lower. but the documentation says all the dedicated gpio functions need to run on the same cpu core. this could be a limitation.
(and it only lets us set 8 pins at a time. i had hoped that we could clear and set the other pins like WR together with D0-D7)

anyway... this way, it seems to be about as fast as doing it the established way, with GPIO.out

your last zip file works fine. thank you!

regarding the benchmark: i wonder how this compares to espressif's esp_lcd driver.

[Bodmer]

Great thanks letting me know it is working. I can now start integrating the changes into the published library.

I did look at using GPIO bundles after the S3 came out but the documentation was lacking at the time and I could not get it to work. This situation has improved so I have been meaning to investigate GPIO bundles again.

I have not looked at the esp_lcd code so do not know if there is a significant performance delta. The limitation is TFT_eSPI is the GPIO write speeds possible using direct regiater writes.

[svdrummer]

Compiler..Arduino
If I put the lillygo version of this library into a local folder, would this still work? I make changes, but Arduino will over write the library by itself, from time to time
Once running, the S3 display is very fast and smooth. Even if the resolution is significantly higher that past models

[Bodmer]

Maybe the IDE is set to auto update libraries? Not something I have seen.
Yes, you can add libraries to the sketch folder but thing can get confusing if libraries exist with the same name.

[ghost]

IDE 2.0.x scans and alerts when library updates are available. You can skip them, do them manually, or let the IDE do them all for you. In the last case, the Liligo version is 5 builds behind, so a click on that will overwrite all the changes needed for the S3-parallel Upper-GPIO-Pins solution from Lilygo.
For my purposes I would be most pleased if that support could be added to the existing library package, since I have both Esp32 eSPI and ESP32-S3 Parallel hardware that I want to engineer (and program) into some wearable items.
Starting from a knowledge base weaker than twice-watered tea, I managed to make this work, but without your help I will be condemned to maintaining a rogue fork that does not play nice with other older hardware.

• Wes