Bare-metal vs RTOS — when to use each: Exercises

Formula The two tools you will reuse (defined from zero)

Tool 1 — super-loop worst-case latency. In a "super-loop" (a while(1) that runs each job once, top to bottom, forever), a job that becomes ready just after it was checked must wait for the whole rest of the loop. So the worst wait is the sum of every job's worst-case run time: $L_{worst} = \sum_{i = 1}^{N} C_{i}$ Here $C_{i}$ = worst-case execution time (WCET) of job $i$ — see Worst-Case Execution Time (WCET). The $\sum$ symbol (a stretched "S" for "Sum") just means "add these up for $i = 1, 2, \dots, N$ ".

Tool 2 — Liu & Layland utilisation bound. For $n$ periodic tasks under Rate-Monotonic Scheduling, each task $i$ has a period $T_{i}$ (how often it repeats) and cost $C_{i}$ (how long it runs). The fraction of the CPU it eats is $C_{i} / T_{i}$ . Add them up to get total utilisation $U$ . The rule says the schedule is guaranteed safe if: $U = \sum_{i = 1}^{n} \frac{C _{i}}{T _{i}} \leq n (2^{1/ n} - 1)$ The right side is a "safety ceiling" that shrinks toward $ln 2 \approx 0.693$ as $n$ grows. If $U$ is under the ceiling → safe. If $U$ is over it → the test is inconclusive (maybe still schedulable, must check response times).

L1 — Recognition

Q1.1

"Real-time" means the system is fast. True or false — and give the one-word correction if false.

Recall Solution

False. Real-time means deterministic (bounded, predictable, on-time). A system that always answers in 50 ms is more real-time than one that usually takes 1 ms but sometimes 200 ms. Predictability beats raw speed.

Q1.2

Match each item to bare-metal or RTOS: (a) super-loop while(1), (b) per-task stacks, (c) mutexes and message queues, (d) "you own every timing decision".

Recall Solution

(a) super-loop → bare-metal
(b) per-task stacks → RTOS (each task needs its own stack)
(c) mutexes / queues → RTOS (synchronisation primitives)
(d) you own every timing decision → bare-metal

L2 — Application

Q2.1

A super-loop runs four jobs with WCETs $C = {2, 1, 30, 5}$ ms. A sensor job (the 2 ms one) needs servicing every 5 ms. Compute the worst-case latency the sensor can suffer, and state whether the 5 ms requirement is met.

Recall Solution

Use Tool 1: $L_{worst} = 2 + 1 + 30 + 5 = 38$ ms. The sensor can wait up to 38 ms — that badly misses its 5 ms requirement (by more than 7×). The 30 ms display job is the poison.

Q2.2

Compute total utilisation $U$ for three tasks $(C, T) = (1, 4), (1, 6), (2, 12)$ ms.

Recall Solution

$U = \frac{1}{4} + \frac{1}{6} + \frac{2}{12} = 0.25 + 0.1 \overline{6} + 0.1 \overline{6} = 0.583$

Q2.3

For $n = 3$ tasks, compute the Rate-Monotonic bound $n (2^{1/ n} - 1)$ . Does the task set from Q2.2 pass?

Recall Solution

$3 (2^{1/3} - 1) = 3 (1.2599 - 1) = 3 (0.2599) = 0.7798$ Since $U = 0.583 \leq 0.780$ , the set passes the sufficient test → all deadlines guaranteed. No need to compute exact response times.

L3 — Analysis

Q3.1

System: control loop every 1 ms ( $C = 0.2$ ms), Wi-Fi stack (blocking, up to 50 ms), UI redraw (up to 40 ms). (a) In a super-loop, what latency does the control loop see? (b) Under an RTOS with control at highest priority, what is its response time?

Figure — Bare-metal vs RTOS — when to use each

Recall Solution

(a) Super-loop — Tool 1: $L = 0.2 + 50 + 40 = 90.2$ ms. Against a 1 ms deadline this misses by ~90×. Fatal. (b) RTOS, control highest priority — nothing higher exists to pre-empt it, so from the response-time recurrence $R_{i} = C_{i} + \sum_{j \in h p (i)} ⌈ R_{i} / T_{j} ⌉ C_{j}$ the sum is empty, leaving $R = C = 0.2$ ms. It always meets 1 ms. Wi-Fi and UI run in leftover time. See Context Switching for the cost of the pre-emption itself.

Q3.2

Two tasks, $(C, T) = (2, 5)$ (high priority) and $(4, 12)$ (low priority) ms. Use the response-time recurrence to find the low task's response time $R_{2}$ . Start at $R_{2}^{(0)} = C_{2} = 4$ .

Recall Solution

Recurrence: $R_{2} = C_{2} + ⌈ R_{2} / T_{1} ⌉ C_{1} = 4 + ⌈ R_{2} /5 ⌉ \cdot 2$ . Iterate:

$R_{2}^{(0)} = 4 \Rightarrow ⌈ 4/5 ⌉ = 1 \Rightarrow R_{2}^{(1)} = 4 + 1 \cdot 2 = 6$
$R_{2}^{(1)} = 6 \Rightarrow ⌈ 6/5 ⌉ = 2 \Rightarrow R_{2}^{(2)} = 4 + 2 \cdot 2 = 8$
$R_{2}^{(2)} = 8 \Rightarrow ⌈ 8/5 ⌉ = 2 \Rightarrow R_{2}^{(3)} = 4 + 2 \cdot 2 = 8$ ✓ (stable)

$R_{2} = 8$ ms. Since $8 \leq T_{2} = 12$ , the low task meets its deadline even though the high task pre-empts it twice.

L4 — Synthesis

Q4.1

A thermostat: read temp every 1 s ( $C = 2$ ms), drive relay ( $C = 1$ ms), refresh LCD every 0.5 s ( $C = 30$ ms). Argue with numbers whether to choose bare-metal or RTOS.

Recall Solution

Super-loop worst case (Tool 1): $L = 2 + 1 + 30 = 33$ ms. The tightest deadline is the LCD at 500 ms and temp at 1000 ms — both are dozens of times larger than 33 ms. No timing conflict exists. Verdict: bare-metal. An RTOS would add RAM (kernel + stacks) and context-switch overhead for zero timing benefit.

Q4.2

Add a Wi-Fi telemetry stack ( $C$ bursty, up to 200 ms, blocking) to that thermostat, plus keep the 1 ms-critical safety cutoff that must fire within 2 ms of an over-temp interrupt. Re-decide, and say how you would structure the winning design.

Recall Solution

Now super-loop latency for the safety check $= 2 + 1 + 30 + 200 = 233$ ms $≫$ its 2 ms deadline → fails. Verdict: RTOS. Structure:

Safety cutoff → an ISR or highest-priority task (see Interrupts and ISRs); response $\approx C \approx$ sub-ms, always $\leq 2$ ms.
Control/relay/LCD → medium priority.
Wi-Fi (blocking) → lowest priority, runs in leftover time. Now the 200 ms Wi-Fi burst contributes nothing to the safety latency (only higher-priority work delays a task). Guard the whole thing with a watchdog.

L5 — Mastery

Q5.1

Four tasks $(C, T)$ in ms: $(1, 4), (2, 8), (1, 16), (3, 32)$ . (a) Compute $U$ . (b) Compute the RM bound for $n = 4$ . (c) Does it pass the sufficient test? (d) If a fifth task $(2, 10)$ is added, recompute $U$ and the $n = 5$ bound, and decide.

Recall Solution

(a) $U = \frac{1}{4} + \frac{2}{8} + \frac{1}{16} + \frac{3}{32} = 0.25 + 0.25 + 0.0625 + 0.09375 = 0.65625$ . (b) $4 (2^{1/4} - 1) = 4 (1.18921 - 1) = 4 (0.18921) = 0.75683$ . (c) $0.65625 \leq 0.75683$ → passes. Guaranteed schedulable under RM. (d) Add $(2, 10)$ : new $U = 0.65625 + 0.2 = 0.85625$ . New bound $5 (2^{1/5} - 1) = 5 (1.148698 - 1) = 5 (0.148698) = 0.74349$ . Now $0.85625 > 0.74349$ → the sufficient test fails (inconclusive). You cannot claim safety from utilisation alone; you must run the exact response-time analysis per task, or drop/merge a task.

Q5.2 (design justification)

You are told: "Use an RTOS everywhere — it's safer." Give a numeric counter-case where bare-metal is the correct engineering choice, and name the cost the RTOS-everywhere rule ignores.

Recall Solution

Counter-case: a coin-cell sensor node with two similar-rate jobs, $C = {1, 1}$ ms, deadlines of 1 s. Super-loop latency $= 2$ ms $≪ 1000$ ms → trivially met. An RTOS here adds kernel flash/RAM, per-task stacks, and context-switch energy on a device whose whole budget is a battery. The ignored cost is RAM/power/certification overhead plus added non-determinism in the kernel's worst case. Bare-metal wins. Recall the mnemonic SLAP — you only reach for an RTOS when Several tasks are Latency-critical with Async I/O and differing Priorities; this node SLAPs none of those. (See also Priority Inversion and Mutexes — a whole class of RTOS-only bugs you avoid entirely by staying bare-metal.)

Recall Feynman check — say the whole page in two sentences

Bare-metal makes every job wait for the sum of all jobs, so one slow job poisons the timing of a fast critical one. An RTOS lets high-priority work pre-empt low-priority work, so a critical task waits only for higher-priority jobs — you pay RAM, power and complexity for that isolation, and you only pay it when your jobs genuinely fight over timing.

Connections

Worst-Case Execution Time (WCET) — where every $C_{i}$ number comes from
Rate-Monotonic Scheduling — the priority rule behind the utilisation bound
Context Switching — the overhead an RTOS charges for pre-emption
Interrupts and ISRs — bare-metal's real-time lever
Watchdog Timers — the safety net for both worlds
Priority Inversion and Mutexes — RTOS-only hazard class