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

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

KYA. Kisi bhi maths se pehle, hardware ko picture karo. Ek hi CPU hai — ek worker jo ek waqt mein sirf ek kaam kar sakta hai. Hum usse kai jobs dete hain (inhe tasks bhi kehte hain): sensor padhna, screen refresh karna, wagera.

KYU. Is page ka har formula sirf is bottleneck ki wajah se exist karta hai. Agar har job ke liye ek CPU hota, toh koi scheduling problem nahi hoti aur yeh page bhi nahi hota. Poora subject yahi hai: ek worker ko bahut saari demands ke beech kaise share karein?

PICTURE. Ek chalk box = CPU. Kai chhote job-boxes se arrows uski taraf point karte hain. Sab ek saath andar nahi ja sakte — woh queue hi saari problem hai.

Step 2 — Super-loop: har dish finish karo, order mein, forever

KYA. Bare-metal firmware aam taur par ek endless loop jaisi dikhti hai jo har job ko completion tak chalati hai, fixed order mein, phir se shuru karti hai.

KYU. Yeh sabse simple cheez hai jo possibly kaam kar sakti hai: koi kernel nahi, koi scheduler nahi, chhoti memory. Tum ise upar se neeche padh sakte ho aur exactly jaante ho kya hoga.

PICTURE. Ek circular track. Chaar coloured tiles us par end-to-end rakhe hain — unki widths unke execution times $C_{i}$ hain. CPU ek chalk dot hai jo constant speed se ring ke around crawl karta hai, ek full lap = ek loop iteration.

Widths dekho: display tile (pink) bahut badi hai. CPU dot ko har single lap mein usse cross karna padta hai — yahan tak ki chhoti sensor tile ko bhi woh poora crossing wait karna padta hai.

Step 3 — Worst-case wait: ek job poochti hai, "bas miss ho gayi"

KYA. Hum ab super-loop ke liye killer number derive karte hain: worst-case latency $L_{worst}$ — ek job kitni der tak ready-but-unserved baith sakti hai.

KYU yahi exact scenario. "Worst case" paranoia nahi hai; ek real-time system apne worst moment se judge hota hai, kabhi average se nahi. Toh hum poochte hain: wait kab sabse lamba hota hai? Jawab: jab job ready ho jaaye uss waqt ke theek baad jab CPU ne use check kiya. Ab use poore baaki lap mein baithna padta hai CPU ke waapis aane se pehle.

PICTURE. Ek red "READY!" flag sensor tile par pop up hoti hai theek baad CPU dot usse nikal gaya. Red arc dikhata hai dot ko kitna aur travel karna hai — saare remaining tiles — waapis aane se pehle.

Worst case mein woh remaining arc almost poora loop hai, toh hum wait ko ek full loop se bound karte hain:

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

Step 4 — Pre-emption: "sab chhodo aur soup ABHI hilaao"

KYA. Ek RTOS ek superpower add karta hai: ek high-priority task ek low-priority task ko mid-execution interrupt (pre-empt) kar sakta hai, run kar sakta hai, phir control waapis de sakta hai. (Yeh mid-flight hand-off exactly Context Switching hai, aur interrupt trigger ek Interrupts and ISRs mechanism hai.)

KYU. Super-loop mein fast job ka wait slow jobs par depend karta tha. Pre-emption logic ko flip kar deta hai: ek job ab sirf usse zyada important jobs se delay hoti hai, kabhi kam important waalo se nahi.

PICTURE. Ek timeline. Low-priority UI task (pink bar) chal rahi hai. Beech mein, high-priority control task (blue) ready ho jaati hai — ek blue arrow pink bar mein slice karta hai, pink bar pause ho jaata hai, blue completion tak chalta hai, phir pink resume ho jaata hai. Blue task ne pink wale ka wait nahi kiya.

Step 5 — Interruptions count karna: ceiling kyun aata hai

KYA. Hum task $i$ ka response time $R_{i}$ chahte hain — "job $i$ ready hoi" se "job $i$ finish hoi" tak ka time. Task $i$ ko apne liye $C_{i}$ CPU chahiye, lekin us stretch mein higher-priority tasks baar baar ghus aate rehte hain. Hume count karna hai ki har kitni baar ghusta hai.

KYU ceiling function. Ek higher-priority task $j$ lo jiska period $T_{j}$ hai. $R_{i}$ ki window mein $j$ kitni baar aata hai? Woh shuruat mein ek baar aata hai, phir har $T_{j}$ pe. Agar $R_{i} = 10$ ms aur $T_{j} = 4$ ms, arrivals $t = 0, 4, 8$ par hoti hain — yeh 3 arrivals hain, 2.5 nahi. Aadhi arrival nahi ho sakti; ek partial period bhi ek poora interruption trigger karta hai. Agli poori whole number tak round up karna exactly "ceiling" operation hai.

PICTURE. $R_{i}$ length ki ek horizontal window. Har $T_{j}$ par tick marks task $j$ ke arrivals dikhate hain. Hum window ke andar ticks count karte hain; aakhri partial slot bhi ek poori tick manta hai — picture dikhati hai kyun hum up round karte hain, down nahi.

Ab response time assemble karo:

$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 — Saamp apni poonch kaata hai: $R_{i}$ ko iteration se solve karna

KYA. $R_{i}$ equation ke dono sides par aata hai (ceiling ke andar bhi). Tum bas "right side compute karo" nahi kar sakte — jawab laane ke liye jawab chahiye hoga. Toh hum ise repeating loop ki tarah solve karte hain.

KYU iterate karo. Ek guess se shuru karo jo obviously bahut chhota hai — task ka apna kaam akela, $R_{i}^{(0)} = C_{i}$ . Usse daalo, bada value milega (interruptions add hue), usse waapis daalo, aur aise chalte raho. Har round mein sirf interruptions add ho sakte hain, toh number badhta hai aur phir ruk jaata hai. Jab ruk jaaye, true $R_{i}$ mil jaata hai. (Agar woh deadline se pehle badhta rahe, task unschedulable hai.)

PICTURE. Ek staircase ek flat plateau ki taraf chadhti hai: $R^{(0)}, R^{(1)}, R^{(2)}, \dots$ har step pehle se uncha lekin kam-kam se, jab tak line flat nahi ho jaati — the fixed point.

Step 7 — "Sab fit bhi hoga kya?" — utilisation gate

KYA. Har $R_{i}$ compute karna kaam hai. Ek faster first screen hai: add karo ki har task CPU ko kitna busy rakhti hai aur ek bound se compare karo. Yeh Rate-Monotonic Scheduling ke liye Liu & Layland test hai.

KYU fraction $C_{i} / T_{i}$ . Ek task jo har $T_{i}$ ms mein $C_{i}$ ms CPU chahti hai, CPU ke time ka fraction $C_{i} / T_{i}$ occupy karti hai. Woh fractions sum karo aur tumhe total demand $U$ milega. Agar $U > 1$ toh tumne ek CPU ke 100% se zyada maanga hai — impossible, koi scheduler tumhe bachaa nahi sakta.

PICTURE. CPU time ke 100% ko represent karne wala ek bar, colored demand chunks $C_{i} / T_{i}$ se slice kiya hua stacked. Ek dashed chalk-yellow line guarantee bound mark karti hai; agar stack line ke neeche rahe, deadlines guaranteed hain.

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

Step 8 — Degenerate & edge cases (kabhi gap mat chhodo)

KYA. Woh corners jahan formulas kuch surprising karte hain. Har ek apna moment earn karta hai.

KYU. Ek reader jo unhandled corner hit karta hai, poora trust kho deta hai. Yeh rahe, exhaustively.

Sirf ek job (N = 1). Super-loop latency $L = C_{1}$ — job sirf apne aap ka wait karti hai. Response time $R_{1} = C_{1}$ . Bare-metal aur RTOS agree karte hain; RTOS sirf overhead add karta hai. → bare-metal jeetta hai.
Highest-priority task. $h p (i) = \emptyset$ (empty set), sum zero hai, $R_{i} = C_{i}$ . Yeh woh best case hai jo pre-emption de sakta hai — deliberately sabse critical job ke liye use kiya jaata hai.
Lowest-priority task. Sab $h p (i)$ mein hain; yeh saare interruptions absorb karta hai aur sabse bada $R_{i}$ rakhta hai. Apna non-urgent slow kaam yahan rakho.
$U = 1$ exactly. Utilisation test fail ho jaata hai (bound $< 1$ ), lekin system shayad abhi bhi schedulable ho — tumhe exact $R_{i}$ recurrence par fall back karna padega. Bound sufficient hai, necessary nahi.
$R_{i}$ kabhi rukta nahi (deadline $T_{i}$ se upar chadh jaata hai): task unschedulable hai — is scheme ke under koi priority ordering uski deadline meet nahi kar sakti. Redesign karo (faster hardware, lower demand, ya offload).
Do tasks ek resource share karte hain — ek low-priority task ek lock hold karte hue ek high-priority task ko stall kar sakta hai, "sirf higher priorities mujhe delay karti hain" rule tod ke. Woh leak Priority Inversion and Mutexes hai, alag se patch kiya jaata hai. Aur agar koi task bilkul hang ho jaaye, ek watchdog system reset kar deta hai.

Ek-picture summary

Do timelines, same teen jobs, comparison ke liye stacked. Upar (super-loop): fast control job (blue) fat Wi-Fi + UI blocks ke peeche fasi hai — uska wait poora loop hai, $\sum C_{i} = 90.2$ ms. Neeche (RTOS): control highest priority hai; ek blue spike fire hota hai jab bhi woh ready hoti hai, slow kaam ko slice karte hue, wait $= C = 0.2$ ms. Same hardware, same jobs — sirf sharing rule badla.

Recall Feynman retelling — poora walkthrough plain words mein

Ek cook, bahut saare dishes. Bare-metal cook har dish ko fully finish karta hai, fixed order mein, round and round. Agar chhota "soup hilaao" wala job ek urgent moment mein ready ho jaaye theek baad jab cook uske paas se guzra, use har doosri dish finish hone tak wait karna padta hai — woh total wait sirf saare dish sizes add karne jaisa hai, $\sum C_{i}$ . Ek giant dish (display, Wi-Fi) yahan tak ki sabse chhoti urgent job ko forever wait karwaati hai.

RTOS cook ek smart timer rakhta hai. Woh dishes ko importance se label karta hai. Jab ek important dish bulaye, woh jo bhi less important kaam kar raha hota hai use pause karta hai, urgent wala handle karta hai, phir resume karta hai. Toh ek urgent dish ab sirf un dishes ka wait karti hai jo isse zyada important hain — count karo ki woh kitni baar ghuste hain (upar round karke, kyunki half-visit bhi fully interrupt karta hai), unke sizes add karo, plus apna kaam: woh response time $R_{i}$ hai. Kyunki $R_{i}$ dono sides par dikha, tum guess-and-refine karo jab tak number rukta nahi.

Uss sab se pehle, ek quick sanity check: har dish ka "cook ke din ka fraction" ( $C_{i} / T_{i}$ ) add karo. Agar total ek safety line ke neeche rahe, har deadline guaranteed hai — detailed kaam ki zaroorat nahi.

Moral: apni ek urgent job ko top priority do aur RTOS uska wait "poore loop" se "sirf khud" tak shrink kar deta hai. Yahi poori wajah hai RTOSes exist karte hain.

Connections

Worst-Case Execution Time (WCET) — har $C_{i}$ kahaan se aata hai
Context Switching — pre-emption ke mid-flight pause/resume ke peeche ka mechanism
Interrupts and ISRs — jo actually pre-emption fire karta hai
Rate-Monotonic Scheduling — priority numbers kaise assign hote hain
Priority Inversion and Mutexes — "sirf higher priorities mujhe delay karti hain" rule mein leak
Watchdog Timers — safety net jab task hang ho jaaye