News: Raspberry Pi Pico (RP2040) support

[Bodmer]

I have updated the TFT_eSPI master library (only[url=https://github.com/Bodmer/TFT_eSPI] available from Github[/url] at the moment).

The library has been tested with the Raspberry Pi Pico connected to an ILI9341 4 wire SPI display.

The examples are working and performance is quite good.

For those familiar with the "Graphicstest" example these are the results:

Benchmark,                Time (microseconds)
Screen fill (5 times),    114981  (43.49 fps)
Text,                     31986
Lines,                    128851
Horiz/Vert Lines,         18031
Rectangles (outline),     10210
Rectangles (filled),      241497
Circles (filled),         70702
Circles (outline),        58318
Triangles (outline),      33224
Triangles (filled),       109793
Rounded rects (outline),  30585
Rounded rects (filled),   255167
Total = 1103345us
Total = 1.1033s

The Jpeg decode is slower that processors that have a dedicated FPU but it is still acceptable.

Sprites work very well and the large RAM means full frame buffers are possible for the smaller displays (e.g. 240x320).

[Bodmer]

The official Arduino board package for the Raspberry Pi Pico was released recently. Quite a few warnings get reported but I have updated the library so it compiles and runs fine.

So the library master copy is now compatible with both the official board package and Earle Philhower's.

Update: PIO capability has been edded. The PIO functions only work with Earle Philhower's board package:
https://github.com/earlephilhower/arduino-pico

[Dresch123]

Thanks very much! My definition looked really similar (same pins even)... I am beginning to wonder if I am having some problem with my Pico Pi hardware.
Did you use Mbed or the Philhower core?
Thanks again! Bill

[Dresch123]

Thanks again! Using the MBed core I got the GC9A01 working.
It is a beautiful display and very low power.

[Bodmer]

No, SPI mode is fixed at 0 for all displays except ST7789 since I found my display only worked in mode 3. See here.

A simple check could be added to make the mode defined in a user setup but there has not been a need for that yet:

#ifndef TFT_SPI_MODE 
  #if defined(ST7789_DRIVER) || defined(ST7789_2_DRIVER)
    #define TFT_SPI_MODE SPI_MODE3
  #else
    #define TFT_SPI_MODE SPI_MODE0
  #endif
#endif

[Dresch123]

I hope you don't mind me bringing up the ST7789 without CS issue again but I found a better workaround than CS hardware change. And that conversation is locked.
My display worked with SPI Mode 2. I changed the Mode Set like this:
// Processor specific code used by SPI bus transaction begin/end_tft_write functions
// #define SET_BUS_WRITE_MODE spi_set_format(SPI_X, 8, (spi_cpol_t)(TFT_SPI_MODE >> 1), (spi_cpha_t)(TFT_SPI_MODE & 0x1), SPI_MSB_FIRST)
//XXXX Temp fix
#define SET_BUS_WRITE_MODE spi_set_format(SPI_X, 8, (spi_cpol_t)1, (spi_cpha_t)0, SPI_MSB_FIRST)
So with no CS hardware change on this display, I got:

Thanks again!

[Bodmer]

That's interesting. The data sheet indicates mode 0 is correct (clock idle low, rising edge sample). Mode 3 (clock idle high, falling edge sample) is the only one I found worked on ESP8266 and ESP32.

Mode 0 should be correct, so this all points to startup conditions/state of the clock line being important for the ST7789. Because there is no CS line to sync the correct clock transition to the correct data bit. You would expect a reset to work after setting the SPI mode but it doesn't. It may be the RP2040 board package always switches to mode 0 after the library closes the transaction, causing a clock idle state change and extra clock edge.

[Dresch123]

I came across the Mode 2 setting here:

---

https://forums.raspberrypi.com/viewtopic.php?t=300583

Re: Interfacing PICO with LCD ST7789
Tue Feb 09, 2021 12:17 am
Which st7789 display do you have?

I'm asking because I couldn't get the pio example to work - I had to code up a standard spi hack to get it to run.

I had to set the polarity as

spi_set_format(SPI_PORT,8,SPI_CPOL_1,SPI_CPHA_0,SPI_MSB_FIRST);

before my display would work.

which makes me think some of the st7789's have alternate polarity or something?

---

It seems the ifndef decision tree could include ST7789 and RP2040. I think I will implement that way.
I hope to get in more of these small displays in soon to confirm.
Thanks again Bodmer.

[Bodmer]

Interesting again, the Raspberry Pi PIO example worked fine on my display that has a CS line. This does suggest display differences, another explanation is that idle state changes are occurring between transactions, hence the variation associated with using different processors.

[Bodmer]

New PIO code has been added at v2.3.45 for the RP2040 to allow the fast SPI PIO capability of the RP2040 to be used with 18bit colour SPI displays such as the ILI9488. Example setup:

#define RP2040_PIO_SPI   // Note: TFT_eSPI touch functions not available when PIO used.

#define ILI9488_DRIVER

#define TFT_MISO  0
#define TFT_MOSI  3
#define TFT_SCLK  2
#define TFT_CS   20
#define TFT_DC   22
#define TFT_RST  21

#define LOAD_GLCD
#define LOAD_FONT2
#define LOAD_FONT4
#define LOAD_FONT6
#define LOAD_FONT7
#define LOAD_FONT8
#define LOAD_GFXFF

#define SMOOTH_FONT

#define SPI_FREQUENCY  63000000