ESP32 Forum

Hi,
can you point me to documentation, where limitations and requirements of code running in ISR context are described?

Searching docs for "ISR context" didn't return any relevant results. Neither did cursory search through docs content.

Thanks.

I have no reference to point you to, but from the top of my head:
You can use any function in an ISR context with the following exceptions/limitations:
1. Only call FreeRTOS functions explicitly allowed in ISR context, i.e. "...FromISR" functions. This implies
2. No (potentially) blocking functions, i.e. functions which may have to wait for some event/interrupt to happen; this includes basically all functions which take a TickType_t 'maxwait' argument.
3. No ESP_LOGx logging. Logging is 'expensive' and may internally block e.g. waiting for UART buffer space.
Not necessarily required, but best to adhere to:
- keep ISR runtime as short as possible. No lengthy processing (loops) in an ISR.
- avoid excessive stack use in an ISR
- avoid floating point operations in an ISR

Thanks. Can I ask how long processing in ISR is still acceptable?

ADC Continuous Mode Driver sample recommends processing ADC data in main function after receiving notification from s_conv_done_cb callback. Since I need to do other stuff in main function, like sending HID reports, and ADC data are supplied as an argument to s_conv_done_cb as well, I figured why not simply process the data in the callback?

Measured with esp_cpu_get_cycle_count, data processing in callback takes 18000 cpu cycles. That's about 0.23ms at 80Mhz. Obvious consequences of my approach (a few missed ADC samples and slightly delayed processing) are acceptable. But since ADC callbacks are called in an ISR context, I'd like to avoid weird behavior like instability or missed interrupts from other sources. So far, everything seems to works fine.

Horvat wrote: ↑

Wed Jun 26, 2024 12:06 pm

Thanks. Can I ask how long processing in ISR is still acceptable?

Pretty much depends, I would say. Or, technically, as long as your application can accept (lower-priority) interrupts being disabled/delayed...

Since I need to do other stuff in main function, like sending HID reports, and ADC data are supplied as an argument to s_conv_done_cb as well, I figured why not simply process the data in the callback?

You may want to consider creating multiple tasks to handle separate things concurrently.

data processing in callback takes 18000 cpu cycles.

That's more than I'd personally be comfortable with, but may still work. I suggest to implement the callback in terms of putting the data into a (FreeRTOS) queue or a ringbuffer for a processing task to asynchronously consume, and to compare the cycle count of that approach. Depending on the amount of data that needs copying into the queue/buffer, I expect the callback to complete 5-10x faster in this case.