Solved: 8-bit ST7789V with RP2040

[elral]

I got a Tufty RP2040 Board where a Display (320x240) with ST7789V driver is included.
I went through the USER_SETUP_ID 104 where for the pins is stated:

// Note: All the following pins are PIO hardware configured and driven
// The pins are hard-coded at the moment and must not be changed here
// Connections MUST use the pins below

Within the USER_SETUP_ID 105 for 16 bit it is stated:

// PIO requires these to be sequentially increasing GPIO with no gaps

I am wondering if for the 8-bit parallel interface also a sequentially increasing of the GPIO can be used as the pins for the display are using different GPIO's (but sequentially increasing) on the Tufty board.
My first attempts seems that this is the case as the display gets "somehow" intialized but shows a completly mixed up graphic which changes during refreshing (some for the ST7789_2_DRIVER). Just for a test a used the ILI9341 driver and it gets also "somehow" initialized. The bouncing circles can be identified (much more than for the ST7789 driver), but there are two small areas with them side by side, completly wrong colours (yes, that's clear) and a lot of random pixels around these two areas. So for me it seems that the GPIO's are not hardcoded and a another assignment can be used.
For now I have no idea what is going wrong, maybe you have an idea?
My setup in the platformio.ini is:

build_flags =
    -DUSER_SETUP_LOADED=1
    -DST7789_DRIVER=1
    -DTFT_HEIGHT=320
    -DTFT_WIDTH=240
    -DTFT_BL=2
    -DTFT_BACKLIGHT_ON=HIGH
    -DTFT_PARALLEL_8_BIT
    -DTFT_CS=10
    -DTFT_DC=11
    -DTFT_WR=12
    -DTFT_RD=13
    -DTFT_D0=14
    -DTFT_D1=15
    -DTFT_D2=16
    -DTFT_D3=17
    -DTFT_D4=18
    -DTFT_D5=19
    -DTFT_D6=20
    -DTFT_D7=21
    -DLOAD_GLCD=1
    -DLOAD_FONT2=1
    -DLOAD_FONT4=1
    -DLOAD_FONT6=1
    -DLOAD_FONT7=1
    -DLOAD_FONT8=1
    -DLOAD_GFXFF=1
    -DSMOOTH_FONT=1

[elral]

At least in ST7789_Init.h in line 106 is written writedata(0xE5); // 239, but 239 is 0xEF.
Changing this improves it slightly, lines are not anymore shifted. But the image (e.g. bouncing circles) are way to small and is rotated by 90°.

/edit: Just stripped my code down just to display a rect of max. size. It is not way too small, "only" rotated by 90°?

Also I saw a VSYNC connection, I guess it has an effect.

[elral]

I found the issue #557 where exactly the same is described. I also tested the test program danem mentioned (program) and the display works fine. So im sure it is not the pin assignment. I changed the init sequence in ST7789_Init.h according the referenced program which didn't helped. Next I used your init sequence in the test program, and the display works too (except wrong colours).
The last test was to init the display via the your library but filling the screen by direct access to the pins with the functions from the test program. Still no success, always just a part of the display gets written (lke the picture above).

For me it seems to be "some where" how the data are transferred to the parallel bus. That's getting out of my knowledge unfortenutely.

Thanks and I hope it helps.

/edit: Still no success, always just a part of the display gets written (lke the picture above). <- This is not true, I gets nothing written. I saw the display clear

/edit2: Sorry multiple answers. With setting CS to LOW I can write to the display by the functions from the testprogram (see above). So the initialisation runs fine (but havn't checked the colors, will come later).

/edit3: OK, TX_FIFO= someData seems not be working, e.g. it does not set the correct window within setWindow(). Might be that in this case the pin definition must be as in the USER_SETUP_ID 104 ? tft_Write_8(d) which seems to use also the state machine is working, therefore the display gets correct initialized.

[Bodmer]

Post in #2128 seems to have the same problem. This suggests to me that the library is not compatible with a parallel interface based ST7789 display for some reason. That display seems to work fine with the SPI interface though!

I do not have a paralle based ST7789 so am unable to test and debug. I will try to get hold of one and investigate but that may take a significant time as I am busy with other priorities at the moment.

[Bodmer]

I found #1773 and proposed a solution that seems to work.

Change the 1 in the line in the file here to 2 and try that.

This slows down the interface slightly.

[Bodmer]

Another way to slow things down to test if the interface speed is too fast for that display is to use the Arduino IDE menu to reduce the CPU clock frequency, the display interface slows down proportionally.

[elral]

@Bodmer thanks so much!!! With setting #define DIV_UNITS 2 it is perfectly running.
Would be good to have this in the library like in #1773 proposed.
I can prepare a pull request as I have to clone the repo anyway to have this change in my different variants (platformIO) and maybe to include later in our open source project.
I have to set TFT_RGB_ORDER=0 to get the same colours as the ILI9341 used before/parallel.

[Bodmer]

Thanks for letting me know. I have an update ready so will push that later today.

[Bodmer]

I have updated the Github master library. The speed can now be set in the setup file, example:

// For RP2040 processor and 8 or 16 bit parallel displays:
// The parallel interface write cycle period is derived from a division of the CPU clock
// speed so scales with the processor clock. This means that the divider ratio may need
// to be increased when overclocking. I may also need to be adjusted dependant on the
// display controller type (ILI94341, HX8357C etc). If RP2040_PIO_CLK_DIV is not defined
// the library will set default values which may not suit your display.
// The display controller data sheet will specify the minimum write cycle period. The
// controllers often work reliably for shorter periods, however if the period is too short
// the display may not initialise or graphics will become corrupted.
// PIO write cycle frequency = (CPU clock/(4 * RP2040_PIO_CLK_DIV))

//#define RP2040_PIO_CLK_DIV 1 // 32ns write cycle at 125MHz CPU clock

#define RP2040_PIO_CLK_DIV 2 // 64ns write cycle at 125MHz CPU clock

//#define RP2040_PIO_CLK_DIV 3 // 96ns write cycle at 125MHz CPU clock

[elral]

Thank you very much!

[JojoS62]

great, I could switch also easily code from ILI9341 display to the tufty2040. I have used lvgl and it works also. Only the colors are not ok, yellow is displayed as cyan. Any ideas what needs to be changed?
my project/platformio.ini with the defines (same as in first post):
https://github.com/JojoS62/Pico-TFT

[Bodmer]

The rgb colour order needs changing, add one of these two options:

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

Also check the correct display driver is specifed in your setup file e.g:
#define ST7789_DRIVER

[JojoS62]

changing the RGB order to BGR did it, I added -DTFT_RGB_ORDER=TFT_BGR to the options above.
Thanks for your quick reply and this great library!