Question Support for Waveshare ILI9488 + RP2040 (Pico-ResTouch-LCD-3.5)

[venice1200]

Hi,
Happy new Year and all the best for you.

Waveshare offers an nice ILI9488 based TFT for the RP2040 and it looks to me that it uses an SPI->16Bit design like your library supports for the 9486.
The ILI9486 RPi display must be of the Waveshare design and use a 16 bit serial interface based on the 74HC04, 74HC4040 and 2 x 74HC4094 logic chips.
https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5
https://www.waveshare.com/w/upload/8/85/Pico-ResTouch-LCD-3.5_Sch.pdf

I just want to ask if your library is able to drive this TFT with the RP2040?

Many thanks for your Library
Regards

[Bodmer]

Yes, you can drive the display with SPI, I have only tested the ILI9486 though. You may find you need to limit the SPI clock rate to 20MHz, although 32MHz may work.

That interface design requires 16 bit commands so you need to put #define RPI_DISPLAY_TYPE in the setup file.

To use the display you need to defined the display driver and correct pins in the setup file, e.g. #define ILI9488_DRIVER

The display appears to interface with SPI port 1 pins so you also need to include #define TFT_SPI_PORT 1 as the Pico defaults to using SP port 0.

[venice1200]

Hi,
#define RPI_DISPLAY_TYPE was the key to get it working.
32MHz is working as well.
I haven't tested touch.
The option #define RP2040_PIO_SPI doesn't work for me but I think it's not needed as of the SPI Frequency (20-32MHz).
Many thanks.

Here is my working (20MHz) config used with the "Master" from 2022-01-13.

// Setup000_RP2040_ILI9488.h
// Works with Waveshare "Pico-ResTouch-LCD-3.5" HAT (SKU: 19907)

//#define RP2040_PIO_SPI
#define RPI_DISPLAY_TYPE

#define ILI9488_DRIVER     // WARNING: Do not connect ILI9488 display SDO to MISO if other devices share the SPI bus (TFT SDO does NOT tristate when CS is high)

#define TFT_MISO  12  //0
#define TFT_MOSI  11  //3
#define TFT_SCLK  10  //2
#define TFT_CS     9  //20  // Chip select control pin
#define TFT_DC     8  //8   // Data Command control pin
#define TFT_RST   15  //19  // Reset pin (could connect to Arduino RESET pin)
#define TFT_BL    13  //       LED back-light

//#define TOUCH_CS 21     // Chip select pin (T_CS) of touch screen

#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#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 LOAD_FONT8N // Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

#define SMOOTH_FONT

#define TFT_SPI_PORT 1 // Set to 0 if SPI0 pins are used, or 1 if spi1 pins used

// #define SPI_FREQUENCY   1000000
// #define SPI_FREQUENCY   5000000
// #define SPI_FREQUENCY  10000000
#define SPI_FREQUENCY  20000000
// #define SPI_FREQUENCY  27000000
// #define SPI_FREQUENCY  32000000
// #define SPI_FREQUENCY  40000000
//#define SPI_FREQUENCY  70000000

// Optional reduced SPI frequency for reading TFT
#define SPI_READ_FREQUENCY  20000000

// The XPT2046 requires a lower SPI clock rate of 2.5MHz so we define that here:
#define SPI_TOUCH_FREQUENCY  2500000

[Bodmer]

Good to hear it is working for you.

At the moment the PIO option does not support 16 bit commands, this will be added at some point.

[venice1200]

I stopped testing this Display as it's too weird to get the components running with the Arduino IDE.
Maybe later.

[ruebarb]

This screen is the best I have used so far, best quality, great view angles and the fast. Winner on all aspects. The fastest I could get SPI without color issues
SPI_FREQUENCY 60000000
I also needed this TFT_INVERSION_ON

Benchmark Time (microseconds)
Screen fill 432798
Text 27385
Lines 343151
Horiz/Vert Lines 37080
Rectangles (outline) 21407
Rectangles (filled) 1045586
Circles (filled) 165967
Circles (outline) 120304
Triangles (outline) 70200
Triangles (filled) 379445
Rounded rects (outline) 53184
Rounded rects (filled) 1069713
User_Setup(Pico-Res-Touch).txt

[plomari]

The fastest I could get SPI without color issues

That appears to be as slow as Bodmer's test, 11 fps.

I do not favour that Waveshare shift register based display design, it was designed for a Raspberry Pi and it has a logic race hazard design flaw,

What is the logic race? Do you know why Waveshare designed it like this, instead of just connecting the ILI9488 with SPI directly? This seems roundabout and restrictive for no reason. It's slower, forces the pixel format to 16 bit (if I understand correctly), and you can't read back anything from the ILI9488. (Also, why the heck did they add a sram chip, a SD card port, and a reset button to the board?? I wonder why they didn't just solder the RP2040 on the board too.)

Does anyone know a better display? The TFT and the display chip are actually OK, just not the wiring. The fact that you can stick the RPI pico on the board is convenient for quick testing, but it's not a requirement to me.

[Bodmer]

The SPI clock rate is rounded down to the nearest integer division of 125MHz (CPU clock) so available rates are 31.25MHz and 62.5MHz. This means 60MHz will be rounded down to 31.25MHz, hence the same as 11 fps.

I think the original RPi circuit based on shift register was created by by someone who did not analyse the design properly but found "it worked", subsequently the design was was adopted by some Chinese vendors, again without analysing the design because support software was already freely available. It worked on the RPi but is not a good design for other microcontrollers. Since then better designs have appeared like this MHS 4.0 display. The race hazard is between the write strobe and data setup time paths. The 74HC4094 has long propagation times when powered from 3.3V that can be more than a SPI clock period and that delay is temperature dependant.

The TFT_eSPI library supports a lot of displays, SPI and 8 bit parallel. I have just added 16 bit parallel support which has pretty blistering performance on a 16 bit HX8357C display:

Benchmark,                Time (microseconds)
Screen fill (5 times),    20494  (243.97 fps)
Text,                     4219
Lines,                    43113
Horiz/Vert Lines,         1912
Rectangles (outline),     1128
Rectangles (filled),      50039
Circles (filled),         13823
Circles (outline),        15219
Triangles (outline),      10882
Triangles (filled),       20275
Rounded rects (outline),  5908
Rounded rects (filled),   51210
Total = 238222us
Total = 0.2382s

Yep, it is clearing the 320x480 screen in ~4ms!

However for hand wiring a display the 4 wire SPI types are less error prone. The ILI9488 is slower then others with SPI as it needs 3 bytes per pixel instead of 2, on the other hand the ILI9488 displays are readily available.

If you want a ready built RP2040 board with TFT then options are more limited. Dustin Watts has designed a board for SPI displays and the RP2040 here. I use this board with multiple display types that have the same connection pin header.

[plomari]

I think the original RPi circuit based on shift register was created by by someone who did not analyse the design properly but found "it worked", subsequently the design was was adopted by some Chinese vendors, again without analysing the design because support software was already freely available.

That's sad. These displays are extremely widely available, and because of such a dumb mistake, they can be used at only 1/3rd of their performance or worse.

MHS 4.0 display

It's linked in the README of this library too, but I didn't find this particular display for sale anywhere. I've seen some SPI boards that obviously don't have the 4 ICs needed for the botched SPI -> parallel translation, but they didn't have the MHS text on the photos of their PCBs.

Also, the Waveshare pico display is actually nice. It's an IPS screen, which seems to be rare for 3.5" or 4" displays. Is there any chance that I could modify the Waveshare board to switch it to direct SPI? (I suppose even if possible, this would require some major skills to change the IM configuration pins and to rewrite the data lines... which means "no".)

The race hazard is between the write strobe and data setup time paths. The 74HC4094 has long propagation times when powered from 3.3V that can be more than a SPI clock period and that delay is temperature dependant.

Thanks for explaining. I saw in the 74HC4094 datasheet that the maximum frequency depends on voltage and temperature with probably not enough headway for this use case, which I find scary and questionable.

However for hand wiring a display the 4 wire SPI types are less error prone. The ILI9488 is slower then others with SPI as it needs 3 bytes per pixel instead of 2, on the other hand the ILI9488 displays are readily available.

Isn't the pixel format over SPI configurable? Section 4.7.2 in the ILI9488 datasheet. It says that it's only 1 byte for the 3 bit per pixel format. It doesn't describe how the 16 bit format works - I assume it's either 2 bytes per pixel, or not supported. (Only the 3 bit and 18 bit formats are explained, but 16 bit is listed as available.)

Another question: could the 18 bit parallel interface be used in theory, on a board with support for it? Of course that's a lot of wires, but the pico has sufficient GPIOs.

Dustin Watts has designed a board for SPI displays and the RP2040 here. I use this board with multiple display types that have the same connection pin header.

I don't really need such a "combiner". But for people who don't want to solder it may be a nice solution, and it looks superior to the Waveshare board. (Still, wouldn't it be nicer to solder the RP2040 chip directly to the PCB?)

[Bodmer]

MHS4.0 (with ST7796) display is sometimes available on Aliexpress.

Similar displays are available from Waveshare but identifying the controller will take some research. Would be a risk buying one. One user reported the 3.5" Waveshare screen works and has an ILI9486 controller. I would not advise buying one though as I have not tested them.

The ILI9488 data sheet is in error (based on my empirical testing). The 16 bit mode does not work with SPI. This is the reason for this code. Similarly the ILI9486 does not work in 16 bit colour mode for SPI.

18 bit parallel would work but is not supported by TFT_eSPI. The ILI9488 does support 16 bit colour in 8 bit parallel and 16 bit parallel modes.

On Dustin's board you can "surface mount" the Pico direct on the board (pads are provided for this). I was going to do this on mine but luckily realised you do not have the height gap required to plug in a USB lead and would have to either source a very low profile lead or make one! Ideally the USB connector would be at the edge of the board but I guess that was not considered.

[plomari]

Do some ILI chips support 16 bit over SPI? I looked at the ST7796 datasheet, and it seems to explicitly support 16 bit over SPI. Are ST chips "better" than ILI, or does it depend on the exact chip?

Is it possible to do 18 bit over 8 bit parallel? Or 18 bit over 16 bit parallel? In particular, I dislike that the Waveshare pico display restricts colors to 16 bit while still being very slow. (I've purchased it recently and I can still send it back.)

Basically I'd like to keep as many options open as possible to use the full extent of the display (18 bit colors, high framerate), while being able to go to a lower depth format when I notice that CPU/memory use are too high to get what I want.

18 bit parallel would work but is not supported by TFT_eSPI.

Does the library support 18 bit colors at all? I suppose this would require going 32 bit per pixel for performance reasons, but from what I can see in the code, everything is 16 bit color centric. Not a huge problem though, software can be fixed, but hardware can't.

[Bodmer]

Answers in order:

1. Yes
2. Yes, already implemented for SSD1963 which uses 3 byte transfer over 8 bit parallel
3. and 4. In my view 18 bit 666 colour has little benefit over 16 bit 565 because the Gamma colour match on these displays is typically quite poor, for example the colour band widths in a rainbow spread are often not equal. Gamma and internal voltage settings settings are not well documented and vary between screen suppliers (There are now 8 gamma/bias voltage options in the ILI9481 init sequence now!). The library functions have 32 bit colour parameters for future 8 bit ARGB but these are not used yet (may never be!) and all colour exchanges are 16 bit. For 18 bit displays the 6 bits of R and B are just 5 bits shifted left. There is a slight benefit for wide spread colour gradients with 18 bit colour(64 brightness levels v 32).

[Bodmer]

Another point I forgot re colour resolution is that IPS displays have better viewing angle, they also tend to be mode expensive. For most displays the viewing angle has a dramatic effect on the colour appearance. Many displays are also designed for phones hence the optimum visual orientation is portrait. The "best" viewing angle IPS display I have has a HX8357C controller with good colours over almost full 180 angle. Sadly these are no longer available.

[plomari]

1. Yes

To ILI 16 bit SPI, or ST being generally better than ILI?

Another point I forgot re colour resolution is that IPS displays have better viewing angle, they also tend to be mode expensive. For most displays the viewing angle has a dramatic effect on the colour appearance.

This Waveshare pico LCD is sold as IPS and seems to have very good viewing angels. No shifting of any kind.

I don't know how to check 18 bit versus 16 bit color modes on it, if even possible.

[Bodmer]

1. Yes to both, however your decision criteria seem to be based more on image quality whereas I typically only glance at the displayed data occassionally and thus colour fidelity is a low priority, update speed is not particularly important to me either but nice to have when the display changes significantly.

The ST7796 display I have is not IPS even though the Chinese vendor claimed it was. For reliable information you tend to pay more (or for Adafruit a lot more) for the display. The best vendor I have bought from for truthfulness, completeness of information and continuity of supply is BuyDisplay.com.

The Pico Waveshare display is 16 bit colour. The interface is serial but the circuit converts to 16 bit parallel (write strobe every 16 clocks) so the parallel colour modes are available.

If you are not making an interactive screen with the need for rapid graphics updates, then I would stick with the display you have and get your project working.

[AndrewCapon]

Hi Guys,

I found this conversation while looking for reasons why this WaveShare ResTouch is so slow, thinking it was something I was doing wrong.

Looks like it isn't me getting something wrong.

I wonder if I could ask a quick question as there is a level of expertise here far beyond mine!

I have a load of 9341s that work well but was looking for a better looking display with better viewing angles.

Are there any 9341 320x240 IPS displays with touchscreens anyone can recommend?

[venice1200]

Double check this one
https://www.adafruit.com/product/1770

[Bodmer]

As far as I am aware there are no ILI9341 wide viewing angle (aka IPS) displays on the market.

The choice of other controller type is dependant on the screen size you need. A Google serach will show that there are quite a few ST7789 based IPS technology screens available. For example this one:
https://shop.pimoroni.com/products/2-0-320x240-color-ips-tft-display-with-microsd-card-breakout?variant=29413854249043

TFTs direct from China will be cheaper but you need to be careful as some vendors do not make it clear which option/controller you are actually buying!

[AndrewCapon]

Hi Guys, thanks very much for the pointers. I will have a look at those...

[simlc0523]

Thanks to all the great info above, I've been able to get my lcd display running with the RP2040. However, I have run into a problem when I try to run example code that accesses the SD card. The only Arduino example file I can find is the ESP32_SCcard_jpeg sketch under eTFT_SPI/Generic. When I compile it, a number of errors are generated relating to the fact that there are multiple SD libraries. I've forced the compile to use one SD library or another, which results in different errors, as each SD library is slightly different. I found the SD library related to the ESP32 board and it caused a different set of errors. I realize that the RP2040 is a recent port to the Arduino IDE, but I'm hoping someone has run across this issue and has figured it out. Thanks!

[archearth]

Hi there, I assume you have the same display as me, this one: https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5. From what info I was able to gather this display uses SPI1 to work. And it seems that the SD card uses the SPI1 as well. I was able to read from the SD card by setting the following SPI1 pins in setup and then passing SPI1 to the SD.begin().

However, with this setup I think I am running into SPI1 conflicts between the TFT and SD card and I get this as a result when I try to read a GIF from the SD card.

So this is where I am currently stuck and not sure what is happening or how to solve this. If @Bodmer or anyone else have any insights or suggestions, those will be kindly appreciated.