Hard real-time interrupt support

[zephyrbot]

Reported by Carles Cufi:

Currently the ISR wrapper that envelopes all ISR execution code, and that is automatically called when using the IRQ_CONNECT() macro, adds a certain amount of latency from the moment the hardware interrupt is triggered to the first instruction executed inside the actual ISR (i.e. the one whose address is passed as a parameter to IRQ_CONNECT().

We would therefore benefit from a framework that allows interrupts that have very strict timing requirements due to external constraints (commonly referred to as hard real-time interrupts) to skip the wrapping and execute directly as soon as the hardware allows it.

A short wish list for the framework:

• Cross-architecture (though initially only required by the BLE Controller on ARM Cortex-M0 and Cortex-M4)
• Provides a IRQ_CONNECT_DIRECT() macro that places the ISR directly in the vector table for guaranteed minimum latency
• A short description of guidelines of duties and limitations of interrupts/ISRs declaring themselves as hard real-time: Ability to interact with the kernel (at the very least posting a semaphore) Obligation to call the power-management code at some point in the ISR code since there's no wrapper to do it for it
• Reduction of the amount of time the kernel spends with interrupts disabled. This is critical for hard real-time interrupts and currently it is O ( n ) with threads/timeouts: tracked in GH-2897

Please note that this is not a replacement for the Zero-Latency Interrupt (ZLI) framework already in place, but is in fact complementing it.

(Imported from Jira ZEP-1038)

[zephyrbot]

Blocks GH-2222

[zephyrbot]

Blocks GH-2159