Electronics Guide

The Superloop and Its Limits

A bare-metal application typically consists of an initialization phase followed by an endless loop, often called a superloop, that polls inputs and dispatches work. Interrupt service routines handle time-critical events, setting flags that the loop examines on its next pass. For modest applications this structure is clear and adequate.

The superloop falters when tasks have conflicting timing needs. A long operation in one part of the loop delays every other part, so a slow display update can make the system miss a deadline elsewhere. Coordinating many such activities by hand, through carefully interleaved state machines and shared flags, grows fragile and hard to maintain as the application expands.

What an RTOS Provides

An RTOS introduces the abstraction of independent tasks, each written as if it had the processor to itself, while a scheduler shares the single core among them. The operating system also supplies services for tasks to communicate, synchronize, and share resources safely, relieving the application of building these mechanisms from scratch.

The defining quality of a real-time operating system, as opposed to a general-purpose one, is determinism. Its scheduling and synchronization services have bounded, predictable timing, so that a high-priority task is guaranteed to run within a known interval of becoming ready. This predictability is what allows an RTOS to meet hard deadlines.

Microcontroller-class real-time operating systems are typically small, configurable kernels rather than full operating systems. Widely used examples include FreeRTOS and Zephyr, both open source and both built around preemptive priority-based schedulers, alongside commercial kernels common in safety-critical work. A compact RTOS kernel can occupy only a few kilobytes of program memory, leaving most of a constrained device's resources for the application itself.

Preemptive Priority Scheduling

Most real-time operating systems use preemptive priority scheduling, in which every task is assigned a priority and the scheduler always runs the highest-priority task that is ready. If a higher-priority task becomes ready while a lower-priority one is running, the scheduler immediately preempts the running task, saves its context, and switches to the more urgent one.

This policy guarantees that urgent work is not delayed by less important activity, which is precisely the behavior real-time systems require. Its correctness depends on assigning priorities thoughtfully, because a poorly prioritized system can starve lower-priority tasks or fail to meet deadlines despite having ample processing capacity.

Time Slicing and Cooperative Scheduling

When several tasks share the same priority, the scheduler may divide processor time among them in rotation, a technique called time slicing or round-robin scheduling. Each task runs for a fixed interval before yielding to the next of equal priority, preventing any one from monopolizing the processor.

Cooperative scheduling takes the opposite stance, switching tasks only when the running task voluntarily yields. This approach simplifies the protection of shared data, since a task cannot be interrupted by another task at an arbitrary point, but it depends on every task yielding promptly and is therefore unsuitable when a misbehaving task could block the rest indefinitely.

Rate-Monotonic Priority Assignment

For systems of independent periodic tasks, rate-monotonic assignment provides a principled way to set priorities: the task with the shortest period receives the highest priority. This policy is provably optimal for such task sets, meaning that if any fixed-priority assignment can meet all deadlines, the rate-monotonic one can.

Schedulability analysis accompanies this assignment, calculating whether the combined processor demand of all tasks leaves enough time for each to meet its deadline. A classic sufficient test bounds total processor utilization, the sum of each task's execution time divided by its period: a set of independent periodic tasks is guaranteed schedulable under rate-monotonic priorities when that utilization stays below a limit that decreases with the number of tasks and approaches about sixty-nine percent, the natural logarithm of two, for many tasks. The bound is conservative, since it is sufficient but not necessary, and exact tests such as response-time analysis admit higher utilization. Either way, the analysis considers each task's execution time and period and provides a mathematical basis for confidence that the system will meet its timing requirements before it is ever run.

The Roles of Tasks and ISRs

Tasks are the units the scheduler manages. Each has its own stack and runs under the scheduler's control, able to call blocking operating-system services that suspend it until a condition is met. Tasks carry the bulk of the application's logic, structured as independent threads of execution.

Interrupt service routines run outside the scheduler's control, triggered by hardware events and executing at a priority above all tasks. They cannot block or wait, because there is no task context to suspend, and they must complete quickly to avoid delaying other interrupts and the scheduler itself. Their role is to respond immediately to hardware and to hand longer work to a task.

Deferred Interrupt Processing

A well-designed ISR does the minimum necessary at interrupt time and defers the rest. It might read a value from a peripheral, store it, and signal a task that processing is needed, then return. The signaled task, running at a lower priority, performs the detailed work when the scheduler next selects it.

This division keeps interrupt service routines short and their timing predictable, which preserves the system's responsiveness to other interrupts. It also moves complex logic into the task context, where it can use the full range of operating-system services and blocking calls that an ISR cannot. The pattern is sometimes implemented with a dedicated high-priority task that an ISR wakes to handle the deferred work.

Mutexes and Critical Sections

A mutex, short for mutual exclusion, protects a shared resource by ensuring that only one task accesses it at a time. A task acquires the mutex before using the resource and releases it afterward; any other task that attempts to acquire it meanwhile is blocked until the mutex becomes free. This serialization prevents the corruption that simultaneous access would cause.

For the briefest shared-data accesses, a task may instead enter a critical section by temporarily disabling interrupts or scheduling, guaranteeing that no other context runs during the access. Critical sections are simple and fast but must be kept extremely short, because they delay every other activity, including time-critical interrupts, for their entire duration.

Semaphores and Signaling

A semaphore is a counter used to signal events or to manage a pool of identical resources. A binary semaphore, taking only the values zero and one, signals that an event has occurred: an ISR gives the semaphore, and a waiting task that has taken it proceeds. This is the standard mechanism by which an interrupt wakes a task for deferred processing.

A counting semaphore tracks the number of available units of a resource, such as slots in a buffer. Tasks take a unit before using the resource and give it back afterward, and the semaphore blocks any task that requests a unit when none remain. Semaphores thus serve both to signal occurrences and to regulate access to limited resources.

Queues and Message Passing

Message queues let tasks exchange data safely without sharing memory directly. One task or ISR places a message into the queue, and another removes it, with the operating system handling the necessary synchronization internally. A task that reads from an empty queue blocks until a message arrives, providing both data transfer and synchronization in a single mechanism.

Message passing through queues is often preferable to shared variables protected by mutexes, because it confines the shared state to the queue and gives each task its own copy of the data. This containment reduces the opportunities for the subtle errors that arise when multiple tasks manipulate common memory, yielding designs that are easier to reason about.

Priority Inversion

Priority inversion occurs when a high-priority task is forced to wait for a resource held by a low-priority task, while a medium-priority task runs and prevents the low-priority one from releasing it. The high-priority task is effectively blocked by the medium-priority task, defeating the priority scheme and potentially causing missed deadlines.

Priority inheritance counters this hazard. When a high-priority task blocks on a mutex held by a lower-priority task, the operating system temporarily raises the holder's priority to that of the waiter, allowing it to run, finish, and release the mutex promptly. Once released, the holder returns to its original priority. This mechanism bounds the duration of inversion and is a standard feature of real-time mutexes.

The priority ceiling protocol offers a stronger alternative. Each mutex is assigned a ceiling equal to the highest priority of any task that may acquire it, and a task takes on that ceiling while holding the resource. This not only bounds inversion but also prevents the deadlock and chained blocking that can arise when tasks acquire several mutexes in different orders, at the cost of additional bookkeeping. A common simplification, the priority ceiling emulation found in many kernels, raises a task to a fixed ceiling immediately upon locking, trading some precision for ease of implementation.

Separating Interface from Implementation

A driver should present a clear interface that describes what it does, such as transmit a buffer or read a channel, while concealing how it does so. The application calls these interface functions without knowing the register layout or timing quirks of the underlying hardware, which keeps application code portable and comprehensible.

This separation localizes hardware dependence within the driver. When the hardware changes, only the driver's implementation must be revised, leaving the application and its interface untouched. The discipline of hiding peripheral details behind a stable interface is the single most important principle of driver design.

Driver State and Resource Management

Many peripherals operate over time rather than instantaneously, and their drivers must track the progress of ongoing operations. A driver typically maintains state describing whether a transfer is idle, in progress, or complete, and it uses this state to sequence the steps of an operation and to reject conflicting requests.

Drivers also manage the resources a peripheral requires, such as the buffers a transfer uses and the synchronization objects that signal completion. In an RTOS environment, a driver commonly exposes a blocking interface that suspends the calling task until the operation finishes, freeing the processor for other work in the interim and signaling the task through a semaphore when the hardware completes.

The Layered Model

At the lowest level, a register-access layer defines the addresses and bit fields of the peripheral hardware. Above it, a hardware abstraction layer, commonly abbreviated HAL, provides functions that perform peripheral operations in terms of those registers while hiding the specific bit manipulations. Higher still, a device or middleware layer composes these operations into complete services such as a file system or a communication stack.

Each layer depends only on the one immediately beneath it, so replacing a lower layer to support different hardware leaves the upper layers unchanged. A hardware abstraction layer written for one microcontroller family can be re-implemented for another, allowing application and middleware code to migrate with little or no modification.

Balancing Abstraction and Efficiency

Layering aids portability and clarity, but each layer adds function calls and generality that can cost execution time and memory. In the most performance-sensitive paths, the overhead of traversing several abstraction layers may be unacceptable, and direct register access or a thinner driver may be warranted.

Effective designs apply abstraction where its benefits justify its cost and bypass it where they do not. Configuration and infrequent operations gain from a portable, readable abstraction layer, while tight inner loops and latency-critical handlers may interact with hardware more directly. Judging this balance is a recurring engineering decision in driver development.

Polled, Interrupt-Driven, and DMA Transfers

The simplest driver polls the peripheral, repeatedly checking a status flag and transferring each unit of data when the hardware is ready. Polling is easy to write but wastes the processor, which spins idly while waiting, and it is therefore suited only to short transfers or to systems with nothing else to do.

An interrupt-driven driver instead lets the peripheral signal readiness through an interrupt, freeing the processor between data units to perform other work. The ISR transfers each unit as it becomes ready. This approach uses the processor efficiently for moderate data rates but still incurs an interrupt for every unit, which becomes burdensome at high speeds.

Offloading Transfers with DMA

A direct-memory-access, or DMA, driver delegates the actual data movement to a dedicated controller that transfers a whole block between the peripheral and memory without processor involvement. The processor configures the transfer, starts it, and is interrupted only once, on completion, regardless of how many units the block contains. This offloading is essential for high-throughput peripherals, where per-unit interrupts would overwhelm the processor.

The cost of DMA is added complexity. The driver must allocate and align buffers, configure the controller correctly, and coordinate with the cache and memory system so that the processor and the controller observe consistent data. On a processor with a data cache, a buffer the processor has written may still reside in the cache rather than in main memory, so the driver must clean the cache before a memory-to-peripheral transfer and invalidate it after a peripheral-to-memory transfer to prevent the two from reading stale data. Managing this coordination, and handling the completion interrupt that signals the transfer is done, makes DMA drivers more intricate than their interrupt-driven counterparts, a complexity justified by the efficiency they deliver.

What Makes Code Reentrant

A reentrant function can be safely entered by a second context while a first is still executing within it. This requires that the function not rely on shared mutable state that an intervening call could corrupt: it should operate on its arguments and local variables, avoid static or global data, and avoid calling non-reentrant functions in turn.

Functions that read or modify shared state are not inherently reentrant and must be protected when concurrency is possible. A driver function that manipulates a peripheral's registers, for instance, can be corrupted if a second context enters it midway, leaving the hardware in an inconsistent state. Identifying which functions must be reentrant, and which shared state they touch, is the first step toward thread safety.

Achieving Safe Concurrent Access

Where a function must access shared state, mutual exclusion makes that access safe. Guarding the shared operation with a mutex, or for the briefest accesses with a critical section, ensures that only one context manipulates the state at a time, preventing the interleaving that would corrupt it.

Particular care is needed for state shared between a task and an interrupt, because an ISR cannot acquire a mutex and a task cannot block an ISR. Such sharing is typically protected by briefly disabling the relevant interrupt around the task's access, or by structuring the interaction so that the ISR only signals the task rather than sharing data directly. Disciplined handling of these task-to-interrupt interactions eliminates a frequent source of intermittent, hard-to-reproduce defects.