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

5.5.15 · D4 · Coding › Embedded Systems & Real-Time Software › Bare-metal vs RTOS — when to use each

Formula Do tools jo tum baar baar use karoge (zero se define kiye gaye)

Tool 1 — super-loop worst-case latency. Ek "super-loop" mein (ek while(1) jo har job ek baar, upar se neeche, hamesha ke liye run karta hai), ek job jo check hone ke ठीक baad ready ho jaata hai, usse poore baaki loop ka intezaar karna padta hai. Toh worst wait har job ke worst-case run time ka sum hota hai: $L_{worst} = \sum_{i = 1}^{N} C_{i}$ Yahan $C_{i}$ = worst-case execution time (WCET) of job $i$ — dekho Worst-Case Execution Time (WCET). $\sum$ symbol (ek bada "S" for "Sum") ka matlab bas itna hai ki "inhe $i = 1, 2, \dots, N$ ke liye jod do".

Tool 2 — Liu & Layland utilisation bound. $n$ periodic tasks ke liye Rate-Monotonic Scheduling ke under, har task $i$ ka ek period $T_{i}$ hota hai (yeh kitni baar repeat hota hai) aur cost $C_{i}$ (yeh kitni der tak chalta hai). CPU ka jo fraction yeh khata hai woh hai $C_{i} / T_{i}$ . Inhe jodkar total utilisation $U$ milta hai. Rule kehta hai schedule guaranteed safe hai agar: $U = \sum_{i = 1}^{n} \frac{C _{i}}{T _{i}} \leq n (2^{1/ n} - 1)$ Right side ek "safety ceiling" hai jo $n$ badhne ke saath $ln 2 \approx 0.693$ ki taraf ghatta hai. Agar $U$ ceiling ke neeche hai → safe. Agar $U$ uske upar hai → test inconclusive hai (ho sakta hai phir bhi schedulable ho, response times check karne padenge).

L1 — Recognition

Q1.1

"Real-time" ka matlab hai system fast hai. Sahi hai ya galat — aur agar galat hai toh ek-word correction do.

Recall Solution

Galat. Real-time ka matlab hai deterministic (bounded, predictable, on-time). Ek system jo hamesha 50 ms mein jawaab deta hai woh zyada real-time hai uss system se jo usually 1 ms leta hai par kabhi kabhi 200 ms. Predictability raw speed se zyada important hai.

Q1.2

Har item ko bare-metal ya RTOS se match karo: (a) super-loop while(1), (b) per-task stacks, (c) mutexes aur message queues, (d) "tum khud har timing decision ke malik ho".

Recall Solution

(a) super-loop → bare-metal
(b) per-task stacks → RTOS (har task ko apna stack chahiye)
(c) mutexes / queues → RTOS (synchronisation primitives)
(d) tum khud har timing decision ke malik ho → bare-metal

L2 — Application

Q2.1

Ek super-loop mein char jobs hain jinke WCETs $C = {2, 1, 30, 5}$ ms hain. Ek sensor job (woh 2 ms wala) ko har 5 ms mein service chahiye. Sensor ko jo worst-case latency ho sakti hai woh calculate karo, aur batao ki 5 ms requirement meet hoti hai ya nahi.

Recall Solution

Tool 1 use karo: $L_{worst} = 2 + 1 + 30 + 5 = 38$ ms. Sensor ko 38 ms tak wait karna pad sakta hai — yeh iske 5 ms requirement ko buri tarah se miss karta hai (7× se zyada). 30 ms display job zeher hai.

Q2.2

Teen tasks ke liye total utilisation $U$ compute karo $(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

$n = 3$ tasks ke liye Rate-Monotonic bound $n (2^{1/ n} - 1)$ compute karo. Kya Q2.2 ka task set pass karta hai?

Recall Solution

$3 (2^{1/3} - 1) = 3 (1.2599 - 1) = 3 (0.2599) = 0.7798$ Kyunki $U = 0.583 \leq 0.780$ hai, set sufficient test pass kar leta hai → saare deadlines guaranteed hain. Exact response times calculate karne ki zaroorat nahi.

L3 — Analysis

Q3.1

System: control loop har 1 ms ( $C = 0.2$ ms), Wi-Fi stack (blocking, up to 50 ms), UI redraw (up to 40 ms). (a) Super-loop mein control loop ko kitni latency milti hai? (b) Ek RTOS ke under jahan control highest priority par hai, iska response time kya hai?

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

Recall Solution

(a) Super-loop — Tool 1: $L = 0.2 + 50 + 40 = 90.2$ ms. 1 ms deadline ke against yeh ~90× miss karta hai. Fatal hai. (b) RTOS, control highest priority — isse pre-empt karne ke liye koi higher priority nahi hai, toh response-time recurrence $R_{i} = C_{i} + \sum_{j \in h p (i)} ⌈ R_{i} / T_{j} ⌉ C_{j}$ mein sum empty hai, aur $R = C = 0.2$ ms milta hai. Yeh hamesha 1 ms meet karta hai. Wi-Fi aur UI bacha hua time mein run karte hain. Pre-emption ki cost ke liye Context Switching dekho.

Q3.2

Do tasks, $(C, T) = (2, 5)$ (high priority) aur $(4, 12)$ (low priority) ms. Response-time recurrence use karke low task ka response time $R_{2}$ nikalo. $R_{2}^{(0)} = C_{2} = 4$ se shuru karo.

Recall Solution

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

$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. Kyunki $8 \leq T_{2} = 12$ hai, low task apna deadline meet karta hai even though high task ise do baar pre-empt karta hai.

L4 — Synthesis

Q4.1

Ek thermostat: har 1 s mein temp read karo ( $C = 2$ ms), relay drive karo ( $C = 1$ ms), har 0.5 s mein LCD refresh karo ( $C = 30$ ms). Numbers ke saath argue karo ki bare-metal choose karein ya RTOS.

Recall Solution

Super-loop worst case (Tool 1): $L = 2 + 1 + 30 = 33$ ms. Sabse tight deadline LCD ki 500 ms aur temp ki 1000 ms hai — dono 33 ms se kai zyada hain. Koi timing conflict exist nahi karta. Verdict: bare-metal. RTOS yahan RAM (kernel + stacks) aur context-switch overhead add karega zero timing benefit ke liye.

Q4.2

Us thermostat mein ek Wi-Fi telemetry stack add karo ( $C$ bursty, up to 200 ms, blocking), saath hi 1 ms-critical safety cutoff raho jo over-temp interrupt ke 2 ms ke andar fire hona chahiye. Dobara decide karo, aur batao ki winning design ko kaise structure karoge.

Recall Solution

Ab super-loop latency safety check ke liye $= 2 + 1 + 30 + 200 = 233$ ms $≫$ iske 2 ms deadline → fail. Verdict: RTOS. Structure:

Safety cutoff → ek ISR ya highest-priority task (dekho Interrupts and ISRs); response $\approx C \approx$ sub-ms, hamesha $\leq 2$ ms.
Control/relay/LCD → medium priority.
Wi-Fi (blocking) → lowest priority, bacha hua time mein run karta hai. Ab 200 ms Wi-Fi burst safety latency mein kuch contribute nahi karta (sirf higher-priority work ek task ko delay karta hai). Poori cheez ko ek watchdog se guard karo.

L5 — Mastery

Q5.1

Chaar tasks $(C, T)$ ms mein: $(1, 4), (2, 8), (1, 16), (3, 32)$ . (a) $U$ compute karo. (b) $n = 4$ ke liye RM bound compute karo. (c) Kya yeh sufficient test pass karta hai? (d) Agar paanchwa task $(2, 10)$ add ho jaaye, $U$ aur $n = 5$ bound dobara compute karo aur decide karo.

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. RM ke under guaranteed schedulable hai. (d) $(2, 10)$ add karo: naya $U = 0.65625 + 0.2 = 0.85625$ . Naya bound $5 (2^{1/5} - 1) = 5 (1.148698 - 1) = 5 (0.148698) = 0.74349$ . Ab $0.85625 > 0.74349$ → sufficient test fail ho gaya (inconclusive). Sirf utilisation se safety claim nahi kar sakte; tumhe har task ke liye exact response-time analysis run karni hogi, ya koi task drop/merge karna hoga.

Q5.2 (design justification)

Tumhe bola gaya: "Har jagah RTOS use karo — yeh safer hai." Ek numeric counter-case do jahan bare-metal sahi engineering choice hai, aur woh cost batao jo RTOS-everywhere rule ignore karta hai.

Recall Solution

Counter-case: ek coin-cell sensor node jisme do similar-rate jobs hain, $C = {1, 1}$ ms, deadlines of 1 s. Super-loop latency $= 2$ ms $≪ 1000$ ms → trivially met. RTOS yahan kernel flash/RAM, per-task stacks, aur context-switch energy add karega ek aisi device par jinका poora budget ek battery hai. Jo cost ignore ki ja rahi hai woh hai RAM/power/certification overhead aur kernel ke worst case mein added non-determinism. Bare-metal wins. Mnemonic SLAP yaad karo — RTOS tabhi lo jab Several tasks Latency-critical hon with Async I/O aur differing Priorities; yeh node SLAP ka koi criteria meet nahi karta. (Dekho bhi Priority Inversion and Mutexes — RTOS-only bugs ki ek poori class jisse tum bare-metal par rehkar bilkul bachte ho.)

Recall Feynman check — poora page do sentences mein bolo

Bare-metal mein har job saari jobs ke sum ka intezaar karti hai, isliye ek slow job ek fast critical job ki timing kharaab kar deta hai. Ek RTOS high-priority work ko low-priority work ko pre-empt karne deta hai, isliye ek critical task sirf higher-priority jobs ka intezaar karta hai — tum RAM, power aur complexity us isolation ke liye pay karte ho, aur sirf tabhi pay karte ho jab tumhare jobs genuinely timing ke liye ladte hain.

Connections

Worst-Case Execution Time (WCET) — jahan har $C_{i}$ number aata hai
Rate-Monotonic Scheduling — utilisation bound ke peeche ki priority rule
Context Switching — woh overhead jo ek RTOS pre-emption ke liye charge karta hai
Interrupts and ISRs — bare-metal ka real-time lever
Watchdog Timers — dono worlds ke liye safety net
Priority Inversion and Mutexes — RTOS-only hazard class