10. Real-Time Systems and RTOS

Introduction and Context

Microprocessors and microcontrollers do not merely compute values; they interact with physical processes whose timing may be as important as numerical correctness. A motor-control loop, airbag controller, pacemaker, industrial protection relay, and robotic actuator must respond within specified time limits. A result produced after its deadline may be as useless or dangerous as an incorrect result. This requirement gives rise to real-time systems.

A real-time system is a computing system in which the correctness of an operation depends on both the logical result and the time at which that result is produced. Real-time computing is therefore concerned with predictable response, bounded delays, scheduling, synchronization, resource sharing, and controlled interaction with hardware. It is not synonymous with “fast computing.” A slower system with predictable timing may be more suitable than a faster system with variable and unbounded delays.

In small embedded products, timing can be implemented by a super-loop, interrupt service routines, and hardware timers. As the number of functions increases, this approach becomes difficult to verify and maintain. A real-time operating system (RTOS) provides abstractions such as tasks, queues, semaphores, mutexes, software timers, and event groups. These abstractions permit an application to be divided into independently understandable activities while allowing the kernel to control processor allocation.

This chapter develops the principles needed to analyze and design real-time applications for microcontrollers. It links timing theory with practical RTOS mechanisms and also explains when a bare-metal design remains the better engineering choice.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish hard, firm, and soft real-time requirements.

2. Analyze latency, response time, execution time, jitter, utilization, and deadlines.

3. Explain preemptive and cooperative scheduling and apply common scheduling policies.

4. Design task-based applications using priorities, queues, semaphores, mutexes, and event mechanisms.

5. Diagnose priority inversion, deadlock, starvation, race conditions, and missed deadlines.

6. Compare an RTOS-based architecture with a timer-driven bare-metal architecture.

7. Apply timing analysis, measurement, testing, and professional design practices to embedded systems.

What Makes a System Real-Time?

The defining property of a real-time system is temporal correctness. Let an event occur at time \(t_a\), and let the corresponding response be completed at \(t_c\). The response time is

\[R = t_c - t_a\]

If the required deadline is \(D\), the response is acceptable only when \(R \leq D\), subject to the system specification. The deadline may be relative to the triggering event or an absolute point on a global time scale.

A useful distinction is between latency and execution time. Execution time is the processor time required by a computation. Latency includes waiting caused by interrupts, higher-priority tasks, synchronization, disabled interrupts, cache or memory effects, and scheduling decisions. A task can have a short execution time but a long response time if it waits in a ready queue or for a shared resource.

Jitter is variation in response time or periodic activation time. For a periodic sampling task, excessive jitter changes the effective sampling interval and can affect control stability, signal reconstruction, and communication protocols. Thus, average timing is inadequate for safety-critical analysis; worst-case or statistically justified bounds are required.

Real-time requirements are commonly classified as follows:

• Hard real-time: Missing a deadline represents system failure or may create an unsafe condition. Examples include over-current protection and a flight-control stabilization loop.
• Firm real-time: A late result has no value, but an occasional missed deadline may not cause catastrophic failure. A stale industrial inspection result is an example.
• Soft real-time: Late results retain value but reduce quality. Audio playback, user-interface refresh, and noncritical telemetry commonly belong here.

These categories describe consequences, not processor speed. A hard real-time system may use a modest microcontroller if its workload is bounded and its timing is carefully engineered.

Timing Models and Schedulability

A task is a schedulable unit of work. A periodic task is activated at regular intervals; a sporadic task is activated irregularly but has a known minimum inter-arrival time; an aperiodic task has no useful bound on arrivals. Each task can be described by its execution time \(C\), period or minimum inter-arrival time \(T\), deadline \(D\), and priority.

For a periodic task set, processor utilization is approximated by

\[U = \sum_{i=1}^{n} \frac{C_i}{T_i}\]

This calculation is a first screening tool rather than a complete proof of schedulability. Context switches, interrupt processing, blocking, timing overhead, and execution-time variation must also be included. A system with low average utilization may still miss deadlines if a task experiences unbounded blocking.

Under fixed-priority preemptive scheduling, a higher-priority task can interrupt a lower-priority task. A widely used policy is rate-monotonic scheduling (RMS), in which shorter-period tasks receive higher priority. Another is deadline-monotonic scheduling, in which shorter relative deadlines receive higher priority. Under earliest-deadline-first (EDF), priorities vary dynamically and the task with the nearest deadline executes first.

For a simplified fixed-priority analysis, the response time of task \(i\) can be estimated iteratively:

\[R_i = C_i + B_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j\]

Here, \(B_i\) is the maximum blocking time and \(hp(i)\) is the set of tasks with higher priority than task \(i\). The iteration begins with \(R_i=C_i+B_i\) and continues until the value stabilizes or exceeds the deadline. This model highlights an important point: lower-priority tasks can affect the schedulability of higher-priority tasks through resource blocking.

The utilization equation and response-time equation are models, not substitutes for measurement and design judgment. Worst-case execution time is often difficult to determine because of compiler optimization, memory wait states, interrupts, data-dependent loops, and peripheral behavior. Engineers therefore combine static reasoning with instrumentation and stress testing.

From Super-Loops to Kernel-Based Designs

A bare-metal super-loop repeatedly calls functions such as `read_inputs()`, `control_update()`, and `send_status()`. It is simple, has little memory overhead, and can be highly deterministic when every function is short and bounded. Interrupts may record events or perform urgent hardware actions, while the main loop processes deferred work.

The super-loop becomes problematic when one function blocks, when functions have substantially different periods, or when many event combinations must be handled. A long communication transaction can delay control work; adding a new feature can alter the timing of all existing functions; and shared state can be changed by both interrupts and foreground code without a clear synchronization policy.

An RTOS introduces a kernel that manages tasks and selects which ready task runs. A task normally has its own stack, state, priority, and program flow. The kernel can suspend a task while it waits for an event, allowing another ready task to execute. This makes waiting explicit and avoids repeatedly polling inactive functions.

The RTOS does not automatically make an application real-time. Poor priorities, unbounded memory allocation, long critical sections, blocking device drivers, and incorrect synchronization can still produce missed deadlines. The kernel is an engineering tool whose configuration and use must be justified by the requirements.

Scheduling, Preemption, and Context Switching

A scheduler chooses the next task. In a cooperative system, a task continues until it voluntarily yields, blocks, or completes a designated unit of work. Cooperative scheduling can be simple and predictable, but a badly behaved task can delay every other task.

In preemptive scheduling, the kernel can suspend a running task when a higher-priority task becomes ready. This improves response to urgent events but introduces context-switch overhead and increases the need for synchronization. A context switch saves the processor state of one task and restores the state of another. The cost depends on processor architecture, compiler, floating-point context, memory system, and kernel configuration.

Interrupt service routines should normally be short. An ISR can capture a timestamp, read a peripheral register, clear the interrupt source, place data in a buffer, and notify a task. Lengthy parsing, formatted output, dynamic allocation, and complex control algorithms are generally better deferred to task context. A useful design pattern is “top half and bottom half”: the ISR performs urgent acknowledgement and the task performs substantial processing.

Priority assignment should reflect urgency and blocking relationships rather than organizational importance. A control task with a tight deadline may require a higher priority than a diagnostic task, even if diagnostics are more visible to a developer. Priorities should be documented together with periods, deadlines, execution-time assumptions, and resource dependencies.

Communication and Synchronization Mechanisms

Concurrency creates two distinct needs: communication and mutual exclusion. Communication transfers information between activities; mutual exclusion protects an operation or data structure from simultaneous access. Confusing these purposes leads to fragile designs.

A queue transfers discrete messages, often by copying fixed-size objects into a kernel-managed buffer. It is appropriate when a producer generates commands or measurements for a consumer. Queue length is a design parameter: a queue that is too short loses data or causes blocking, while an excessively long queue increases memory use and can hide a downstream overload.

A binary semaphore commonly represents an event or a one-of-two state. An ISR may give a semaphore to wake a task. A counting semaphore represents multiple identical resources or accumulated events. A mutex is specifically intended to protect a shared resource and usually supports ownership and priority inheritance.

A mutex should protect a small, clearly defined critical region. The task that locks it must unlock it, and calls that can block for an unbounded time should not normally be made while holding it. A spinlock is generally unsuitable for a single-core microcontroller because spinning wastes processor time; blocking synchronization is preferable unless the hardware and kernel provide a specific short-duration use case.

Event groups or flag sets allow a task to wait for one or more conditions. They are useful when a task requires, for example, both sensor initialization and network availability. Direct task notifications, message buffers, and stream buffers may provide lower-overhead alternatives in compact RTOS implementations.

Shared variables accessed by an ISR and a task require more than the `volatile` qualifier. `volatile` informs the compiler that a value may change unexpectedly; it does not make a multi-step operation atomic and does not establish mutual exclusion. Atomic instructions, critical sections, lock-free protocols, or appropriate kernel primitives are needed according to the data size and access pattern.

Resource Sharing and Priority Inversion

Priority inversion occurs when a high-priority task is indirectly delayed by a low-priority task holding a resource. The problem becomes severe when a medium-priority task preempts the low-priority task, preventing it from releasing the resource needed by the high-priority task. Consequently, the medium-priority task appears to delay the high-priority task even though it does not share the resource.

Priority inheritance temporarily raises the priority of the resource-holding task to that of the highest-priority blocked task. Priority ceiling protocols assign a ceiling to resources and restrict task execution or priority according to a predefined policy. These methods reduce unbounded inversion, but they do not eliminate poor resource design. Shared-resource critical sections should remain short, nesting should be minimized, and resource acquisition order should be consistent.

Deadlock occurs when tasks wait indefinitely for one another. The classical conditions are mutual exclusion, hold-and-wait, no preemption, and circular wait. Designers can prevent deadlock by imposing a global lock order, avoiding nested locks, using timeouts, or replacing shared state with message passing. A timeout is a diagnostic and recovery mechanism, not proof that deadlock is impossible.

Starvation occurs when a task is continually denied processor time or a resource. Fair scheduling, bounded critical sections, aging mechanisms, and capacity analysis help control starvation. Race conditions arise when correctness depends on an uncontrolled order of concurrent operations. They are especially difficult to reproduce because instrumentation can change timing and make the fault disappear.

Designing an RTOS Application

A disciplined design begins with externally observable events and timing requirements rather than with an arbitrary number of tasks. The designer identifies inputs, outputs, activation conditions, deadlines, data rates, failure responses, and resource ownership. Functions are then grouped into tasks according to timing, cohesion, and blocking behavior.

Consider a motor controller with a 1 kHz current-control loop, a 100 Hz supervisory task, a communication task, and a diagnostic logger. The current-control task must have a bounded execution time substantially below 1 ms and should avoid waiting for communication or file-system activity. The supervisory task can exchange set points through a queue or protected data structure. Communication and logging should use lower priorities and bounded buffers. A fault ISR may disable the power stage immediately and notify a high-priority fault-management task.

The task design should specify:

• activation source and period;
• worst-case execution-time estimate;
• relative deadline and priority;
• inputs, outputs, and queue capacities;
• resources that may be locked;
• maximum blocking time;
• behavior on overflow, timeout, or hardware failure.

Initialization order is also significant. Clocks, memory, interrupt vectors, peripherals, kernel objects, and tasks must be initialized in a sequence that prevents an interrupt from using an unready object. Startup self-tests should complete before safety-relevant outputs are enabled.

Dynamic memory allocation is convenient but can introduce fragmentation and unpredictable allocation time. Static allocation or fixed-size memory pools are often preferred for hard real-time paths. If dynamic allocation is necessary, it should be restricted to initialization or governed by a bounded allocator.

Verification, Measurement, and Debugging

Timing claims require evidence. Instrumentation can toggle a GPIO at task entry and exit, allowing an oscilloscope or logic analyzer to measure execution time, period, jitter, and interrupt interference. A cycle counter can provide finer resolution, but measurement itself must be accounted for. RTOS trace tools can show task states, ready-queue transitions, blocking intervals, queue occupancy, and interrupt activity.

Testing should include nominal operation, maximum input rates, simultaneous events, full queues, delayed peripherals, communication failure, clock variation, and repeated reset conditions. Stress tests should intentionally create contention and overload. The system should expose deadline misses and stack-watermark violations rather than silently continuing.

A useful diagnostic distinction is between a computation that is too slow and one that is delayed. Execution-time profiling identifies the former; trace analysis and response-time measurement identify the latter. Stack sizing requires observing high-water marks under representative and stress workloads. Watchdog timers can recover from certain failures, but a watchdog is not a substitute for finding the cause of a missed deadline. Its timeout must be longer than legitimate worst-case execution and recovery intervals yet short enough to limit unsafe persistence.

Bare-Metal Alternatives and Selection Criteria

An RTOS is attractive when the application contains multiple semi-independent activities, complex communication, reusable middleware, or evolving requirements. It provides structure, but consumes RAM and flash, adds context-switch overhead, and introduces kernel configuration and debugging concerns.

Bare-metal design remains appropriate when the application has a small number of tightly coupled functions, strict resource limits, or a timing structure that is easier to prove without a kernel. A timer-driven cyclic executive is a useful middle ground: tasks are assigned to time slots in a major cycle, and the schedule is statically constructed. This can provide excellent determinism, but the schedule becomes difficult to modify as functionality grows.

The choice should be based on timing assurance, maintainability, certification demands, memory budget, team expertise, middleware requirements, and expected product evolution. “RTOS” and “bare metal” are not competing ideologies; they are architectural options. Some systems combine them, using an RTOS for communications and supervisory functions while hardware timers and carefully controlled interrupt paths handle the most urgent protection actions.

Illustrative Case Study: Conveyor Safety and Quality Controller

Background

A fictional manufacturing company develops a microcontroller-based controller for a high-speed conveyor. The controller reads optical sensors, regulates conveyor speed, rejects defective products, reports production data, and stops the motor if a guard is opened or an over-current condition is detected.

Situation and Problem

The first prototype uses a super-loop. Sensor processing, serial communication, display updates, and data logging are executed sequentially. During high communication traffic, the loop becomes long and the reject actuator occasionally operates late. The safety stop is implemented in an interrupt, but the interrupt handler also performs diagnostic formatting, producing variable latency.

Analysis

Measurements show that the reject decision has a 2 ms deadline. Normal response is 1.2 ms, but bursts of serial traffic increase it beyond 4 ms. The safety stop must respond within a much tighter bounded interval and must not depend on the communication stack. The system therefore contains both hard and soft real-time functions.

Approach and Solution

The design is reorganized around an RTOS. A high-priority sensor task is activated by a timer and processes captured sensor events. A reject task receives timestamped product decisions through a queue and drives the actuator. Communication and display tasks run at lower priorities. Logging uses a bounded buffer and discards noncritical diagnostic records when full.

The guard and over-current inputs are connected to hardware interrupt paths that immediately disable the motor-drive enable signal. The ISR records the fault source and notifies a fault task, which performs controlled shutdown and reporting. No formatted output is performed in the ISR.

A mutex protects a shared configuration object, and priority inheritance is enabled. The motor-control task never waits for the communication task. All queues have documented capacities, and overflow produces a fault record. GPIO instrumentation confirms the sensor-to-reject response remains below the required deadline under maximum communication load.

Outcome

The architecture separates safety action, hard timing work, and noncritical services. The reject task meets its deadline in stress tests, while the safety path is independent of RTOS scheduling for its first protective action. The project also gains clearer ownership of data and more informative diagnostics.

Learning Points

The case demonstrates that an RTOS does not replace hardware protection, that ISRs should defer substantial work, and that timing analysis must include interference and blocking. It also shows why queue capacities, priority assignments, and failure behavior are design decisions rather than implementation details.

Challenges, Professional Practice, and Governance

Common mistakes include assigning priorities by feature importance, using delays instead of event-driven synchronization, placing blocking calls in high-priority tasks, protecting too much code with disabled interrupts, and assuming that average execution time represents worst-case behavior. Another frequent error is allowing a low-priority logging operation to share a lock with a hard real-time control path.

Safety-related systems require traceability from hazard analysis to timing requirements, architecture, implementation, verification, and change control. Depending on the application domain, standards such as IEC 61508, ISO 26262, IEC 62304, DO-178C, or sector-specific industrial standards may impose process and evidence requirements. The applicable standard must be selected according to the product domain; no single RTOS guarantees compliance.

Security also has timing implications. Authentication, encryption, secure boot, and intrusion detection consume computation and memory and may introduce bursts of activity. Security tasks must be included in schedulability analysis. A denial-of-service condition through excessive communication can become a real-time failure, so input validation, rate limiting, and bounded parsing are necessary.

Emerging microcontrollers increasingly include multicore processors, hardware accelerators, memory-protection units, and integrated tracing. Multicore systems introduce cache coherence, inter-core communication, affinity, and shared-bus contention. Virtualization and mixed-criticality systems permit functions of different assurance levels to share hardware, but require stronger temporal and spatial isolation. Model-based design, automated trace analysis, and formal verification of selected synchronization protocols are becoming more practical. These developments improve capability but also enlarge the set of timing interactions that must be controlled.

Best-Practice Design Principles

1. State deadlines, periods, activation causes, and consequences of lateness explicitly.

2. Bound execution time, blocking time, interrupt duration, queue growth, and recovery time.

3. Keep ISRs short and defer computation to appropriately prioritized tasks.

4. Prefer message passing for ownership transfer and use mutexes only for well-defined shared resources.

5. Use priority inheritance or a ceiling protocol where shared resources require it.

6. Avoid unbounded allocation, recursion, uncontrolled polling, and indefinite waits in critical paths.

7. Measure worst-case behavior under overload, contention, and fault conditions.

8. Separate safety protection from convenience functions such as logging and user-interface updates.

9. Document task interfaces, resource ownership, priority rationale, and failure handling.

10. Treat timing, security, and maintainability as connected system properties.

Chapter Summary

Real-time systems require correctness in both value and time. Their analysis depends on response time, execution time, latency, jitter, deadlines, utilization, blocking, and task activation models. Hard, firm, and soft real-time classifications express the consequences of lateness. Fixed-priority, rate-monotonic, deadline-monotonic, and dynamic EDF scheduling provide different ways to allocate processor time.

An RTOS organizes concurrent functions through tasks and kernel services such as queues, semaphores, mutexes, event groups, and notifications. Correct design requires careful priority assignment, bounded critical sections, avoidance of deadlock and starvation, and control of priority inversion. Bare-metal super-loops and cyclic executives remain valid alternatives when the application is small or a static schedule is easier to verify. In either architecture, timing requirements must be supported by analysis, measurement, stress testing, and documented engineering decisions.

Key Terms

Real-time system: A system whose correctness depends on logical results and their timing.

Deadline: The latest acceptable completion time for an operation.

Latency: Delay between an event and the start or completion of its response.

Jitter: Variation in activation time or response time.

Hard real-time: A timing regime in which a missed deadline constitutes system failure or unacceptable danger.

Firm real-time: A regime in which a late result has no value, although occasional misses may be tolerated.

Soft real-time: A regime in which late results retain reduced value.

Task: A schedulable unit of execution with its own state and timing properties.

Period: Time between successive activations of a periodic task.

Worst-case execution time: The maximum processor time required by a task under defined assumptions.

Preemption: Suspension of a running task so another eligible task can execute.

Context switch: Saving one task’s processor state and restoring another’s.

Mutex: An ownership-based synchronization object used to protect a shared resource.

Semaphore: A synchronization counter or event mechanism used for signaling or resource counting.

Priority inversion: Delay of a higher-priority task because a lower-priority task holds a needed resource.

Priority inheritance: Temporary elevation of a resource holder to reduce priority inversion.

Deadlock: Permanent waiting caused by circular or otherwise unresolved resource dependencies.

Schedulability: The property that all specified tasks can meet their timing requirements.

Cyclic executive: A statically scheduled bare-metal architecture organized into repeating time frames.

Review Questions

Short Answer Questions

1. Why is a real-time system not necessarily a high-speed system?

2. Distinguish latency from execution time.

3. What is the purpose of a queue in an RTOS application?

4. Why does `volatile` not by itself solve concurrency problems?

5. Define priority inversion.

Long Answer Questions

1. Explain hard, firm, and soft real-time systems with suitable embedded examples.

2. Describe preemptive scheduling and discuss the benefits and costs of context switching.

3. Explain how mutexes, semaphores, queues, and event mechanisms serve different synchronization needs.

4. Derive the main considerations in fixed-priority response-time analysis.

5. Compare an RTOS-based design with a bare-metal cyclic executive for a multi-function controller.

Analytical / Application Questions

1. A periodic task set has execution times and periods of (1 ms, 5 ms), (2 ms, 10 ms), and (3 ms, 20 ms). Calculate basic utilization and explain why the result alone cannot prove schedulability.

2. Design a task and synchronization architecture for a controller that must process a 500 Hz sensor, communicate over a serial link, update a display, and log faults.

3. A high-priority control task is intermittently delayed by a low-priority logging task while a medium-priority communication task continues to run. Identify the concurrency problem and propose two remedies.

22. Multiple Choice Questions with Answers

Question 1

Which statement best defines a real-time system?

A. It always uses the fastest available processor.

B. It produces logically correct results within specified timing constraints.

C. It executes only one task at a time.

D. It cannot use an operating system.

Correct Answer: B. It produces logically correct results within specified timing constraints.

Question 2

A task has an execution time of 2 ms and a period of 10 ms. Its basic processor utilization is:

A. 2%

B. 5%

C. 20%

D. 200%

Correct Answer: C. 20%

Question 3

Which mechanism is most appropriate for transferring discrete sensor messages from one task to another?

A. Queue

B. Mutex

C. Critical-section mask

D. Priority ceiling

Correct Answer: A. Queue

Question 4

What is the primary purpose of priority inheritance?

A. To increase the clock frequency of the processor

B. To prevent all task preemption

C. To reduce priority inversion caused by resource ownership

D. To eliminate the need for task priorities

Correct Answer: C. To reduce priority inversion caused by resource ownership

Question 5

Which operation is generally most appropriate inside a short interrupt service routine?

A. Formatting a long diagnostic string

B. Waiting for a communication response

C. Performing dynamic memory compaction

D. Capturing the event and notifying a task

Correct Answer: D. Capturing the event and notifying a task

Question 6

A late result has no value, but an occasional missed deadline does not necessarily cause system failure. This is characteristic of:

A. Hard real-time computing

B. Firm real-time computing

C. Non-real-time computing

D. Batch computing

Correct Answer: B. Firm real-time computing

Question 7

Which condition is a common cause of deadlock?

A. A task uses a fixed-size queue

B. Tasks acquire multiple locks in inconsistent orders

C. An ISR records a timestamp

D. A periodic task has a documented deadline

Correct Answer: B. Tasks acquire multiple locks in inconsistent orders

Question 8

Why is average execution time insufficient for proving a hard deadline?

A. Average time does not reveal worst-case interference and delays.

B. Average time is always greater than worst-case time.

C. Average time applies only to communication tasks.

D. Average time cannot be measured electronically.

Correct Answer: A. Average time does not reveal worst-case interference and delays.

Question 9

In a bare-metal cyclic executive, application functions are primarily organized according to:

A. A dynamically changing priority queue

B. A statically constructed repeating time schedule

C. Random event polling

D. Mutex ownership

Correct Answer: B. A statically constructed repeating time schedule

Question 10

A low-priority task holds a mutex needed by a high-priority task, while a medium-priority task preempts the low-priority task. What problem is illustrated?

A. Starvation caused by queue overflow

B. Priority inversion

C. Cache coherency failure

D. Deadline monotonic scheduling

Correct Answer: B. Priority inversion