Bare-metal vs RTOS — when to use each: Visual walkthrough

WHAT. Before any maths, picture the hardware. There is exactly one CPU — one worker who can do exactly one thing at a time. We hand it several jobs (also called tasks): reading a sensor, refreshing a screen, and so on.

WHY. Every formula on this page exists only because of this bottleneck. If we had one CPU per job, there would be no scheduling problem and no page. The whole subject is: how do we share one worker among many demands?

PICTURE. One chalk box = the CPU. Arrows from many little job-boxes point into it. They cannot all enter at once — that queue is the entire problem.

Step 2 — The super-loop: finish every dish, in order, forever

WHAT. Bare-metal firmware usually looks like one endless loop that runs each job to completion, in a fixed order, then starts over.

WHY. It is the simplest thing that could possibly work: no kernel, no scheduler, tiny memory. You can read it top to bottom and know exactly what happens.

PICTURE. A circular track. Four coloured tiles sit on it end-to-end — their widths are their execution times $C_{i}$ . The CPU is a chalk dot that crawls around the ring at constant speed, one full lap = one loop iteration.

Look at the widths: the display tile (pink) is huge. The CPU dot must travel across it every single lap — even the tiny sensor tile has to wait for that whole crossing.

Step 3 — The worst-case wait: a job asks, "just missed me"

WHAT. We now derive the killer number for the super-loop: the worst-case latency $L_{worst}$ — the longest a job can sit ready-but-unserved.

WHY this exact scenario. "Worst case" is not paranoia; a real-time system is judged by its worst moment, never its average. So we ask: when is the wait longest? Answer: when the job becomes ready the instant after the CPU just checked it. Now it must sit through the entire rest of the lap before the CPU comes around again.

PICTURE. A red "READY!" flag pops up on the sensor tile just after the CPU dot has left it. The red arc shows how far the dot must still travel — all the remaining tiles — before it returns.

In the worst case that remaining arc is almost the whole loop, so we bound the wait by one full loop:

$L_{worst} = add up i = 1 \sum N each job’s worst time C_{i}$

Step 4 — Pre-emption: "drop everything and stir the soup NOW"

WHAT. An RTOS adds one superpower: a high-priority task may interrupt (pre-empt) a low-priority task mid-execution, run, then hand control back. (This mid-flight hand-off is exactly Context Switching, and the interrupt trigger is an Interrupts and ISRs mechanism.)

WHY. In the super-loop the fast job's wait depended on slow jobs. Pre-emption flips the logic: a job is now delayed only by jobs more important than itself, never by less important ones.

PICTURE. A timeline. The low-priority UI task (pink bar) is running. Halfway through, the high-priority control task (blue) becomes ready — a blue arrow slices into the pink bar, the pink bar pauses, blue runs to completion, then pink resumes. The blue task did not wait for the pink one.

Step 5 — Counting the interruptions: why a ceiling appears

WHAT. We want task $i$ 's response time $R_{i}$ — the time from "job $i$ becomes ready" to "job $i$ finishes." Task $i$ needs $C_{i}$ of CPU for itself, but during that stretch, higher-priority tasks keep barging in. We must count how many times each barges in.

WHY a ceiling function. Take a higher-priority task $j$ with period $T_{j}$ . Over a window of length $R_{i}$ , how many times does $j$ arrive? It arrives once at the start, then again every $T_{j}$ . If $R_{i} = 10$ ms and $T_{j} = 4$ ms, arrivals land at $t = 0, 4, 8$ — that is 3 arrivals, not 2.5. You cannot have half an arrival; a partial period still triggers one more full interruption. Rounding up to the next whole number is exactly the "ceiling" operation.

PICTURE. A horizontal window of length $R_{i}$ . Tick marks every $T_{j}$ show task $j$ 's arrivals. We count the ticks inside the window; the last partial slot still counts as one whole tick — the picture shows why we round up, not down.

Now assemble the response time:

$R_{i} = my own work C_{i} + \sum_{j \in h p (i)} how many times j interrupts ⌈ \frac{R _{i}}{T _{j}} ⌉ cost of each j interruption C_{j}$

Step 6 — The snake bites its tail: solving $R_{i}$ by iteration

WHAT. $R_{i}$ appears on both sides of the equation (inside the ceiling too). You cannot just "compute the right side" — you would need the answer to get the answer. So we solve it as a repeating loop.

WHY iterate. Start with a guess that is obviously too small — the task's own work alone, $R_{i}^{(0)} = C_{i}$ . Feed it in, get a bigger value (interruptions added), feed that back in, and so on. Each round can only add more interruptions, so the number grows and then stalls. When it stops changing, we have found the true $R_{i}$ . (If it grows past the deadline first, the task is unschedulable.)

PICTURE. A staircase climbing to a flat plateau: $R^{(0)}, R^{(1)}, R^{(2)}, \dots$ each step taller than the last but by less each time, until the line goes flat — the fixed point.

Step 7 — "Will it all even fit?" — the utilisation gate

WHAT. Computing every $R_{i}$ is work. There is a faster first screen: add up how busy each task keeps the CPU and compare to a bound. This is the Liu & Layland test for Rate-Monotonic Scheduling.

WHY a fraction $C_{i} / T_{i}$ . A task that needs $C_{i}$ ms of CPU every $T_{i}$ ms occupies the fraction $C_{i} / T_{i}$ of the CPU's time. Sum those fractions and you get total demand $U$ . If $U > 1$ you have asked for more than 100% of one CPU — impossible, no scheduler saves you.

PICTURE. A bar representing 100% of CPU time, sliced into coloured demand chunks $C_{i} / T_{i}$ stacked up. A dashed chalk-yellow line marks the guarantee bound; if the stack stays under the line, deadlines are guaranteed.

$U = \sum_{i = 1}^{n} \frac{C _{i}}{T _{i}} \leq guarantee bound n (2^{1/ n} - 1)$

Step 8 — Degenerate & edge cases (never leave a gap)

WHAT. Corners where the formulas do something surprising. Each earns its own moment.

WHY. A reader who hits an unhandled corner loses all trust. Here they are, exhaustively.

Only one job (N = 1). Super-loop latency $L = C_{1}$ — the job waits for nobody but itself. Response time $R_{1} = C_{1}$ . Bare-metal and RTOS agree; the RTOS adds only overhead. → bare-metal wins.
Highest-priority task. $h p (i) = \emptyset$ (empty set), sum is zero, $R_{i} = C_{i}$ . This is the best case pre-emption can give — used deliberately for the most critical job.
Lowest-priority task. Everyone is in $h p (i)$ ; it absorbs all interruptions and has the largest $R_{i}$ . Put your non-urgent slow work here.
$U = 1$ exactly. The utilisation test fails (bound $< 1$ ), but the system might still be schedulable — you must fall back to the exact $R_{i}$ recurrence. The bound is sufficient, not necessary.
$R_{i}$ never stops growing (climbs past the deadline $T_{i}$ ): the task is unschedulable — no priority ordering under this scheme meets its deadline. Redesign (faster hardware, lower demand, or offload).
Two tasks share a resource — a low-priority task holding a lock can stall a high-priority one, breaking the "only higher priorities delay me" rule. That leak is Priority Inversion and Mutexes, patched separately. And if a task hangs entirely, a watchdog resets the system.

The one-picture summary

Two timelines, same three jobs, stacked for comparison. Top (super-loop): the fast control job (blue) is stuck behind the fat Wi-Fi + UI blocks — its wait is the whole loop, $\sum C_{i} = 90.2$ ms. Bottom (RTOS): control is highest priority; a blue spike fires instantly whenever it is ready, slicing through the slow work, wait $= C = 0.2$ ms. Same hardware, same jobs — only the sharing rule changed.

Recall Feynman retelling — the whole walkthrough in plain words

One cook, many dishes. Bare-metal cook finishes each dish fully, in a fixed order, round and round. If the tiny "stir the soup" job becomes urgent right after the cook walked past it, it must wait for every other dish to finish first — that total wait is just adding up all the dish sizes, $\sum C_{i}$ . One giant dish (the display, the Wi-Fi) makes even the tiniest urgent job wait forever.

RTOS cook carries a smart timer. He labels dishes by importance. When an important dish calls, he pauses whatever less important thing he's doing, handles the urgent one, then resumes. So an urgent dish now only ever waits for dishes more important than itself — count how many times those barge in (rounding up, because a half-visit still fully interrupts you), add their sizes, plus your own work: that's the response time $R_{i}$ . Since $R_{i}$ shows up on both sides, you guess-and-refine until the number stops moving.

Before doing any of that, a quick sanity check: add up each dish's "fraction of the cook's day" ( $C_{i} / T_{i}$ ). If the total sits under a safety line, every deadline is guaranteed — no detailed work needed.

The moral: give your one urgent job the top priority and an RTOS makes its wait shrink from "the whole loop" to "just itself." That is the entire reason RTOSes exist.

Connections

Worst-Case Execution Time (WCET) — where each $C_{i}$ comes from
Context Switching — the mechanism behind pre-emption's mid-flight pause/resume
Interrupts and ISRs — what actually fires the pre-emption
Rate-Monotonic Scheduling — how the priority numbers get assigned
Priority Inversion and Mutexes — the leak in the "only higher priorities delay me" rule
Watchdog Timers — the safety net when a task hangs