Bare-metal vs RTOS — when to use each — Coding notes

WHAT are we even comparing?

WHY does the choice matter? (first principles)

You have one CPU and N jobs, each with its own period and deadline. The CPU can only do one thing at a time, so you must interleave the jobs. Two philosophies:

1. The super-loop (bare-metal)

while (1) {
    read_sensor();     // ~2 ms
    update_control();  // ~1 ms
    update_display();  // ~30 ms  <-- the troublemaker
    handle_uart();     // ~5 ms
}

WHY this works: simple, no kernel, tiny RAM/flash. WHY it breaks at scale: the worst-case loop time is the sum of every job. If update_display() takes 30 ms, your sensor can be starved for up to ~38 ms even if it needed servicing every 5 ms. The slowest job poisons everyone.

2. Pre-emptive scheduling (RTOS)

The RTOS lets a high-priority task interrupt (pre-empt) a low-priority one mid-execution. Now a job's latency depends only on higher-priority work, not on slow low-priority work.

Formula Response time under fixed-priority pre-emption (RTA)

For task $i$ (lower number = higher priority), its response time $R_i$ is the solution to the recurrence: $R_i \;=\; C_i \;+\; \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j$ WHY this shape? While task $i$ runs (needing $C_i$ ), every higher-priority task $j$ can pre-empt it once per its period $T_j$ . Over a window of length $R_i$ , task $j$ arrives $\lceil R_i/T_j\rceil$ times, each costing $C_j$ . We iterate (start $R_i^{(0)}=C_i$ ) until it stops growing. The point: the slow update_display (a low priority task) now contributes nothing to the sensor's latency. That's the magic an RTOS buys.

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

HOW to decide — the 80/20 rule of thumb

Use bare-metal when…	Use an RTOS when…
Tiny MCU, few KB RAM	More RAM (RTOS kernel + per-task stacks cost RAM)
1–4 simple, similar-rate jobs	Many tasks with different periods/priorities
Hard determinism via ISRs is enough	Need clean concurrency + blocking calls
Lowest power / cost / certification simplicity	Networking (TCP/IP), filesystems, USB stacks
You want to understand every cycle	You want to scale features without rewriting scheduling

Recall Feynman: explain it to a 12-year-old (click to reveal)

Imagine one cook (the CPU) and several dishes (jobs). Bare-metal is a cook who finishes each dish completely, in a fixed order, again and again. Easy to follow — but if one dish takes ages, the soup that needs constant stirring burns. RTOS is a cook with a smart timer: "Drop everything and stir the soup right now — it's urgent!" He can pause a slow dish, handle the urgent one, then come back. He's a bit slower overall (he wastes a few seconds switching tasks), but nothing important ever burns. You hire the smart cook only when you have urgent + slow dishes fighting for attention.

Flashcards

What does "real-time" actually mean?

Deterministic / bounded, predictable timing that meets deadlines — NOT raw speed.

What is the worst-case latency of a job in a super-loop?

The sum of worst-case execution times of ALL jobs,

L=\sum C_i

— every job waits for every other job.

Why does an RTOS reduce a critical task's latency?

Pre-emption: only higher-priority tasks delay it; slow low-priority jobs contribute nothing.

Write the response-time recurrence for fixed-priority pre-emption.

R_i = C_i + \sum_{j\in hp(i)} \lceil R_i/T_j\rceil C_j

, solved iteratively.

State the Liu & Layland utilisation bound for Rate-Monotonic.

U=\sum C_i/T_i \le n(2^{1/n}-1)

; limit

\ln 2 \approx 0.693

Name three costs an RTOS adds over bare-metal.

RAM (kernel + per-task stacks), context-switch overhead, and added complexity/non-determinism in worst case.

The 80/20 question for choosing an RTOS?

"Do my jobs have conflicting timing requirements?" If yes → RTOS; if no → bare-metal.

Mnemonic for when to use an RTOS?

SLAP — Several tasks, Latency-critical, Async/blocking I/O, Priorities differ.

In a super-loop, why does a slow display job hurt the sensor?

The sensor is only serviced once per loop, so it waits up to the full loop time, which includes the slow display.

What primitives does an RTOS give you for concurrency?

Tasks/threads, scheduler, semaphores, mutexes, message queues, timers.

Connections

Interrupts and ISRs — bare-metal's way to get "real-time" without a scheduler
Rate-Monotonic Scheduling — the priority-assignment theory behind the RTOS column
Priority Inversion and Mutexes — a classic RTOS pitfall (Mars Pathfinder)
Context Switching — the overhead an RTOS pays to share the CPU
Watchdog Timers — safety net in both paradigms
Worst-Case Execution Time (WCET) — the $C_i$ feeding every formula above

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, embedded system mein ek hi CPU hota hai aur kaam (jobs) bahut saare. Sawaal sirf itna hai: CPU ko in kaamo mein kaise baanto? Bare-metal matlab tum ek bada while(1) loop likhte ho jisme har kaam baari-baari chalta hai. Simple hai, RAM kam lagti hai, har clock cycle tumhare control mein hai. Problem yeh hai ki agar ek kaam (jaise display update) 30 ms le leta hai, toh tumhara critical sensor 30 ms tak wait karega — kyunki loop mein worst case latency saare kaamo ke time ka sum hota hai. Ek slow kaam sabko zeher kar deta hai.

RTOS ek chhota scheduler program hai jo CPU ko tumhare liye baant deta hai. Iska sabse bada superpower hai pre-emption — high-priority task beech mein ghuskar low-priority task ko rok deta hai. Isliye tumhare critical sensor ki latency sirf usse zyada priority wale kaamo par depend karti hai, slow display ka usme koi contribution nahi. Yaad rakho: "real-time" ka matlab fast nahi, balki predictable / on-time hota hai. 50 ms mein hamesha jawaab dena, 1 ms mein kabhi-kabhi jawaab dene se behtar hai.

Decision kaise lein? 80/20 rule: ek sawaal pucho — "Kya mere jobs ki timing requirements aapas mein conflict karti hain?" Agar nahi (thode se simple, similar-speed kaam) toh bare-metal kaafi hai. Agar haan (ek fast critical loop ko ek slow networking/UI kaam delay kar raha hai) toh RTOS lo. Mnemonic yaad rakho SLAP — Several tasks, Latency-critical, Async/blocking I/O, Priorities differ — yeh char ho toh RTOS uthao.

Aur ek schedulability check bhi hai: Rate-Monotonic ke liye agar utilisation $U = \sum C_i/T_i \le n(2^{1/n}-1)$ hai, toh RTOS guarantee deta hai ki saare deadlines miss nahi honge. Yeh formula tumhe pehle hi bata deta hai ki tumhare tasks CPU mein fit honge ya nahi.

Bare-metal vs RTOS — when to use each

WHAT are we even comparing?

WHY does the choice matter? (first principles)

1. The super-loop (bare-metal)

2. Pre-emptive scheduling (RTOS)

HOW to decide — the 80/20 rule of thumb

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Embedded Systems & Real-Time Software

Connections