Pico 2 W with 320x480 display

[ctimmer]

I purchased this Pico Breadboard Kit (docs).
The included instructions indicated the Pico 2 did not have enough memory to drive the 320x480 display.

I am using a Pico 2 W with this driver.

My code (mostly from the examples):

#Display from github:
#SPI0
#GP2 CLK
#GP3 DIN
#GP5 CS
#GP6 DC
#GP7 RST

import st7789_base, st7789_ext

display = st7789_ext.ST7789(
    SPI(0, baudrate=10000000, phase=0, polarity=1),
    width=320, height=480,
    reset=machine.Pin(7, machine.Pin.OUT),
    dc=machine.Pin(6, machine.Pin.OUT),
    cs=machine.Pin(5, machine.Pin.OUT)
#    inversion = False,  # Not defined in parameters ???
)
display.init(landscape=True) #,mirror_y=True)

display.enable_framebuffer()

backlight = Pin(5,Pin.OUT)
backlight.on()
display.fill (display.color(255,0,0))
mycolor = display.color(255,0,255) # RBB
display.rect(10,10,50,50,mycolor,fill=True)

display.show()

The display initializes without a memory fault but I can't seem to get anything to display on the screen. Has anyone had success using this board or using this size of display?

Thanks,
Curt

[peterhinch]

The ST7789 only supports displays up to 320*240. Your display must use a different controller. If you determine the actual controller we may be able to point you at a driver.

[ctimmer]

The controller you can get for the breadboard is written in C++. I was really wanting to use this with MicroPython.

I used this controller module because is was supposed to be compatible with a number of similar type displays. The display is described as a ST7796SU1. None of my searches yielded a controller, only suggestions to modify similar modules. I also did a search for ST7796SU1 datasheet and came up empty.

Thanks for your input,
Curt

[peterhinch]

The ST7796S datasheet is available. The final U is probably a packaging option. I wonder if it is compatible with the ILI9488 which is widely used at this resolution.

It's worth noting that an RGB565 framebuffer for such a display would require 307,200 bytes - impossible on an RP2. Even the 4-bit ILI9488 driver for nano-gui is too big for the Pico W at 76800 bytes, but will work on Pico 2. I assume that the supplied C driver is not framebuffer based.

[DoubleVee73]

Can I just check some maths here please as I am working with large frame buffer memory sizes on the RP2 and for RGB565 and 240x320, my maths tells me the buffer is 240x320x2 =153,600 bytes? Please could you confirm as I am concerned I have missed something here 😀

[peterhinch]

Sure. The display used by @ctimmer is 320x480, with double your number of pixels.

[DoubleVee73]

And the moral of the story.....always read the full thread 😂 Sorry to disturb @peterhinch !

[ricksorensen]

You may need to fiddle around with the initialization sequence for the larger display. See:

https://coxxect.blogspot.com/2025/02/use-st7796-spi-lcd-on.html
This is using circuitpython but it indicates modifications needed.

This in turn refers to:
https://www.waveshare.com/wiki/3.5inch_Capacitive_Touch_LCD#Working_with_ESP32S3

near the end of this page is a link to a zip file for Pico demonstration of basic 7796 driver in micropython.
https://files.waveshare.com/wiki/3.5inch%20Capacitive%20Touch%20LCD/3.5inch_Capacitive_Touch_LCD_Demo_Pico.zip

I do not have this display so I cannot verify/test. Good luck.

[ctimmer]

Thanks everyone, I'll check out the suggested links.
Curt

[ctimmer]

My original code would have worked if the spi interface had been set up correctly. Here is my "working" code:

from st7789_ext import ST7789

spi = SPI(0, baudrate=27000000, sck=Pin(2), mosi=Pin(3), phase=0, polarity=0)
display = ST7789 (
        spi ,           #spi (spi): spi object **Required**
        480 ,           #width (int): display width **Required**
        320 ,           #height (int): display height **Required**
        Pin (7) ,             #reset (pin): reset pin
        Pin (6) ,             #dc (pin): dc pin **Required**
        Pin (5)               #cs (pin): cs pin
    )
# init(landscape=False,  # init functions with defaults
#      mirror_x=False,
#      mirror_y=False,
#      is_bgr=False,
#      xstart = None,
#      ystart = None,
#      inversion = False)
display.init(landscape=True, is_bgr=True, inversion=True)
display.enable_framebuffer()
display.fill (display.color(r=255, g=255, b=255))
#
display.rect(x=10, y=10, w=100, h=100, color=display.color(r=255, g=0, b=0), fill=True)
display.rect(x=120, y=10, w=100, h=100, color=display.color(r=0, g=128, b=0), fill=True)
display.rect(x=230, y=10, w=100, h=100, color=display.color(r=0, g=0, b=255), fill=True)

# text(self,x,y,txt,fgcolor,bgcolor)
display.text (x=20, y=120,
              txt="Hello World",
              fgcolor=display.color(r=255, g=255, b=255) ,
              bgcolor=display.color(r=0, g=0, b=0))

The display updates very fast. Output from the code above:

Thanks again,
Curt

[peterhinch]

So it's as I thought - an ILI9488. The driver doesn't subclass FrameBuffer, which avoids instantiating a large buffer. The downside is considerable code complexity, duplicating the functionality of FrameBuffer in Python code.

[ctimmer]

One final note:
I could not display images reliably at the spi baudrate set to 270_000_000. Had to unplug and plug in the pico to get things running again. Lowering the baudrate to 100_000_000 seems to have fixed the problem.

Curt

[peterhinch]

Those rates seem implausible. If you issue

spi = SPI(0, baudrate=100_000_000, sck=Pin(2), mosi=Pin(3), phase=0, polarity=0)
print(spi)

you will find the actual baudrate which is probably in the region of 30MHz. On the RP2040 I have to hand, this code reports 24MHz.

[ctimmer]

I found the buadrate in the c++ driver initialization. Maybe this doesn't work the same way as MP.
Curt

[peterhinch]

You'd need to study the hardware datasheet. The SPI clock rate is determined by the chip's hardware clocks. The maximum working baudrate will also be determined by the display controller's hardware: the ILI9488 datasheet (section 17.4.3) gives 50ns for the serial clock cycle time (write) i.e. 20MHz. In practice display controllers can usually be overclocked (I use 24MHz) but 100+MHz? The author of that c++ code is having a laugh.