Touch GUI

[peterhinch]

I have ported micropython-gui to touch displays: micropython-touch. Current support is for resistive touch overlays with XPT2046 or TSC2007 touch controllers, however adding further touch controllers should be straightforward. Below is an ILI9341 display with XPT2046 from eBay with a Pi Pico.

Note that Chinese displays like that above sometimes have poor touch overlays. It's worth paying more from products from a reputable manufacturer such as Adafruit.

[beetlegigg]

Ooo Very nice. I have some ili9341 screens that appears to have touch screen abilities and comes with a plastic pen. I hope they have the right touch driver chip. I'll be giving it a go soon.

If that picture of an ili9341 screen with a pico on a PCB was from you own PCB design do you have the gerbers? If not I will have a go with KiCad if I can remember how to do it. My last attempt with KiCad worked OK but was a bit inelegant, and it was actually for a pico with a wemos D1 Esp 8266 to run your old mqtt-as bridge package. :-)

[peterhinch]

Most of the Chinese ILI9341 screens have an XPT2046. The "docs" on eBay don't disclose this information. A good magnifying glass is recommended.

I use Fritzing/Aisler for PCB's with their own CAD software. It claims to be able to output gerbers but I've not used that capability. The picture is not entirely kosher as the PCB was for micro-gui and needed wire links for the XPT2046 interface. I did most of the development using a different PCB with an Adafruit display and TSC2007.

[peterhinch]

To anyone using this I recommend grabbing an update. There are some bugfixes, notably an improvement to touch accuracy. Calibration is now more deterministic and more accurate.

[JL1306]

Testing and getting my head around this, using ILI9341 with xpt2046 touch controller.
Have most of it working, including touch.
Having issue with screen orientation with some of the older examples.
Using various.py examples, have modified line 10 to import display and touch. Orientation is in Landscape mode but touch coordinates start at bottom right.
How and where to declare orientation so that touch reading coordinates are correct?

[peterhinch]

The procedure (which is documented here) is as follows.

First ensure your screen orientation is as you want it.

Initially create hardware_setup.py with no tpad.init line. Run touch.setup and follow the on-screen instructions, touching each cross as it appears, as accurately as possible. The output at the REPL will be a tpad.init line. Copy paste that into hardware_setup.py, reboot and the orientation of touch should match that of the screen.

If the doc is unclear, please advise and I will correct it.

I'm not sure what you mean by older examples: touch and screen orientation are defined in hardware_setup.py. The examples simply use the setup as defined.

[JL1306]

Unfortunately, this has extremely slow response time.
Could be very useful and valuable if written in C and included in firmware.

[JL1306]

esp32

[JL1306]

will try with pico.

[JL1306]

I was also sharing same spi bus for display and touch on esp32.
Not sure how asyncio was handling above?

[beetlegigg]

I followed the example setup for the ili9341 and xpt2046 where the ili9341 used the hard SPI bus and the Touch uses SoftSPI.

[peterhinch]

It is possible to share the bus, but the screen requires a much faster bus than can be tolerated by the touch controller. This requires a tweak to hardware_setup.py documented here. See also this setup example and this one.

If this is not done correctly, with the bus running at a fixed 2.5MHz, it will work but be excruciatingly slow.

[peterhinch]

I have modified the setup examples to comment out the tpad.init line and to point users to SETUP.md. It is necessary to calibrate the touch panel to ensure that its orientation matches that chosen for the display.

[JL1306]

Thanks Peter for clarifying. It makes much more sense. Particularly, initial setup calibration and the way spi busses operate.
Another question or possible suggestion. xpt2046 touch controller on ili9341 has a hardware interrupt option/pin available.
Could a worth while improvement be achieved by using touch hardware irq instead of polling?

Have you done testing with other than pico microcontrollers, esp32 and original pyboard?

[peterhinch]

Could a worth while improvement be achieved by using touch hardware irq instead of polling?

This rather depends on what problem you wish to solve. Very brief touches can be missed, an IRQ could solve that. However overall responsiveness is constrained by the need to refresh the screen over SPI. Touch screens tend to have a lot of pixels, so a complete refresh is not visually instantaneous. This latter problem can't be fixed. In my view the problem of very brief touches being missed is best addressed by interface design (touches can also be missed by inaccurate positioning). Controls should provide a visual confirmation of touch, either by their effect on other visible elements or directly (see Button.litcolor). My conclusion was that using the IRQ to trigger an interrupt is unlikely to offer any real gain in usability. I think its principal application is in games, with a fast parallel-connected display.

Have you done testing with other than pico microcontrollers, esp32 and original pyboard?

I have not yet done this. However micro-gui has been tested on a variety of hosts and the GUI core and widgets are little changed. It is written in standard Python~. I would be surprised to see a platform-specific issue apart from the perennial one of RAM: this isn't going to run on an ESP8266.

~ Except for some Viper code in certain display drivers which have run on multiple platforms. Display drivers are common to all three GUI variants.

[JL1306]

I have it now working well on esp32.
Response is very good, with most examples.
Thank You Peter.

For some reason, have not been able to get touch working on Hardware SPI 1 bus, spi = SPI(1, mosi=Pin(13), miso=Pin(12), sck=Pin(14), baudrate=1_000_000) ?

But softSPI works OK. spi = SoftSPI(mosi=Pin(13), miso=Pin(12), sck=Pin(14), baudrate=1_000_000)

[peterhinch]

Thanks for confirming ESP32. I have today tested ESP32S3 with SPIRAM which also works. I used a shared SPI bus with rate switching to check that ESP32 could handle this.

For some reason, have not been able to get touch working on Hardware SPI 1...

That's hard to explain. SoftSPI working on the same pins proves the wiring and the touch panel. Which seems to leave the host (?). It might be worth trying another ESP32.

In practical terms SoftSPI is fine for the touch controller.