ESP32-XPT2046 Interrupt

[Bwanna]

I have a similar question as tfischer4765 in posting: https://github.com/ImpulseAdventure/GUIslice/discussions/505
Started a separate posting to not hijack that one.

I've been successful using the ESP23 and PaulStoffregen XPT2046_Touchscreen driver. Both the TouchTest and TouchTestIRQ sketches work successfully.
Also, Ive been successful with GUISLICE using the ESP32, TFT_eSPI, and XPT2046_PS driver. HOWEVER, the Touch response is painfully slow as it waits for polling.

I'd like to have the XPT2046_PS IRQ initiate a GUISlice response upon a touch event without waiting for polling. Is this possible using the XPT2046_PS library?

r/
Steve

[Pconti31]

@Bwanna Well, first off as I have pointed out before being retired I don't have the income to have a large number of MCU's and TFT's so I can't test this out. Looking at the code base it seems to me you should be able to simply edit your esp-tftespi-default-xpt2046.h config file on line 131 and change

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

removing 255 and replacing it with what ever pin number you have wired to the interrupt.
This should cause GUIslice to use this constructor to XPT2046_PS inside GUIslice_drv_tft_espi.cpp

#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

Will this speed touch up or even work? Sorry, I have no idea.

Paul--

[Bwanna]

Paul,
Very much appreciate the feedback!

As mentioned, I was able to get the PS library successfully working with an IRQ setting. The PS example sketch responds correctly and indicates proper action.

I guess my question is more about trying to link the output of the XPT2046_PS IRQ action to the GUIslice touch response. This is where I'm unskilled in figuring it out.

Some things I'm observing and wondering if this is where I can try to focus?

1. the XPT2046_PS library includes an ISR action resulting from the IRQ pin going negative. I'm not sure how to tap into this ISR so that it links to the GUIslice code and triggers an immediate response... rather than waiting for polling.
2. The GUIslice libraries are a bit more difficult for me to decipher. THis is where I'm stuck. Is there a way to utilize the ISR from the PS library to initiate a touchhandler response in GUISlice.

Or... am I seeing this completely wrong and there's another direction I should investigate.

Thanks and all suggestions are very much welcomed!
Steve

[Pconti31]

@Bwanna Again, I can't test this but I would start by set #define XPT2046_IRQ to your pin inside your esp-tftespi-default-xpt2046.h config then replacing the code inside GUIslice_drv_tft_espi.cpp between the #elif defined(DRV_TOUCH_XPT2046_PS)
and #elif defined(DRV_TOUCH_HANDLER) starting around lines 1939 to 1973??? with
something like this code and be prepared to do some debugging. By the way the brackets might not be balanced.

  #elif defined(DRV_TOUCH_XPT2046_PS)
    uint16_t  nRawX,nRawY; //XPT2046 returns values up to 4095
    uint16_t  nRawPress;   //XPT2046 returns values up to 4095

  // tirqTouched() is much faster than touched().  For projects where other SPI chips
  // or other time sensitive tasks are added to loop(), using tirqTouched() can greatly
  // reduce the delay added to loop() when the screen has not been touched.
  if (m_touch.tirqTouched()) {
    if (m_touch.touched()) {
      TS_Point p = m_touch.getPoint();
      if ((p.z > pGui->nTouchCalPressMin) && (p.z < pGui->nTouchCalPressMax)) {
        // PaulStoffregen/XPT2046 appears to use a different orientation
        // than other libraries. Therefore, we will remap it here
        // to match the default portrait orientation.
        nRawX = 4095-p.y;
        nRawY = p.x;

        nRawPress = p.z;
        m_nLastRawX = nRawX;
        m_nLastRawY = nRawY;
        m_nLastRawPress = nRawPress;
        m_bLastTouched = true;
        bValid = true;
      }
      else {
        if (!m_bLastTouched) {
          // Wasn't touched before; do nothing
        }
        else {
          // Touch release
          // Indicate old coordinate but with pressure=0
          m_nLastRawPress = 0;
          m_bLastTouched = false;
          bValid = true;
        }
      }
    }
  }
  // ----------------------------------------------------------------
  #elif defined(DRV_TOUCH_HANDLER)

Paul--

[Bwanna]

Thank You for this suggestion! I'll try it and will post what I discover.

[Bwanna]

Tried the recommended code as is. It compiled without errors. The results unfortunately aren't good. The touch doesn't respond at all. Haven't had a chance to walk through it in detail and will look at that tomorrow.

Thoughts: Process wise, what is the best way to integrate a TS IRQ to immediately cause a touch response while not violating an ISR timelimit?

1. TS IRQ occurs
   1.a. Triggers and ISR? (The one created in the PS Library?)
2. ISR Action?
   2.a. Since ISRs need to be very short, what would be the action within the ISR that would then:
   -cause the appropriate touch event (popup, etc.) (without violating the ISR timelimit)
   -return to normal Main Loop operations

[Pconti31]

@Bwanna I assume you have his example TouchTestIRQ.ino running correctly, if not start there.

For GUIslice, As I stated above first you need this constructor for XT2026_PS to be run where XPT2046_IRQ is set to the correct pin.

XPT2046_Touchscreen m_touch(XPT2046_CS, XPT2046_IRQ); // Chip Select pin, IRQ pin

After which XT2026_PS's internal IRQ will set a flag to true for his routine tirqTouched(). once this routine returns true
touched() and getPoint() should work.

If his sample TouchTestIRQ.ino works and if GUIslice doesn't add GSLC_DEBUG_PRINT() statements to GUIslice_drv_tft_espi.cpp ; starting with the constructor and so forth.

I'm afraid that's all the help I can give without hardware to test...

Paul--

[Pconti31]

@Bwanna One thing I think you are still confused about is what the ISR does. It doesn't avoid polling! It simply makes it faster.
The ISR inside XT2046_PS sets a flag named isrWake a boolean to true. tirqTouched() simply returns isrWake as you should see inside XPT2046_Touchscreen.cpp

What makes it all faster is the if you were to call getPoint() without testing this flag it would call XPT2046_Touchscreen::update() which does a lot of processing to only find out no one touched the screen.

I hope that clears things up for you...
Paul--

[Bwanna]

Thank you Pconti for the information. Very Helpful!

I've only worked a little with ISRs and probably don't understand it as well. Yes, I see how the isrWake flag is set to true when a touch occurs, but still confused about the subsequent actions that occur in the processing of the code as a result of this flag being set.

Walking through it...
-Touch action occurs

• isrWake is set to true
• (then what?)
• ...
• ...
• goal: GUISlice responds to touch event (i.e. Popup screen)

How does this all happen without continuing through the rest of the polling and delaying the response to the touch?

[Pconti31]

@Bwanna
Walking through it...
Touch action occurs

1. isrWake is set to true
2. You modify your config new value for XPT2046_IRQ and edit GUIslice_drv_tft_espi.cpp adding if (m_touch.tirqTouched()) using example code I gave you above.
3. GUIslice polls for touches only when screen is actually touched instead of each time though loop().
4. Debug GUIslice using GSLC_DEBUG_PRINT() and maybe Serial.println() inside XPT2046_Touchscreen.cpp until either you fix or give up.

(then what?)

goal: GUISlice responds to touch event (i.e. Popup screen)
How does this all happen without continuing through the rest of the polling and delaying the response to the touch?
Not sure why you can't understand this but there is NO WAY TO AVOID POLLING. This has nothing to do with GUIslice. Even his example TouchTestIRQ.ino polls. It just faster when tests only occur when screen is touched not each cycle.

I'm sorry but asking me the same questions a different way each time is getting irritating. Please re-read all of my comments before posting again...

Paul--

[Bwanna]

@Pconti31
I am aware that IRQ (isr) does not 'avoid' polling. My question was about how the subsequent isrWake causes a GUISlice action (ie Popup) to occur without experiencing the delay from the normal polling.

Suggestion: If I send you the device I'm using, would you consider taking a look at it? I would be very thankful for any help you can provide. I have been reading/rereading yours and others comments, researching, etc. and am fully stuck. This appears to be beyond my knowledge and it is not my intention to cause frustration with questions.

Bwanna

Device: https://www.elecrow.com/esp32-display-2-4-inch-intelligent-spi-tft-lcd-touch-screen-hmi-display.html

[Pconti31]

@Bwanna I have in the past accepted donations of hardware and have debugged and fix the issues involved. But before you feel compelled to donate hardware I'll try one more time to explain why things can go much faster even though a popup doesn't occur instantly. Note its still quite possible that it won't go fast enough for you...

The normal flow without ISR:

1. GUIslice update() is entered.
   
2. update() calls our driver GUIslice_drv_tft_espi.cpp gslc_TDrvGetTouch()
3. this calls XPT2046_Touchscreen::getPoint() to poll
4. getPoint() calls XPT2046_Touchscreen::update()
5. update() makes many spi transfer commands even if screen isn't touch since it has no way to know. This is the main time sync.
6. GUIslice then goes through code to deal with touch that may not actually occurred (say maybe with a pressure of 0).

With ISR and my modified code inside GUIslice_drv_tft_espi.cpp testing isrWait you only call steps 4,5,6,7 if a touch was actually detected. This makes loop() go faster. Fast enough? I have no idea.

You also haven't told me if you got the demo app TouchTestIRQ.ino working. If that doesn't work you have no hope of getting GUIslice working with ISR.

Paul--

[Bwanna]

Paul,
The flow diagram is VERY helpful. Thank you!

I did a fresh start with everything to ensure all was configured correctly. Unfortunately, now I cannot get GUIslice to work at all with the XPT2046_PS designated. It works with the internal driver, but not with the PS driver.

Here's a summary:
1. TouchTestIRQ.ino (XPT2046_Touchscreen.h)

TouchTestIRQ.ino works BUT - ONLY if the HSPI pins are defined in the Sketch (not directly in the .h or .cpp files)
- The device is wired using the ESP32 HSPI pins (12, 13,14) and not the VSPI
- This library uses the default ESP32 SPI pins (VSPI)
- Don't know how to designate HSPI as the default ESP32 SPI
- potential Issue? How do I get this library to use the HSPI pins when called from GUIslice???
-
TouchTestIRQ.ino

#include <XPT2046_Touchscreen.h>
#include <SPI.h>

#define MISO 12   //ESP HSPI
#define MOSI 13   //ESP HSPI
#define SCK 14   //ESP HSPI
#define CS_PIN  33

// The TIRQ interrupt signal must be used for this example.
#define TIRQ_PIN 36
XPT2046_Touchscreen ts(CS_PIN, TIRQ_PIN);  // Param 2 - Touch IRQ Pin - interrupt enabled polling

void setup() {
  pinMode (SS, OUTPUT);
  Serial.begin(115200);
  SPI.begin(SCK, MISO, MOSI, CS_PIN );      //SPI Initation with HSPI pins
  ts.begin();
  ts.setRotation(1);
  while (!Serial && (millis() <= 1000));
}

void loop() {
  // tirqTouched() is much faster than touched().  For projects where other SPI chips
  // or other time sensitive tasks are added to loop(), using tirqTouched() can greatly
  // reduce the delay added to loop() when the screen has not been touched.
  if (ts.tirqTouched()) {
    if (ts.touched()) {
      TS_Point p = ts.getPoint();
      Serial.print("Pressure = ");
      Serial.print(p.z);
      Serial.print(", x = ");
      Serial.print(p.x);
      Serial.print(", y = ");
      Serial.print(p.y);
      delay(30);
      Serial.println();
    }
  }
}

2. TFT_eSPI

Test_Touch_Controller.ino
- Must also define the HSPI in the TFT_eSPI sketches to make them work with this device.

// This sketch is to test the touch controller, nothing is displayed
// on the TFT.  The TFT_eSPI library must be configured to suit your
// pins used. Make sure both the touch chip select and the TFT chip
// select are correctly defined to avoid SPI bus contention.

// Make sure you have defined a pin for the touch controller chip
// select line in the user setup file or you will see "no member"
// compile errors for the touch functions!

// It is a support and diagnostic sketch for the TFT_eSPI library:
// https://github.com/Bodmer/TFT_eSPI

// The "raw" (unprocessed) touch sensor outputs are sent to the
// serial port. Touching the screen should show changes to the x, y
// and z values. x and y are raw ADC readings, not pixel coordinates.

#include <SPI.h>

//SPI Management - using HSPI
#define MISO 12
#define MOSI 13
#define SCK 14
#define CS_PIN 33

#include <TFT_eSPI.h>
TFT_eSPI tft = TFT_eSPI();

//====================================================================
void setup(void) {
  Serial.begin(115200);  
  SPI.begin(SCK, MISO, MOSI, CS_PIN);  
  Serial.println("\n\nStarting...");
  tft.init();
  // Use this calibration code in setup():
  uint16_t calData[5] = { 428, 1969, 879, 2535, 3 };
  tft.setTouch(calData);
}
//====================================================================
void loop() {
  uint16_t x, y;
  tft.getTouchRaw(&x, &y);  
  Serial.printf("x: %i     ", x);
  Serial.printf("y: %i     ", y);
  Serial.printf("z: %i \n", tft.getTouchRawZ());
  delay(250);
}
//====================================================================

3. GUISlice

no response to touch actions with XPT2046
- Including HSPI pins and setup code in the GUIslice test sketches does NOT work.
- Haven't figure out how to define HSPI pins for callout to "XPT2046_Touchscreen.h"

Idea: Is there a way to designate ESP32 to boot with HSPI as the default "SPI" using SPIClass SPI2(HSPI); or something similar? The thought is to make the changes to the ESP32 bootup so that it's consistent throughout and doesn't have to be defined in the sketch itself. (Just an idea and not even sure if I'm on the right track)

[Pconti31]

@Bwanna I would take the quick and dirty approach and edit XPT2046_Touchscreen::begin(SPIClass &wspi)
changing:

//	_pspi->begin();
	_pspi->begin(14,12,13,33);

then run TouchTestIRQ.ino with your SPI.begin commented out to see it works. Then retry GUIslice...

Paul--

[Bwanna]

@Pconti31
The TouchTestIRQ.ino runs correctly with the change to _pspi.

The GUIslice still doesn't work at all.

If it matters, the GUISlice #include "../configs/esp-tftespi-default-xpt2046_int.h" does work... however, that driver doesn't have an IRQ option.

[Pconti31]

@Bwanna Post a zip file of your esp-tftespi-default-xpt2046.h config and your modified GUIslice_drv_tft_espi.cpp and GUIslice_drv_tft_espi.h files and I'll take a look.

[Bwanna]

Here they are:

GUIslice_files.zip

[Pconti31]

@Bwanna I don't see anything out of order with these files. This only leaves you needing to add debug print statements to trace what is going on...

Paul--

[Pconti31]

@Bwanna One other thing I just thought of. Post a zip of your TFT_eSPI User_Setup.h, User_Setup_Select.h, and GUIslice/src GUIslice_config.h

If I can't find anything with these files I'm afraid I'm at the limit of help I can offer without hardware...

Paul--

[Bwanna]

Here you go
TFT-GUI files.zip

[Bwanna]

The offer is still there is you want to try with the hardware...

[Pconti31]

@Bwanna
Changes you need:
GUIslice_config.h

  #include "../configs/esp-tftespi-default-xpt2046.h"
//  #include "../configs/esp-tftespi-default-xpt2046_int.h"

User_Setup.h line 212

// #define TOUCH_CS 33  // Chip select pin (T_CS) of touch screen

Paul--

[Bwanna]

Probably should have mentioned, until this can be figured out I switched to the internal XPT2046 driver. All of the testing was done with it set as you indicate.

[Pconti31]

Hopefully, tracing will help you out... However, If all else fails you can donate hardware. It a good deal for me. I add to my hardware collection and hopefully help you out. I can't promise success though. Woops! Looks like I screwed up and gave my home address in the clear!!! If it came through to you no problem but if no send an email not using github to my open email address p_conti@hotmail.com and I'll send you my address...

…

________________________________ From: Bwanna ***@***.***> Sent: Thursday, August 10, 2023 1:17 PM To: ImpulseAdventure/GUIslice ***@***.***> Cc: Paul Conti ***@***.***>; Mention ***@***.***> Subject: Re: [ImpulseAdventure/GUIslice] ESP32-XPT2046 Interrupt (Discussion #518) The offer is still there is you want to try with the hardware... — Reply to this email directly, view it on GitHub<#518 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKQIQYWETDEGZGGBLWMLTHLXUUJRLANCNFSM6AAAAAA3EYS2QM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Bwanna]

Paul, I just appreciate the help in figuring this out or at least determining what's the issue. How you enjoy. It's a cool setup. Amazon says you should get to you tomorrow. Cheers, Steve

…

On Fri, Aug 11, 2023, 2:18 PM Paul Conti ***@***.***> wrote: Hopefully, tracing will help you out... However, If all else fails you can donate hardware. It a good deal for me. I add to my hardware collection and hopefully help you out. I can't promise success though. Anyway, My address is: Paul Conti 21 Maurice Street Haverhill, MA 01832-2540 USA ________________________________ From: Bwanna ***@***.***> Sent: Thursday, August 10, 2023 1:17 PM To: ImpulseAdventure/GUIslice ***@***.***> Cc: Paul Conti ***@***.***>; Mention ***@***.***> Subject: Re: [ImpulseAdventure/GUIslice] ESP32-XPT2046 Interrupt (Discussion #518) The offer is still there is you want to try with the hardware... — Reply to this email directly, view it on GitHub< #518 (reply in thread)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AKQIQYWETDEGZGGBLWMLTHLXUUJRLANCNFSM6AAAAAA3EYS2QM>. You are receiving this because you were mentioned.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGA5YH3S3FPR2GRDDTEYFUTXUZZOZANCNFSM6AAAAAA3EYS2QM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[Pconti31]

@Bwanna I have received the board and it runs the demo preloaded. I also can see the port (com5) on my windows 11. But no docs so I'm unclear of setting up with Arduino IDE. What esp32 board (chip) have you selected and what memory configs? Is there a wiki for this version? A link to the amazon page you ordered from?

Paul--

[Pconti31]

@Bwanna Never mind, I think I found the wiki page. I'll let you my progress. It may take a few days...
Paul--

[Bwanna]

The elecrow website has everything too. For programming, it says to select esp32-wroom-da for the board. For memory I selected NO-OTA. 2mb APP/2md SPIFFS

[Pconti31]

@Bwanna I can't seem to get upload to work from the Arduino IDE. Serial Monitor works printing out debug statements from the program that came pre-loaded using 9600 baud but I can seem to replace it. Pressing boot and then reset just restarts the pre-loaded app. and upload fails. Am I missing a trick here?

[Bwanna]

Manual reset is needed.

1. Press hold Boot
2. Press release Reset

That puts it into download mode

[Pconti31]

@Bwanna
here is my Arduino IDE config

[Pconti31]

@Bwanna Once again. never mind...
Dummy here figured out that I need to press boot and reset at the same time.
Paul--

[Pconti31]

@Bwanna Ok, first bit of progress, how to get XT2046_PS to use HSPI interface without coding changes to XPT2046_Touchscreen library.

#include <XPT2046_Touchscreen.h>
#include <SPI.h>

#define CS_PIN  33
// MOSI=11, MISO=12, SCK=13

// For ESP32, The fault SPI pins are for VSPI, here we need HSPI
SPIClass hspi(HSPI); 

// The TIRQ interrupt signal must be used for this example.
#define TIRQ_PIN  36
XPT2046_Touchscreen ts(CS_PIN, TIRQ_PIN);  // Param 2 - Touch IRQ Pin - interrupt enabled polling

void setup() {
  Serial.begin(115200);
  ts.begin(hspi);
  ts.setRotation(1);
  while (!Serial && (millis() <= 1000));
}

void loop() {

  // tirqTouched() is much faster than touched().  For projects where other SPI chips
  // or other time sensitive tasks are added to loop(), using tirqTouched() can greatly
  // reduce the delay added to loop() when the screen has not been touched.
  if (ts.tirqTouched()) {
    if (ts.touched()) {
      TS_Point p = ts.getPoint();
      Serial.print("Pressure = ");
      Serial.print(p.z);
      Serial.print(", x = ");
      Serial.print(p.x);
      Serial.print(", y = ");
      Serial.print(p.y);
      delay(30);
      Serial.println();
    }
  }
}

This works great. Tomorrow I'll modify GUIslice config to add

#define USE_SPICLASS_ESP32_HSPI

and go from there...
Paul--

Paul--

[Bwanna]

Yes, this works well. If I understand correctly, will the GUIslice added #define result in designating the HSPI as the default for the ESP32 instead of the VSPI?

[Pconti31]

@Bwanna I modified GUIslice to have the option to use HSPI. To turn that option on you simply add the #define I mentioned above.
I have also modified GUIslice_drv_tft_espi.cpp to check for this #define and create the SPIClass hspi(HSPI); which will then be used in the m_touch.began(hspi) later instead of the default m_touch.begin(). Now it a question of debugging....

Paul--

[Pconti31]

@Bwanna Ok, I have identified the problem. The touch is in fact working but we only get one event when using IRQ (which makes sense) but GUIslice is coded to detect a stream of touch events because that the way non-IRQ happens, Thus, without IRQ we detect:

  GSLC_TOUCH_DOWN            = GSLC_TOUCH_COORD  | ( 1<<0),    ///< Touch event (down)
  GSLC_TOUCH_DOWN_IN         = GSLC_TOUCH_COORD  | ( 2<<0),    ///< Touch event (down inside tracked element)
  GSLC_TOUCH_DOWN_OUT        = GSLC_TOUCH_COORD  | ( 3<<0),    ///< Touch event (down outside tracked element)
  GSLC_TOUCH_UP              = GSLC_TOUCH_COORD  | ( 4<<0),    ///< Touch event (up)
  GSLC_TOUCH_UP_IN           = GSLC_TOUCH_COORD  | ( 5<<0),    ///< Touch event (up inside tracked element)
  GSLC_TOUCH_UP_OUT          = GSLC_TOUCH_COORD  | ( 6<<0),    ///< Touch event (up outside tracked element)
  GSLC_TOUCH_MOVE            = GSLC_TOUCH_COORD  | ( 7<<0),    ///< Touch event (move)
  GSLC_TOUCH_MOVE_IN         = GSLC_TOUCH_COORD  | ( 8<<0),    ///< Touch event (move inside tracked element)
  GSLC_TOUCH_MOVE_OUT        = GSLC_TOUCH_COORD  | ( 9<<0),    ///< Touch event (move outside tracked element)

With IRQ, the first touch causes GSLC_TOUCH_DOWN and all other touches from that point on only GSLC_TOUCH_MOVE occurs, so a button is high-lighted (selected) but nothing fires for a callback because it's waiting for GSLC_TOUCH_UP_IN.

One quick and dirty fix would be to change the callback to check events for whatever we are getting back. Not sure what that is yet...
I need to give this more thought.

Paul---

[Bwanna]

Very interesting. Would it be useful to trigger an IRQ based on the Touch Up instead of Touch Down?

[Pconti31]

@Bwanna Maybe, I'm not really sure... My recent try was checking for the #define XPT2046_IRQ inside GUIslice.c but the touch code is spread out over quite a few places so my attempt failed. Basically, with my mods to GUIslice.c running the ex02_bld_btn_txt (the one with a single QUIT text button) I got the callback no matter where on screen I touch, even out side the button area. So that didn't work.

I sent email to Calvin for advice but I'm not sure of a response so I'll continue to dig through the code. This is most likely going to take a few days.

Paul--

[Bwanna]

No problem at all. I ran into similar trying to follow all the touch code throughout the processes.

[Pconti31]

@Bwanna Ok, I made some progress here. I think the basic flow is working but could use your help in testing. My version reports as
GUISLICE_VER "0.17.1.3A"

Now a rather big outstanding issue even if your testing goes smoothly is that you no longer have glow working. Your thoughts on that would be useful...

You can download my repository here:
ESP32-XPT2046-IRQ

Paul--

[Bwanna]

@Pconti31 Ran this with the arduino example 'calc' and had a weird response when touching a number... it fill the whole block with that number and did not just show one number per touch.
Btw, what do you mean that "no longer have glow working"?
Hope that helps

[Pconti31]

@Bwanna Ah, One more thing. I created a new config file you should use. No editing required on your part.
#include "../configs/esp-tftespi-elecrow-xpt2026-irq.h"
you can uncomment inside GUIslice_config.h

Paul--

[Pconti31]

@Bwanna Well, before I continue trying to debug any chance you could test the performance of touch. The whole point is whether or not its fast enough for what you are trying to do. If not, i can stop here otherwise I'll look into fixing calc.
Paul--

[Bwanna]

@Pconti31 Pardon, I did test it with my project code and it doesn't appear to be any faster in responding to a touch event. Still long delays that give the impression it's still polling. I can't confirm, but that's the behavior.

[Bwanna]

@Pconti31 Some additional information. I initially ran your GUISLICE_VER "0.17.1.3A on Arduino IDE, which compiled without issue. Since I'm in the process of learning Platformio, I created a new project using this same version and received a problem report in file "GUIslice_drv_tft_espi.cpp" for "too many arguments in function call" referring to line 1654 "hspi" being highlighted
m_touch.begin(hspi);

It also gave problem message for the same thing: "no matching function for call to 'XPT2046_Touchscreen::begin(SPIClass&)'"

It's interesting that the Arduino IDE didn't show this.

[Bwanna]

This seems to be fixed using "HSPI" instead of lowercase.

[Pconti31]

@Bwanna Well, if its the same performance than there is no point in going further with this.

There is no polling taking place other than testing for the interrupt which is a simple test of a Boolean.,
You can uncomment #define DBG_TOUCH in esp-tftespi-elecrow-xpt2026-irq.h and view the output in serial monitor to prove it to yourself.

Sorry, but I think this is lost cause so I'm giving up at this point. I think you are better off seeing if you can shave off performance some other way.
Paul--

[Bwanna]

@Pconti31 I agree. Am considering redesigning my main code to leverage FreeRTOS more efficiently.

Thank you VERY much for all your effort!

Cheers
Steve