Misc - Espressif ESP32-S2 Programming Manual

Chapter 4. API Guides
1. The core
MAX_SYSCALL_INTERRUPT_PRIORITY
2. The core then spins on the spinlock using an atomic compare-and-set instruction until it acquires the lock.
A lock is acquired when the core is able to set the lock's owner value to the core's ID.
3. Once the spinlock is acquired, the function returns. The remainder of the critical section runs with
interrupts (or interrupt nesting) disabled.
• For taskEXIT_CRITICAL(&mux) (or taskEXIT_CRITICAL_ISR(&mux))
1. The core releases the spinlock by clearing the spinlock's owner value
2. The core re-enables interrupts (or interrupt nesting)
Restrictions and Considerations
Given that interrupts (or interrupt nesting) are disabled during a critical section, there are multiple restrictions regard-
ing what can be done within a critical sections. During a critical section, users should keep the following restrictions
and considerations in mind:
• Critical sections should be as kept as short as possible
– The longer the critical section lasts, the longer a pending interrupt can be delayed.
– A typical critical section should only access a few data structures and/or hardware registers
– If possible, defer as much processing and/or event handling to the outside of critical sections.
• FreeRTOS API should not be called from within a critical section
• Users should never call any blocking or yielding functions within a critical section

4.14.6 Misc

Floating Point Usage
Usually, when a context switch occurs:
• the current state of a CPU's registers are saved to the stack of task being switch out
• the previously saved state of the CPU's registers are loaded from the stack of the task being switched in
However, ESP-IDF FreeRTOS implements Lazy Context Switching for the FPU (Floating Point Unit) registers of a
CPU. In other words, when a context switch occurs on a particular core (e.g., CPU0), the state of the core's FPU
registers are not immediately saved to the stack of the task getting switched out (e.g., Task A). The FPU's registers
are left untouched until:
• A different task (e.g., Task B) runs on the same core and uses the FPU. This will trigger an exception that will
save the FPU registers to Task A's stack.
• Task A get's scheduled to the same core and continues execution. Saving and restoring the FPU's registers
is not necessary in this case.
However, given that tasks can be unpinned thus can be scheduled on different cores (e.g., Task A switches to CPU1),
it is unfeasible to copy and restore the FPU's registers across cores. Therefore, when a task utilizes the FPU (by
using a float type in its call flow), ESP-IDF FreeRTOS will automatically pin the task to the current core it is
running on. This ensures that all tasks that uses the FPU are always pinned to a particular core.
Furthermore, ESP-IDF FreeRTOS by default does not support the usage of the FPU within an interrupt context given
that the FPU's register state is tied to a particular task.
Note: ESP targets that contain an FPU do not support hardware acceleration for double precision floating point
arithmetic (double). Instead double is implemented via software hence the behavioral restrictions regarding the
float type do not apply to double. Note that due to the lack of hardware acceleration, double operations may
consume significantly more CPU time in comparison to float.
Espressif Systems
disables its interrupts
Submit Document Feedback
(or interrupt nesting)
1365
up to config-
Release v4.4