Pico-Res-Touch-LCD 3.5 (Shared SPI) compatibility

[matthiasguertler]

Hello,

i am currently experimenting with the Pico-Res-Touch-LCD 3.5 from Waveshare.

It uses:

• ILI9488 Driver for the display
• XPT2046 as touch controller

LCD	Pico	Description
VCC	VSYS	Power input
GND	GND	GND
LCD_DC	GP8	Data/Command pin (High: data; Low: command)
LCD_CS	GP9	Chip select pin of LCD (Low active)
LCD_CLK	GP10	CLK pin of LCD communication, clock input for slave device
MOSI	GP11	SPI MOSI pin
MISO	GP12	SPI MISO pin
LCD_BL	GP13	LCD backlight control
LCD_RST	GP15	LCD reset pin (Low active)
TP_CS	GP16	Touch controller chip select (Low active)
TP_IRQ	GP17	Touch controller interrupt pin (Low active)

If i understand it correctly, it uses a shared SPI for both display and touch and has an interrupt pin. I am unsure if and how it is possible to configure the hardware_setup.py to work with the hardware.

Only using the display (e.g. with the nano_gui) was successful.

[peterhinch]

It is unfortunate that they use the same SPI bus. They claim that the display SPI can run at up to 60MHz while the XPT2046 is only rated to 2.5MHz. A bigger problem is that the GUI performs screen refreshes as a background task, so there would need to be arbitration, pausing refresh while the clock speed is changed and a touch sample grabbed. The software "hooks" are available to do this. I'll experiment in the next few days and report back.

[matthiasguertler]

Hey Peter, thank you for taking your time to experiment.

[peterhinch]

I've done a test where an asyncio lock is used to prevent refresh and touch sensing occuring concurrently. The only effect I could see was that very brief touches were occasionally missed. This could probably occur even without the lock and I don't think it's a practical problem.

I'm very keen to get those Waveshare boards working, and in fact I have the 2.8" version which I use as a reference board for nano-gui. This has the same interface. I'm now confident that it's a straightforward fix so I should be able to post a solution in a couple of days. From a user point of view it should be a matter of passing some extra optional args to the Display constructor.

[peterhinch]

I have pushed an update which works with my 2.8" Waveshare display. There is a slight loss in responsiveness but the outcome is quite usable.

[peterhinch]

Did you get a chance to try this with your 3.5" display?

[matthiasguertler]

Hi,

yes I had a little time, but the first try was not successful. After configuring the hardware setup file, i was able to test the small trial run with the diagonal and two rectangles, but running the setup.py for calibration was not successful. The display was empty with slightly dimmed brightness. I will retest it somewhen in the next couple of days.

[peterhinch]

Have you seen the setup example? Unless you've spotted something I've missed, your display pinout is identical to mine, but with a different display controller and resolution. The touch controller is the same. Given that the display trial worked, that part of your hardware_setup.py is correct.

If adapting my example you'll need to delete the tpad.init line before running touch.setup.py. The low initial SPI baudrate is essential.

If you're still having trouble you might want to post your hardware_setup.py and I'll check it out.

[beetlegigg]

I had a go with my waveshare 3.5 pico screen last evening but the touch did not work. However tweaking my hardware setup in light of your linked example just now its working well. I show my hardware_setup.py for this screen in case it helps @matthiasguertler

# ili9341_pico.py Customise for your hardware config

# Released under the MIT License (MIT). See LICENSE.
# Copyright (c) 2021-2024 Peter Hinch

# As written, supports:
# ili9341 240x320 displays on Pi Pico.
# TSC2007 touch controller.
# Edit the driver import for other displays.

# Demo of initialisation procedure designed to minimise risk of memory fail
# when instantiating the frame buffer. The aim is to do this as early as
# possible before importing other modules.

# WIRING for rpi picoW
"""
# Using waveshare LCD 3.5 
# LCD       picoW (GPIO)  
# VCC       Vin
# GND       Gnd
# LCD_DC    8
# LCD_CS    9
# LCD_CLK   10
# MOSI      11
# MISO      12
# BackLight 13
# LCD_RST   15
# (Touch)
# TP_CS     16 (using GP 0 for Touch)
# TP_IRQ    17

# (GPIO used for SD card)
# 5     SDIO_CLK
# 18    SDIO_CMD
# 19    SDIO_DO
# 20    SDIO_D1
# 21    SDIO_D2
# 22    SDIO CS/D3

"""

from machine import Pin, SPI, freq
import gc
from drivers.ili94xx.ili9486 import ILI9486 as SSD
SSD.COLOR_INVERT = 0xFFFF  # Fix color inversion

# RP2 overclock
freq(250_000_000)

# Screen configuration _______________________________
# (Create and export an SSD instance)
# Arbitrary pins
prst = Pin(15, Pin.OUT, value=1)
pdc = Pin(8, Pin.OUT, value=0)  
pcs = Pin(9, Pin.OUT, value=1)

# Use hardSPI (bus 1)
spi = SPI(1, sck=Pin(10), mosi=Pin(11), miso=Pin(12))
# Precaution before instantiating framebuf
gc.collect()
ssd = SSD(spi, height=320, width=480, dc=pdc, cs=pcs, rst=prst, usd=True) 
from gui.core.tgui import Display

# Touch configuration ________________________________
from touch.xpt2046 import XPT2046
tpad = XPT2046(spi, Pin(0), ssd, alen=10, variance=500, verbose = True)
tpad.init(320, 480, 202, 206, 3898, 3999, True, False, True)

# instantiate a Display instance
# Bus arbitration: pass (spi, display baud, touch baud)
display = Display(ssd, tpad, (spi, 33_000_000, 2_500_000))

I expect the touch mp-touch will work ok without freezing this module, but as previously I was running a nano-gui on this screen with mqtt-as and I had to freeze these modules into a mp build, I did the same this time but freezing mp-touch and mqtt-as.

I forgot that, a year back, you did not recommend freezing the screen driver (just the gui and widget dir's) and froze the blooming lot. However, thus far, its all working just fine.

Your Demo's work as expected and also the mp-touch with mqtt-as example you showed yesterday for the ili9341 screen also worked OK for this larger screen. (albeit that the font size used for the demos means that, on this larger screen, the rendered widgets are too small for fat finger presses, but with a stylus all works well :-)

[peterhinch]

Thanks very much for that.

Re freezing drivers I suspect that the recommendation against this is out of date. This is a question I've pondered for a while. Perhaps early in the development of nano-gui, on some platform, Viper code did not freeze properly? The problem with withdrawing the recommendation would be in testing: testing every single display driver as frozen bytecode is a daunting thought. Perhaps I'll change the wording.

Re the demos these were ported from micro-gui where many of them were designed to run on small displays. Touch displays seem to start at 240x240 so I was planning to scale up the simpler demos to be more touch friendly.

[EDIT] I recommend setting the baudrate of the SPI to 2.5MHz, the reason being that the touch utilities don't perform bus arbitration. Their display update might be very slow on such a large display at 1MHz.

spi = SPI(1, 2_500_000, sck=Pin(10), mosi=Pin(11), miso=Pin(12))

I also think the XPT2046 initialisation should read

tpad = XPT2046(spi, Pin(16), ssd, alen=10, variance=500, verbose = True)

because the CS\ line is on GPIO16

[peterhinch]

I now have one of these and it works fine. I pushed this example setup which worked even without calibration. With thanks to @beetlegigg (credited in code comments).

As a general point it's a large display with a big buffer (nearly 80K). I don't think a Pico W could hack it without frozen bytecode. The Pico runs even the more complex demos with nothing frozen. I also tried it with everything frozen including drivers. This also works.

@matthiasguertler I'll close this as solved, but if you have any problems you could raise a general query in discussions.

[EDIT] My comment about Pico W is incorrect. I have run an mqtt_as demo on the Pico W with this 3.5" display: the demo shows received messages and also allows the user to publish via on-screen pushbuttons. All without frozen bytecode. I'm astonished.

[matthiasguertler]

Thank you @peterhinch. Will try it out once I have more time again :) Maybe on sunday.

-----Original-Nachricht----- Betreff: Re: [peterhinch/micropython-touch] Pico-Res-Touch-LCD 3.5 (Shared SPI) compatibility (Issue #2) Datum: 2024-04-10T18:06:08+0200 Von: "Peter Hinch" @.> An: "peterhinch/micropython-touch" @.>

I now have one of these and it works fine. I pushed this example setup https://github.com/peterhinch/micropython-touch/blob/master/setup_examples/ili9488_ws_pico_res_touch_pico.py which worked even without calibration. With thanks to @beetlegigg https://github.com/beetlegigg (credited in code comments). As a general point it's a large display with a big buffer (nearly 80K). I don't think a Pico W could hack it without frozen bytecode. The Pico runs even the more complex demos. I've also tried it with everything frozen including drivers. This also works. @matthiasguertler https://github.com/matthiasguertler I'll close this as solved, but if you have any problems you could raise a general query in discussions. — Reply to this email directly, view it on GitHub https://github.com/peterhinch/micropython-touch/issues/2#issuecomment-2047939633 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDMVRX4SGXY5SLJN2EXLY3Y4VPOPAVCNFSM6AAAAABFPUNG32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXHEZTSNRTGM . You are receiving this because you were mentioned.Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/peterhinch/micropython-touch/issues/2#issuecomment-2047939633", "url": "https://github.com/peterhinch/micropython-touch/issues/2#issuecomment-2047939633", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]