ST7789 and parallel

[jayhay]

First up, thank you so much for your excellent work, and supporting your library with so many responses.

I've been trying to get an ESP32 to work with a 240x240 round TFT display that only has an 8-bit parallel interface to its ST7789 controller. I've had some luck getting a standard Arduino to interface with the display, so I know it's not faulty - am I correct in understanding that your library's ST7789 drivers only work with SPI? I can't seem to get it working over parallel to the ST7789 in this display.

Thanks in advance!

[Bodmer]

I do not have an ST7789 with parallel interface. If you do not need the slightly higher performance of the parallel interface then you could configure the display for SPI providing you have access to the mode pins.

The library should work with a parallel ST7789 though because the init sequence is identical. Check you have correctly configured the setup by running the setup diagnostic sketch.

[jayhay]

Unfortunately I don't have access to the mode pins, just the parallel interface. I've tried running both st7789 drivers (to be honest, I've tried them all, just out of interest!), but with no success. Running the setup diagnostic gives me the following output:

[code]
TFT_eSPI ver = 1.4.20
Processor    = ESP32
Frequency    = 240 MHz
Transactions = Yes 
Interface    = Parallel 
Display driver = 7789
Display width  = 240 
Display height = 240 

TFT_CS   = D33 (GPIO 33)
TFT_DC   = D15 (GPIO 15)
TFT_RST  = D32 (GPIO 32)

TFT_WR   = D4 (GPIO 4)
TFT_RD   = D2 (GPIO 2)

TFT_D0   = D12 (GPIO 12)
TFT_D1   = D13 (GPIO 13)
TFT_D2   = D26 (GPIO 26)
TFT_D3   = D25 (GPIO 25)
TFT_D4   = D17 (GPIO 17)
TFT_D5   = D16 (GPIO 16)
TFT_D6   = D27 (GPIO 27)
TFT_D7   = D14 (GPIO 14)

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled
[/code]

Any other guidance would be very welcome. I've triple checked all my connections, they are all correct as per the pin numbers in the diagnostics.

[Bodmer]

Try this, change this line in your setup:

define ST7789_DRIVER

to this:

define ST7789_2_DRIVER

Then a simplified init sequence will be used.

[jayhay]

No significant change with that amend. However, I have noticed that when I run any of the examples, the screen will flash up first with a noise of randomly coloured pixels across the whole screen. If I use the st7789_2 drivers, this noise is all over the screen. With the of st7789 driver, I get "shadows" or blocks of black on the left side of the screen amongst the noise of random pixels. This flashes up for just a fraction of a second before the screen goes blank. If it's any use, this is the screen I'm interfacing with: http://shorturl.at/tBD28

[Bodmer]

I am running our of ideas. It looks like the display is not getting setup correctly. The ST7789_2_DRIVER initialisation code is as minimal as it can be for getting a display working. Since commands are not being received this implies some crossed wires in the connections, so all I can suggest is another check that they are correct.

Unfortunately without a display I cannot investigate the possible causes.

[Paulie92]

Hello @Bodmer ,

do you have feedback from any user of your great library, that the parallel interface works with the ST7789 drivers? I also would like to use this display, which has unfortunately only 8/6bit interface.

Thank you for your answer in advance!

[danem]

I am experiencing similar problems with the ST7789 parallel interface on STM32. I've confirmed that the display works and my wiring is correct with this code provided by the display manufacturer. Replacing the init code included in this library with the code found in the aforementioned sketch produces some activity on the display, but doesn't fix things. I've gone as far as replacing the default initialization code in ST7789_Init.h (while still using the library's writecommand interface), and using only the manufacturer provided drawing code (that i've confirmed works on my STM board) without any luck, suggesting the problem may lie in how the parallel data bus is being accessed. I don't have a logic analyzer at the moment but I'll be able to provide some additional data on that later.

#include "Arduino.h"
#include <SPI.h>
#include <TFT_eSPI.h>   

TFT_eSPI tft = TFT_eSPI(); 

// Manufacturer drawing code
// ...

void setup () {
  tft.init();
}

void loop()
{ 
  disp();
  delay(500);
  disp2();
  delay(500);
  Border_Fill();
  delay(500);
}

Here is my setup file:

#define STM32
#define TFT_PARALLEL_8_BIT
#define ST7789_DRIVER   
#define TFT_WIDTH  240
#define TFT_HEIGHT 320

#define TFT_CS   -1 
#define TFT_DC   D8  
#define TFT_WR   D9  
#define TFT_RD   D10
#define TFT_RST  D11

#define TFT_D0   D0
#define TFT_D1   D1
#define TFT_D2   D2
#define TFT_D3   D3
#define TFT_D4   D4 
#define TFT_D5   D5 
#define TFT_D6   D6 
#define TFT_D7   D7 

#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#define SMOOTH_FONT

#define SPI_FREQUENCY  20000000
#define SPI_READ_FREQUENCY  20000000

[danem]

I wasn't really able to discern much with my logic analyzer. With some more poking around I have been able to get some more "sensible" results. With the above setup (and TFT_INVERSION_OFF) I get this result when running the following code:

#include "Arduino.h"
#include <TFT_eSPI.h>
#include <SPI.h>

TFT_eSPI tft = TFT_eSPI();

void setup () {
    tft.init();
}

void loop () {
   tft.fillScreen(TFT_BLACK);
   delay(1000);
}

Changing TFT_BLACK to TFT_RED produces a gray box instead.

Here is the output of the diagnostic sketch:

[code]
TFT_eSPI ver = 2.3.70
Processor    = STM32
Transactions = Yes
Interface    = Parallel
Display driver = 7789
Display width  = 240
Display height = 320

>>>>> Note: STM32 pin references above D15 may not reflect board markings <<<<<
TFT_DC   = D8
TFT_RST  = D11
TFT_WR   = D9
TFT_RD   = D10

TFT_D0   = D0
TFT_D1   = D1
TFT_D2   = D2
TFT_D3   = D3
TFT_D4   = D4
TFT_D5   = D5
TFT_D6   = D6
TFT_D7   = D7

Font GLCD   loaded
Smooth font enabled

[/code]