A 480 x320 plug and play display for Pico 2 would be real nice. Either ST7796 or ILI9488 driver and 4 buttons.
Waveshare has one (Pico-Res-Touch-LCD-3.5, with touch and SD-card). It uses some weird electronics (two SIPO shift registers) to translate from 8-bit SPI to 16-bit parallel, so you can’t just use a “normal” ILI9488 driver. I2C and all the pins not used by touch/sd are not broken out.
It would certainly be nice to have a high-quality version from Pimoroni.
1 Like
Count me in for a 480 x 320 Display Pack. Or a Tufty version of same. =)
1 Like
Indeed, this Waveshare approach is “unconventional” to say the least. Having experimented with such a screen (albeit labelled for the “RPi”), my conclusion was that they introduced the shift register front-end to the parallel interface to potentially squeeze a bit more bandwidth out of it, since the parallel interface might have slightly better performance, but the whole arrangement presents several compatibility issues for limited benefit.
My personal guess is that the engineers at Waveshare just copied an existing old design from some other driver chip, which only had a parallel interface. Unless the serial interface of the ILI-chip is much slower than the parallel interface and also slower than the serial (out) interface of the Pico, the whole design does not make sense.
I always value having free GPIOs higher than bandwith. The Tufty and Presto both use a direct parallel interface from the Pico to the driver, but the Tufty uses eight pins and the Presto 18+ pins (RGB666 plus clock and sync pins). That is ok for users, but not for makers.
I noticed a reference an ST7701 display driver on one of the Pimoroni GitHub repo’s. Up to I think 480x320? That was a while back and haven’t see anything else since. Jun last year some time.
The Waveshare screen I have been using employs an ILI9486 controller. It seems that the parallel interface supports a higher throughput using a slightly slower transfer clock, but obviously benefiting from transferring many bits in parallel. I imagine that this was the motivation for using the 8080 interface instead of the SPI interface.
However, it becomes quite complicated. As another discussion indicates, the “SPI” interface it exposes to the outside world requires 16-bit units, even though the commands being issued to the controller use 8-bit values, so the data needs to be padded in a non-standard way.
Another annoyance is the way that the command transfer rate has to be lower than the picture data transfer rate, but that is not completely unprecedented. Combining all of these things and then providing the usual level of documentation is quite hostile to the purchaser. No-one should be obliged to reverse engineer their purchase, nor should the existence of a Linux driver let the manufacturer off the hook.
I have written my own CircuitPython driver which works for both the Pico and the RPi version of the display. The driver needs a hacked version of the core CircuitPython display-code (because of the padding), but all in all I only had to change three lines and add 8 (mainly for the padding of coordinates).
And I don’t use a different command transfer rate. That wasn’t necessary.