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

Before you can read the parent note Bare-metal vs RTOS, you must be able to see every word it uses. This page builds each one from nothing.

1. The CPU — one worker, one thing at a time

The whole topic exists because of this bottleneck. If you had one CPU per job, there would be no scheduling problem at all. You don't — so you must interleave.

Look at the figure: the horizontal axis is time flowing left to right. The CPU is a single lane. Three jobs (blue, yellow, green) all want that lane, but only one coloured block can occupy the lane at any vertical slice of time. That is what "one CPU" forces on us.

Why do we need this picture first? Because every later symbol — how long a job runs, how long it waits — is measured along this time axis.

2. A "job" / "task" — one unit of work

Picture: each coloured block in Figure 1 is one job running. Its width is how long it takes; its left edge is when it started.

The parent note lists example jobs like read_sensor(), update_display(). Each is a job. We need this word because scheduling is nothing but deciding which job's block goes where on the time axis.

3. $C$ — execution time (how wide a block is)

Picture: $C_i$ is literally the width of block $i$ in Figure 1. A fat block = big $C$. The parent's update_display() ~30 ms is a very fat block; update_control() ~1 ms is a thin sliver.

Why the topic needs it: the super-loop's killer formula $L_{\text{worst}}=\sum C_i$ is just adding up all the block widths. You cannot read that formula without knowing what a single width means.

4. The subscript $i$ and the sum $\sum$ — "add up over all jobs"

Picture: line all four blocks up with no gaps — the total length of that train is the sum. That is why every job waits for every other job: to get its next turn, it must wait for the whole train to pass.

5. $T$ — period (how often a job must run)

Picture (Figure 2): the coloured arrows mark the start of each period — the moments a job "becomes ready" and wants CPU time. A job with a short period has arrows packed close together; a long period spreads them far apart. The gap between two arrows is $T$.

Why the topic needs it: the difference between bare-metal and RTOS only matters when jobs have very different periods (a fast $5$ ms job stuck behind a slow $30$ ms job). $T$ is the number that captures "how different".

6. Deadline & latency — the waiting that hurts

Picture: in Figure 2, imagine the blue arrow (job becomes ready) but the CPU is busy with a yellow block. The red bracket from arrow to the start of the blue block is the latency. Wide bracket = danger.

Why the topic needs it: the whole bare-metal-vs-RTOS argument is "which approach keeps the red bracket small for my urgent jobs?" The super-loop's worst-case latency is $\sum C_i$; the RTOS's is much smaller for high-priority jobs — that's the punchline.

7. Priority & pre-emption — letting urgent jobs cut the line

Picture (Figure 3): top row = super-loop — the green urgent job's arrow arrives while the fat yellow block runs, and green must wait for yellow to fully finish (long red wait). Bottom row = pre-emptive RTOS — the same green arrow arrives, yellow is instantly split in two and green runs immediately (tiny red wait). The split yellow block is pre-emption made visible.

Why the topic needs it: this single picture is the reason RTOSes exist. The related theory of which jobs get which priority is Rate-Monotonic Scheduling, and the subtle bug where a low task blocks a high one is Priority Inversion and Mutexes.

8. $hp(i)$, ceilings, and the response-time recurrence

Why we need this: it is the RTOS counterpart of $L=\sum C_i$. It shows mathematically that slow low-priority jobs (not in $hp(i)$) add nothing to the urgent task's response time — the entire selling point of an RTOS.

9. $U$ — utilisation, "how full is the CPU?"

Picture (Figure 4): a single bar = 100% of the CPU. Each job fills a slice $C_i/T_i$ of it. The parent's example $(1,4),(1,6),(2,12)$ fills $0.25+0.167+0.167=0.583$ of the bar — the rest is idle head-room. The dashed line at $0.780$ is the Liu & Layland safety limit: stay under it and every deadline is guaranteed.

Prerequisite map

Equipment checklist

You are ready for the parent note when you can answer each of these out loud:

Connections

• Interrupts and ISRs — the hardware "cut the line" mechanism behind pre-emption
• Context Switching — the machinery that pauses and resumes a task
• Rate-Monotonic Scheduling — how priorities are assigned from periods
• Priority Inversion and Mutexes — when priority ordering goes wrong
• Worst-Case Execution Time (WCET) — where the $C_i$ numbers come from
• Parent topic