TFT displays and interrupts

Status
Not open for further replies.

KrisKasprzak

Well-known member
All,

I'm using some 2.8" TFT displays with my Teensy 3.2 and can get them working with touch, buttons, SD,etc. However I have several places that i want to be able to push a button on the screen (to trigger some event) but can only seem to trap a screen button push with a polling function--which means such function must be placed like everwhere in my code, yuck.

I was hoping to use the displays IRQ pin conneted to an interrupt pin on my teensy (say pin 4) to trigger an interrupt function. That way no matter where the code is, user can always push a button on the screen for some action to happen.

My display
https://www.amazon.com/Wrisky-240x3...qid=1510373771&sr=8-10&keywords=240+x+320+tft


I've tried everything, maybe the IRQ pin on the display is not for such purpose? I tried using the displays MISO pin to trigger an interrupt--still no luck.

Code:
void setup() {
... all the code to get display working ommitted, but what I have works fine
attachInterrupt(4, ISR_DoSomething, RISING);

}

void ISR_DoSomething(){

if (Touch.dataAvailable()) {
Serial.println("Screen Pushed");
}
 
That's Arduino-style. It does not use interrupts for user-interactions - take a look at Serialx or other devices for example. Arduino uses available() - or "events" which are more or less the same as calling available().
Using the interrupt is not easy, because the position needs to be read with SPI - Which may be used for other devices too, and for the display itself. So it would have to wait for other transactions to complete anyway. Polling is a good solution in this case.

But I don't know how the touch works.. ;-) I think it has to request the position from the chip (and perhaps often to calc an average) via SPI, which can interfere with other SPI transactions - I've never looked into the details. Maybe it is doable somehow, or a way is already existent. Did you take a look at the sourcecode?

This is often better than guessing and trying things.. ;)
 
Last edited:
I did a bit more digging and found the touch chips datasheet. Looks like IRQ pin is an output for the purpose I need--it's to trigger when a pen presses the display. Only issue is the output is not logic level. Polling in loop() with Serial.println(analogRead(A5)); shows 112 bits when screen is not pressed, but 15 when pressed. Unfortunately this low voltage change is outside what an interrupt can read. I'm guess I'm back to putting CheckForButtonPress() in like 20 places in my code....
 
Is this using the 2.8" TFT display the PJRC store carries? ...\hardware\teensy\avr\libraries\XPT2046_Touchscreen\XPT2046_Touchscreen.cpp

From your description of what you found it seems not since the interrupt pin signal from that device is perfectly usable.

I hooked up the interrupt from that display to allow the display to avoid SPI polling the display until a touch was registered - so it is used internally by the library - when the interrupt pin is specified in the constructor for the display.

If you find that driver code on github in the PJRC repository the README notes that the interrupt fires on any data exchange command - likely just the ones to the touch controller. So it seemed not easy to have the enabled interrupt notify of a touch then proceed to read the position data from the device because that would lead to recurring interrupts … it did work easily in about 20 lines in the end ... though I did waste some time trying to deal with the recursive calls in a sample sketch before moving it into the library for a better solution.

Coding would perhaps be easy to take a *function() to callback when the touch interrupt arrived - though that would be during an interrupt so not a good place to do much.

If using that XPT2046 device there might be some good way to help ...
 
The PJRC display uses the TFT ILI9341 - not sure about utouch driver being to the same controller as the one noted above … but perhaps it is.

In any case if the INT fires on touch - hooking it up with attachinterrupt would be the best way to really test it - as long as the pin isn't turned over to the driver.

If you look at the XPT2046 source you can see how to do that
 
Status
Not open for further replies.
Back
Top