ESP32 Forum

Hello again, one more question: Is there an guaranteed max interrupt latency time for LOWMED interrupt type?

Lets say there is interrupt registered like this:

How much time can pass before CPU gets to process my handler function (it has IRAM_ATTR) after physical GPIO interrupt occurs?
Is there any kind of context switch required, or it can jump from task code right to interrupt handler without any delay?

I know a task context switch takes 15 microseconds (And I would like to know why it takes so long? Its like 2000 instructions to just copy few CPU registers to stack? Or it does anything else?)
So is there similar context switch needed when interrupt occurs?

Its just there is gonna be interrupt each 208 us, to process the interrupt it takes about 100-150 us (unblock task that reads sample value over SPI which requires disabling interrupt because its shared on miso line), so I'd like to know if I should worry about missed interrupts or not.
Do you have any idea how to detect missed interrupt while it was disabled (because of SPI read)?
I could measure time between interrupts by calling esp_timer_get_time(), but I'm not sure if its safe to call this function from ISR context and how much tolerance I should add due to interrupt latency.

What if there occurs another interrupt while the CPU is processing my GPIO interrupt handler before it yields? Like from FreeRTOS tick timer?

Is there any kind of context switch required, or it can jump from task code right to interrupt handler without any delay?

Yes, there is a 'context switch' from tasks to ISRs, i.e. the basic task context is saved and switched out for the ISR context/stack.

It is hard to impossible to give a guaranteed upper bound for ISR latency because, besides other higher-priority interrupts, application code may disable interrupts at any time for a hard-to-predict duration, which it does each time a critical section is entered.
A single missed interrupt will be latched in the interrupt status registers and processed normally after interrupts are enabled again, but there's only a single bit for each interrupt, so the system won't know if it 'missed' one or a dozen of the same interrupt.