ESP32 Forum

I would like to know the interrupt latency for an external pin interrupt in ESP32.

I have done a measurement and delay from external trigger to application-provided ISR handler is around 2us (at 240MHz clock), which is around 500 cycles.

That is pretty much slower than I could imagine.

Yep; due to the way the Xtensa architecture is designed, handling interrupts in C unfortunately takes a fair few instructions. We'll see if we can lower this number eventually. If you really really need quick interrupt responses, you can possibly copy the freertos component to your own project and write an assembly interrupt handler for one of the high-priority interrupts in xtensa-vectors.S.

Thank you very much esp_sprite.
Unfortunately, that is far beyond my capabilities at this time . I will study it in detail.

ESP_igrr wrote:I have done a measurement and delay from external trigger to application-provided ISR handler is around 2us (at 240MHz clock), which is around 500 cycles.

yes, real interrupt delay is about 1.7~1.8uS, it seems too long for a 240Mhz processor,

I measure the delay on a 32Mhz 8bit mcu, delay is ~700nS...

I wonder if anyone has by any chance measured the pin-to-pin latency for a minimal interrupt handler (e.g.: on interrupt load a value from a memory and feed it out a GPIO port) written in assembly. The MIPS chip I'd like to replace currently does it in 225 ns at 80 MHz (18 clock cycles), and any increase is likely to make things no longer work.

If you write it in assembly, it doesn't need to be that slow. The ESP32 has high-priority interrupts which basically save PC and then immediately invoke your assembly-level routine. I can't tell if 18 cycles is enough to do what you want, obviously, but there is a fair chance it's possible.

Just to clarify: I don't need to make the same cycle count, just the same wall time (so approx 36/54 cycles at 160/240 MHz).

To be specific, this application operates as a bus slave to an 8-bit legacy computer bus. The most time-critical handler operates as a RAM simulator: it gets an interrupt, reads address bits off 16 GPIs, looks up an internal 64K table, writes an 8-bit data values to GPIOs, and sets the GPIOs to output. That has to happen within the time frame I indicated in order to avoid a lot of additional external logic.

Ah, yes, obviously, I somehow managed to mix up APB clock and CPU clock. Maybe I'll whip up a quick try to see what our interrupt latency can be in high-prio interrupt mode later on, I'm curious about that as well. (If any because some old projects of mine could perhaps use an upgrade...)