NuttX RTOS NuttX Realtime Programming Gregory Nutt
Overview Interrupts Cooperative Scheduling Tasks Work Queues Realtime Schedulers
Real Time == == Deterministic Response Latency Stimulus Response Deadline Real time does not mean fast Real time systems have Deadlines
Bare Metal / No-OS Single Interrupt External Stimulus generates Hardware Interrupt Request (IRQ) Response Latency Hardware Response from Software Processing Hardware Interrupt Vector Software Processing Interrupt Handler Hardware Interrupt Return Hardware Interrupt Processing may may be be delayed if if interrupts disabled. Very Simple! Deterministic if if interrupts never disabled.
Bare Metal / No-OS Nested Interrupts Response Latency Single Interrupt Handler High Priority Deterministic? No Meet Deadlines? Maybe Medium Priority Low Priority Response Latency No OS way: Extensive interrupt processing, prioritized interrupts and, maybe, a main loop.
Bare Metal / No-OS Cooperative Scheduling Task A Task G Task B Task C Main, Background Loop Task F Task E Round-Robin Non-premptive Cooperative Scheduling State State machines ad hoc strategies Non-deterministic! ad hoc strategies Non-deterministic! Task D
RTOS Interrupts No OS way: Extensive interrupt processing, prioritized interrupts and, maybe, a main loop. Interrupt Interrupt Interrupt Interrupt Interrupt Signal Task Task A Signal Task Task B Signal Signal Task Task C Signal Task Task D Signal Task Task E RTOS way: Minimal work performed in in interrupt handlers Interrupt handlers only signal events to to tasks RTOS scheduler manages realtime behavior Prioritized interrupts replaced with prioritized tasks No benefit in in nesting interrupts
Properties of of NuttX Tasks Task = A thread within an an environment (like a Linux process) Thread = Normal sequence of of instruction execution Each thread has its its own stack Each thread has an an execution priority managed by by the OS Each thread is is a member of of a task group Share resources (like a Linux process) Can wait for events or or resource availability Threads communicate via Interprocess Communications (IPC): POSIX Message Queues, Signals, Counting semaphores, etc. Standard / / Linux compatible NuttX supports use of of standard IPCs from interrupt handlers
RTOS Interrupt Processing Stimulus Response Interrupt Handler Signals thread via IPC RTOS Scheduler Reassess next next ready-to-run thread Resumes thread if highest priority, ready-to-run Task Suspended, Waiting for event Thread awakened, Processes interrupt related event Task Suspended, Waiting for Next event
Work Queues Interrupt Handler Top Half Defer more extended interrupt processing to Worker Thread Prioritized Work Queue Worker Thread Bottom half Priority Qeue Non-premptive Qeue Very Very high high priority Inappropriate for for extended processing Non-deterministic! Use with care!
Multiple Work Queues P R I O R I T Y High Priority Work Queue Multiple Low Priority Work High Queues Priority Work High Queue Priority Work Queue Single high priority work queue Intended for interrupt bottom half Should be be highest priority Multiple low priority work queues Support priority inheritance Use to to implement asynchronous I/O (AIO) Thread pool
Components of of Response Latency Stimulus Event Hardware interrupt processing. Delay may be be extended if if interrupts disabled Software interrupt processing Thread state save (for Context Switch) Interrupt handler processing IPC Task execution may delayed if if it it does not have priority Interrupt return State restore OR Interrupt Context Switch Thread processing Output response
Synchronous vs vs Asynchronous Context Switch Asynchronous Context Switch == Interrupt Context Switch Critical part of of realtime response VERY efficient in in NuttX Near zero additional overhead Synchronous Context Switch Thread relinquishes CPU by by waiting for event NOT a critical part of of realtime response But may be be important to to overall performance and throughput
High Priority, Zero Latency Interrupts Software interrupt processing overhead Thread state save and restore (for interrupt Context Switch) ARM Cortex-M* Can support direct vector to to C-code Zero (software) latency NuttX implements with: Higher interrupt priority Direct vector to to C code Indirect interrupt context switches via PENDSV Important to to support: Very high rate interrupts Interrupts with very low latency requirements
Realtime Schedulers Realtime behavior realized via OS scheduler RTOS provides tools only enable realtime designs But a bad application design may still not be be realtime Scheduling Disciplines: Traditional // POSIX Schedulers Deadline Scheduler (and other modern schedulers) Rate Monotonic Scheduling (RMS)
Deadline Schedulers Example: Linux SCHED_DEADLINE Earliest Deadline First (EDF) Highly managed High processing overhead Complex Difficult to to configure correctly Non-standard Not commonly used in in a small RTOS Not currently supported by by NuttX
Standard / POSIX Schedulers Primary NuttX Specification: OpenGroup.org Standard Schedulers specified at at OpenGroup.org: SCHED_FIFO For Managed latency Supports Rate Monotonic Scheduling (RMS) SCHED_RR Not realtime Time-slicing Balanced throughput SCHED_SPORADIC Dynamic prioritization to to achieve processing budget For background tasks with guaranteed bandwidth Response latency vs. Throughput trade-offs
Rate Monotonic Scheduling Can achieve realtime behavior under certain circumstances: Strict priority scheduling Static priorities Priorities assigned according to to the rate monotonic conventions And this unrealistic assumption: Threads with shorter periods/deadlines are given higher priorities No resource sharing No waiting for resources Example: hardware, queue, etc. No semaphores or or locks. No disabling pre-emption No disabling interrupts No critical sections Priority Inversion / Priority Inheritance
Priority Inversion No Locks Event 1 Event 2 Event 3 Low Priority Task High PriorityTask Medium PriorityTask High High Priority Task Task has has to to wait wait at at the the priority of of the the low low priority task! task! High PriorityTask Medium PriorityTask With Lock Low Priority Task Low Priority Task Takes Lock High Priority Task Waits for Lock Low Priority Task Releases Lock
With Lock Event 1 Event 2 Event 3 Low Priority Task Priority Inheritance Medium Priority Task High PriorityTask Low Priority Task High PriorityTask Medium PriorityTask Low Priority Task Lock With Priority Inheritance Low Priority Task Takes Lock Priority Boosted Low Priority Task Releases Lock High High Priority Task Task now now Waits Waits at at the the High High priority
Effect of Violations of Assumptions Average Response Latency Increased Variability in Response Latency Deadline Missed Deadlines Stimulus Can be managed with good designs Response
Mixing Real-Time and non-real-time Tasks Real Time Priority Domain High Priority Work Queue Work Work Queue should be be highest priority because it it services the the interrupt bottom half half P R I O R I T Y Real-Time Tasks Non-Real-Time Tasks Real Real Time Time tasks tasks need need to to be be higher priority than than any any non-real-time task task Non-real-time tasks tasks must must be be lower lower priority than than all all Real Real time time tasks tasks so so that that they they cannot interfere with with Real-time behavior Non-Real-Time PriorityDomain