Interrupt Allocation - Espressif ESP32-S2 Programming Manual

Chapter 2. API Reference
• stack_size: Size of current stack in bytes
• function: pointer to the shared stack function to be executed
Macros
ESP_EXECUTE_EXPRESSION_WITH_STACK(lock, stack, stack_size, expression)
Type Definitions
typedef void (*shared_stack_function)(void)

2.6.16 Interrupt allocation

Overview
The ESP32-S2 has one core, with 32 interrupts. Each interrupt has a certain priority level, most (but not all) interrupts
are connected to the interrupt mux.
Because there are more interrupt sources than interrupts, sometimes it makes sense to share an interrupt in multiple
drivers. The esp_intr_alloc()
A driver can allocate an interrupt for a certain peripheral by calling
esp_intr_alloc_intrstatus()). It can use the flags passed to this function to set the type of inter-
rupt allocated, specifying a specific level or trigger method. The interrupt allocation code will then find an applicable
interrupt, use the interrupt mux to hook it up to the peripheral, and install the given interrupt handler and ISR to it.
This code has two different types of interrupts it handles differently: Shared interrupts and non-shared interrupts.
The simplest of the two are non-shared interrupts: a separate interrupt is allocated per esp_intr_alloc call and this
interrupt is solely used for the peripheral attached to it, with only one ISR that will get called. Shared interrupts can
have multiple peripherals triggering it, with multiple ISRs being called when one of the peripherals attached signals
an interrupt. Thus, ISRs that are intended for shared interrupts should check the interrupt status of the peripheral
they service in order to see if any action is required.
Non-shared interrupts can be either level- or edge-triggered. Shared interrupts can only be level interrupts (because
of the chance of missed interrupts when edge interrupts are used.) (The logic behind this: DevA and DevB share an
int. DevB signals an int. Int line goes high. ISR handler calls code for DevA -> does nothing. ISR handler calls code
for DevB, but while doing that, DevA signals an int. ISR DevB is done, clears int for DevB, exits interrupt code.
Now an interrupt for DevA is still pending, but because the int line never went low (DevA kept it high even when the
int for DevB was cleared) the interrupt is never serviced.)
Multicore issues
Peripherals that can generate interrupts can be divided in two types:
• External peripherals, within the ESP32-S2 but outside the Xtensa cores themselves. Most ESP32-S2 periph-
erals are of this type.
• Internal peripherals, part of the Xtensa CPU cores themselves.
Interrupt handling differs slightly between these two types of peripherals.
Internal peripheral interrupts
• Three timer comparators
• A performance monitor
• Two software interrupts.
Internal interrupt sources are defined in esp_intr_alloc.h as ETS_INTERNAL_*_INTR_SOURCE.
These peripherals can only be configured from the core they are associated with. When generating an interrupt,
the interrupt they generate is hard-wired to their associated core; it's not possible to have e.g. an internal timer
comparator of one core generate an interrupt on another core. That is why these sources can only be managed using
Espressif Systems
abstraction exists to hide all these implementation details.
Each Xtensa CPU core has its own set of six internal peripherals:
1000
Submit Document Feedback
esp_intr_alloc()
Release v4.4
(or