Using ESP_INTR_FLAG_SHARED with the GPIO driver

[mmatton]

Greetings,

Note that my comments below are based on an investigation using the ESP-IDF 4.4.2.

We've run into a problem where we occasionally receive a subset of the GPIO interrupts we have configured with too much latency. The problem seems to be caused by the fact the GPIO interrupt was sometimes delayed by an ongoing flash operation and the fact that we did *not* have the ESP_INTR_FLAG_IRAM flag set when calling gpio_install_isr_service().

We started to look at whether we could add the ESP_INTR_FLAG_IRAM flag to the gpio_install_isr_service() but when we started peeling the onion, some concerns with this solution came up.
Q1: Any concerns with our thinking so far?

While we don't have much stuff we need to do in the ISR, some of the stuff we *do* need to do seems incompatible with the current ESP-IDF implementation. One of the main concerns that came up is that, other than the functions the GPIO driver registers to be called when an interrupt happens, none of the other GPIO APIs are in IRAM. More specifically, we were hoping to be able to use the gpio_get_level(), gpio_set_level() and gpio_intr_disable() *from within* the ISR, but none of these functions seem to be declared in IRAM. We *cannot* offload these calls to a task because said task would not be running during flash operations

Q2: Is there a reason why some of these GPIO driver APIs weren't put into IRAM since some of them are likely to be useful to call from an ISR?

We then turned my attention to the GPIO HAL (and the GPIO LL) layers. The former uses preprocessor defines, and the latter declares the APIs as 'inline'... So this is promising but since 'inline' doesn't guarantee that the compiler will indeed perform a substitution, it seems like __attribute__((always_inline)) would be the only way to guarantee that using the GPIO HAL/GPIO LL APIs directly from an IRAM function would be safe.

Q3: Is there any problem with our reasoning above?
Q4: Is there a reason why the GPIO LL functions aren't forcing inlining to ensure proper behaviour when these functions are being called from IRAM?

Finally, assuming all of the above gets solved, my next concern is that it will be very difficult for us to support a heterogeneous set of GPIO interrupts, where...:
- Some need to be handled during flash operations, and;
- Others shouldn't interrupt flash operations and should be able to run non-IRAM code.
I don't think there's any facilities to support this easily is there? It's almost as if I would like to have part of the GPIOs interrupts handle via IRAM and the others not... My main thought would be to handle the latter with a message queue and very high priority task but there's a lot of prioritization implications to something like this (i.e. it makes all non-IRAM interrupts lower priority than any other interrupt on the system... need to review if that's acceptable on our side)

Q5: Any thoughts on this?

Huge thanks in advance for any feedback...

Cheers!

[mmatton]

I forgot to mention, we're using an ESP32 (non S2, non C3)

[ESP_Bob]

Thank you for your suggestions.

From IDF 5.0, it already supports config some GPIO API to IRAM, and also adds `__attribute__((always_inline))`