HighPriorityInterrupts

Locking in a protected object where there’s no interrupt handling involved (detected in the RTS by the PO’s ceiling priority not being in System.Interrupt_Priority) is managed by temporarily raising the current task’s priority to the ceiling priority of the PO.

If there is interrupt handling involved, then

• if the lock is already in an interrupt context, no action is needed. We’re already in the PO’s handler, and may be interrupted by a higher-priority nested interrupt, but that can’t be for this PO (there’s only one Interrupt_Priority setting).
• if not, the RTS uses taskDISABLE_INTERRUPTS to prevent any application interrupts.

FreeRTOS provides useful information on interrupt settings for Cortex-M processors. The relevance here is that taskDISABLE_INTERRUPTS only disables interrupts that have a logical priority within the range that is permitted to make FreeRTOS API calls, which in the case of this RTOS (for Cortex M3, M4F, so far) is ARM interrupt priority 15 (lowest) to 5 (highest). These correspond to System.Interrupt_Priority 8 to 18 respectively.

If you need very high priority interrupts (as, for example, to manage electronic speed control motors), you can arrange to run them at priorities logically above those permitted for application code (i.e. 4 to 0), but the penalties are that

• you have to set up the Nested Vectored Interrupt Controller (NVIC) yourself (see adainclude/s-interr.adb for your part),
• you must not use any FreeRTOS API calls.