General touch event processing

[tfischer4765]

I have an XPT2046 touchscreen driver. To control the display backlight, I have to react to all screen touches, no matter where. I've already found out that attaching an interrupt routine to the driver's native interrupt pin breaks the touch handling of the gui. Is there a way to set up a callback that will be triggered by any touch event, wether or not it lands on any gui element? Alternatively, is there a way I can hand down the touch events I received to GUIslice so I can keep my custom interrupt handler in place?

Update: Funny thing is, I can't find anything in the code that suggests GUIslice even grabs the interrupt pin of the XPT2046. As far as I can tell, GUIslice relies on polling to collect touch events. I really don't know what's keeping the touch driver from functioning normally if a touch event triggers a very short interrupt routine.

[Pconti31]

@tfischer4765 Yes, GUIslice only does polling. It does have support for adding your own touch driver though.
In fact the example uses the XPT2046 chip just not interrupts. The example to follow is in GUIslice/examples/arduino ex16_ard_touch_hnd.ino it also uses GUIslice/src/ GUIslice_th_XPT2046.(h c) which you may need to modify or create your own version. I have created my own versions for other chips in the past and its not hard to do.
Paul--

[tfischer4765]

If GUIslice only polls, that begs the question: Why does installing an ISR that reacts to the XPT2046's hardware interrupt make GUIslice not "see" the touches? The ISR is very simple:

void IRAM_ATTR touchInterrupt()
{
  eventOccured("Touch");
}

void eventOccured(char *reason)
{
  _lastEvent = millis();
}

void setup()
{
  eventOccured("Startup");

  tftBacklightOn();
  attachInterrupt(digitalPinToInterrupt(TOUCH_IRQ), touchInterrupt, FALLING);
 
}

This is literally all there is to it. Basically some simple code elsewhere checks for the time since the last event and dims and eventually turns off the lcd backlight. I see nothing in there that should prevent GUIslice from polling its touch events.

[Pconti31]

@tfischer4765 I'm not sure you have really examined the code base since in only quick 5 minutes I found a possible solution. Keep in mind I'm just a user like you not the author of this code base so I'll admit I can be wrong...

Also, you haven't really supplied much information to go on, no idea what mcu, guislice config file or the actual touch driver software you are using so this is just a guess. I suspect guislice is setting up the the touch driver as spi no irq so your touch driver is going to ignore your isr. Basically, you need a constructor something like:

#define TIRQ_PIN  2
XPT2046_Touchscreen ts(CS_PIN, TIRQ_PIN);

A quick scan of the guislice ard-adagfx-ili9341-xpt2046.h config file shows that my initial post might be wrong. Its quite possible that guislcie will use a irq pin if told to do so.

say you are using PaulStoffregen/XPT2046_Touchscreen Inside this config file on line 122 we see:

  #define XPT2046_IRQ    255 // IRQ pin or 255 if no IRQ used

which would disable the irq. Furthermore. inside GUIslice_drv_adagfx.cpp we see starting on line 528

#elif defined(DRV_TOUCH_XPT2046_PS)
  const char* m_acDrvTouch = "XPT2046_PS(SPI-HW)";
  #if defined(XPT2046_IRQ)
    // Use SPI, with IRQs
    XPT2046_Touchscreen m_touch(XPT2046_CS, XPT2046_IRQ); // Chip Select pin, IRQ pin
  #else
    // Use SPI, no IRQs
    XPT2046_Touchscreen m_touch(XPT2046_CS); // Chip Select pin
  #endif  
  #define DRV_TOUCH_INSTANCE

Paul--

[Pconti31]

@tfischer4765 One last point, you shouldn't need to write a ISR, the touch driver should be handling that for you
unless you have written the touch driver yourself... In which case you should just ignore everything I said previous post and really take a long hard look at example 16 since that is the only way to invoke a custom driver constructor.
Paul--

[tfischer4765]

@Pconti31 I had actually disected the codebase to some extent before and continued to do so after I wrote the initial question. That's how I knew about the polling loop.

But what you wrote makes a lot of sense, I had plainly overlooked (or forgotten) that IRQ functionality of the PaulStoffregen driver. Unfortunately, my hopes of my (convenient) ISR and the driver's touch processing coexisting were crushed. Neither removing that config option nor setting it to 255, as the comment seems to suggest, makes any difference whatsoever. As soon as I install my own ISR, the touch processing of GUIslice conks out.

By the way, I agree with you that I shouldn't be needing to use an ISR. The way I did it was just a convenient shortcut because in my previous, very primitive handmade GUI, I really didn't care where the touch had landed.

What I should be able to do instead is registering a callback that triggers whenever a touch lands. That can probably be done by a custom driver, as you suggest. I do feel however that it is properly the responsibility of the GUIslice core event handler, not the driver, to provide such functionality.

Oh, and I have example 16 open in another tab as we speak. I've got a few more things I can try, not the least being switching to TFT_eSPI, writing a custom wrapper to the PaulStoffregen driver or just plain layering transparent buttons over everything and handling the backlight processing that way.

[Pconti31]

@tfischer4765 Ah! I really must be getting too old. I should have read your first post closer.
Seems you want to control turning your backlight back on by detecting a touch event.
If so, I have a solution for you. I put together a bunch of demos I wrote for various people and purposes over the years and placed them inside my GUIslice-Solutions repository. In particular, my screen saver might be what you are looking for. The sample displays a Matrix Rain when the activity is timed out and any touch event will cause the return to the app. Of course, in your case you simply turn the back light on/off. No need for the matrix rain screen saver.
All of the logic is contained inside ScreenManager c++ object and the touch is handled by my gslc_touchAny routine.
Maybe it will help you out.
screen saver

[tfischer4765]

@Pconti31 That touch_any thing looks promising. I'll need a few days to parse that code, I'll be back...

In the meantime, I've tried overlaying buttons over any unused space to do the general touch processing, but the lag is just too bad.

[Pconti31]

@tfischer4765 I would suggest you try the demo first then modify it to turn off/on your backlight. You will likely need to comment out lines 92-94 inside the ScreenManager.cpp where it blanks the screen since only a screen saver would need that,
Paul--

[tfischer4765]

Thanks for the offer, but I'll more likely dissect your code and try to recreate some concepts. My application is a multicored, multithreaded network client with a complex state machine and GUI, and far too complicated to copy-paste much from a run-off-the-mill arduino sketch.

[tfischer4765]

@Pconti31 I've given you access to the repository so you can have a sniff around on your own ;-)