touchAttachInterrupt takes 25ms for each pin!!!

[AKTanara]

Board

ESP32-WROOM-32E (4MB Flash)

Device Description

Nothing

Hardware Configuration

Using On both WROOM Tester and on PCB

Version

v2.0.4

IDE Name

Arduino IDE 1.8.19

Operating System

Windows 10

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

921600

Description

I was using ESP32 Arduino v1.0.6 to program ESP32-WROOM-32E (4MB Flash) and had no issue whatsoever. Since I upgraded to ESP32 Arduino v2.0.4 I noticed lags in hardware response. Tracking down I reached some strange difference between two versions. touchAttachInterrupt that took less than 1ms in v1.0.6 now takes 26ms!

Sketch

long beginDur = 0;

void IRAM_ATTR gotTouch() {}

void setup() {
    Serial.begin(115200);
}

void loop() {
    beginDur = millis();
    touchAttachInterrupt(4, gotTouch, 30);
    Serial.println("dur: " + String(millis() - beginDur));
}

Debug Message

Serial output while using ESP32 Arduino v1.0.6:

dur: 0
dur: 0
dur: 0
dur: 0

Serial output while using ESP32 Arduino v2.0.4:

dur: 26
dur: 26
dur: 26
dur: 26

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@AKTanara - You are measuring how long does it take to execute touchAttachInterrupt(4, gotTouch, 30);.

It is done once, usually in setup().
Touch Driver is now based in IDF.
Is it an issue for your application?

[SuGlider]

Since I upgraded to ESP32 Arduino v2.0.4 I noticed lags in hardware response.

The time it takes to execute touchAttachInterrupt(4, gotTouch, 30); has nothing to do with the time it takes from the moment GPIO4 is touched and the respective gotTouch() callback is executed.

What exactly is the issue that you are describing?

[AKTanara]

@SuGlider - First of all thanks for your reply,

@AKTanara - You are measuring how long does it take to execute touchAttachInterrupt(4, gotTouch, 30);.

Yep, I'm well aware of that...

It is done once, usually in setup(). Touch Driver is now based in IDF. Is it an issue for your application?

Actually for the best touch response I was updating the thresholds of touch triggers continuously. So yes it is an issue for my application. Besides I find it fairly unusual for such a simple task on a 240MHz processor to take 25ms per pin! while it wasn't even taking 1ms in previous versions. So I am confident to say it is a bug.
Tracking down the functions I have also noticed that this issue is sourced in IDF and since v1.0.6 has no support for ESP32-S3 I'm hesitating to base my new product on S3.

[SuGlider]

@AKTanara - Thanks for the clarification.

Tracking down the functions I have also noticed that this issue is sourced in IDF and since v1.0.6 has no support for ESP32-S3 I'm hesitating to base my new product on S3.

ESP32-S2 and ESP32-S3 have a way better Touch hardware that uses another IDF code for this peripheral.
You will have no issue if you move to ESP32-S3 chip.

I just tested the sketch of this issue with ESP32-S3 and Arduino Core 2.0.4. Using GPIO 4 also (Touch 4 of ESP32-S3)

output of S3:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x43c
load:0x403c9700,len:0xbec
load:0x403cc700,len:0x2a3c
SHA-256 comparison failed:
Calculated: 3611f330726ad4edf64f62982b0568332a5800bc59425cab90be5379db92c108
Expected: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Attempting to boot anyway...
entry 0x403c98d8
dur: 21
dur: 0
dur: 0
dur: 0
dur: 0
dur: 0
dur: 0
dur: 0
dur: 0

[SuGlider]

For the ESP32 chip, indeed there is the issue of 25~27ms per execution of touchAttachInterrupt(4, gotTouch, 30);.
In the ESP32S3 it take that time just the first time...

We can check the code and verify if we can improve it.

[SuGlider]

The issue with ESP32 is here:
https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-touch.c#L224

It takes the 25ms. If the sktech changes the Threshold all the time, this will be a problem with IDF in Core 2.0.2+, when we moved it to IDF, making it different from Core 1.0.6 version.

[SuGlider]

For the ESP32 there is no other way to change the Threshold using just IDF touch driver calls...
https://github.com/espressif/esp-idf/blob/master/components/driver/esp32/touch_sensor.c#L280-L314

We can try to use HAL level calls ....
https://github.com/espressif/esp-idf/blob/master/components/driver/esp32/touch_sensor.c#L288

@P-R-O-C-H-Y - Please investigate if we can just use touch_hal_set_threshold(touch_num, threshold); to change the Threshold in the ESP32 code and make it faster. Thanks.

[SuGlider]

@AKTanara - Maybe we can fix it to behave the same way as in 1.0.6... let's see.

[SuGlider]

OK, solution is here:
https://github.com/espressif/esp-idf/blob/master/components/driver/touch_sensor_common.c#L179-L199