Bare-metal vs RTOS — when to use each: Question bank

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

Traps se pehle, teen tools jo hum baar baar use karte hain. Inhe pehle padho taaki baad mein koi symbol surprise na kare.

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

Upar ki teen strips har neeche wale trap ka mental model hain: top = super-loop (waits add up hoti hain), middle = RTOS pre-emption (urgent task cut in karta hai), bottom = priority inversion (ek lock urgent task ko trap karta hai).

True or false — justify

Real-time matlab system fast hai.

False. Real-time matlab deterministic — bounded, predictable timing jo deadlines meet kare. Ek system jo hamesha 50 ms mein answer karta hai woh ek aise system se zyada real-time hai jo usually 1 ms mein answer karta hai lekin kabhi kabhi 200 ms leta hai.

Ek RTOS tumhara firmware bare-metal se faster chalata hai.

False, usually average par slower — Context Switching aur kernel bookkeeping cycles cost karta hai. RTOS jo deta hai woh hai critical tasks ke liye predictable latency, throughput nahi.

Bare-metal ke paas ek urgent event par jaldi respond karne ka koi tarika nahi hai.

False. ISRs bare-metal ko time-critical events ke liye hardware-level pre-emption dete hain — isi tarah ek super-loop bina scheduler ke "real-time" rehta hai.

Super-loop mein, ek slow job sirf khud ko hurt karta hai.

False. Har job ek baar per loop service hoti hai, isliye kisi bhi job ka worst-case wait saari jobs ke execution times ka sum hota hai — sabse slow job sab ko poison karta hai (figure ki top strip).

RTOS pre-emptive scheduling ke under, ek slow low-priority task ek high-priority task ko delay kar sakta hai.

Mostly false — yahi toh pura point hai (middle strip). Ek high-priority task ka response time

R_{i}

sirf higher-priority work

h p (i)

par depend karta hai. Exception hai priority inversion, jahan ek shared lock ek low task ko ek high task block karne deta hai.

Agar CPU utilisation

U < 1

ho, toh Rate-Monotonic ke under saari deadlines guaranteed hain.

False. Kyunki

U = \sum C_{i} / T_{i}

, toh Liu & Layland bound hai

U \leq n (2^{1/ n} - 1) \to ln 2 \approx 0.693

, jo 1 se neeche hai. Bound se upar test inconclusive hai, necessarily infeasible nahi.

Liu & Layland utilisation test exact hai: agar yeh fail kare, toh task set unschedulable hai.

False. Yeh sufficient hai, necessary nahi. Iska fail hona matlab hai "exact response-time recurrence

R_{i} = C_{i} + \sum_{j \in h p (i)} ⌈ R_{i} / T_{j} ⌉ C_{j}

chalao" — set phir bhi deadlines meet kar sakta hai.

RTOS add karna hamesha timing behaviour improve karta hai.

False. Agar jobs kam aur similar-rate hain, toh RTOS RAM, context-switch jitter, aur non-determinism zero timing benefit ke liye add karta hai — wahan ek super-loop zyada predictable hoti hai.

Ek watchdog timer sirf RTOS systems par chahiye hota hai.

False. Dono ko chahiye; ek stuck super-loop ya ek deadlocked task dono forever hang karte hain, aur sirf ek independent watchdog MCU ko reset kar sakta hai.

RTOS mein same priority ke do tasks ek doosre ko pre-empt kar sakte hain.

False. Equal-priority tasks ek doosre ko pre-empt nahi karte; woh ya toh blocking point tak run karte hain ya cooperatively time-slice karte hain — pre-emption strictly higher ka lower par hota hai.

Spot the error

"Hamara control loop apni deadline miss kar raha hai, toh hum display code speed up karenge."

Galat lever. Super-loop mein fix architectural hai (RTOS ke under pre-empt karo ya display ko lower priority par move karo), ek already-slow job se kuch ms shave karna nahi.

"Humne RTOS choose kiya, toh hume ab WCET ke baare mein sochne ki zaroorat nahi."

Galat. Har schedulability test — utilisation bound aur response-time recurrence — built hai WCET numbers (

C_{i}

) par. Ek RTOS ko inki zyada zaroorat hai, kam nahi.

"Har task ko highest priority do taaki koi deadline miss na ho."

Agar sab top priority par hain, toh kuch bhi nahi hai — tumne extra overhead ke saath ek run-to-completion queue recreate kar li. Priorities tabhi help karti hain jab woh urgency ke hisaab se differ karein.

"Humne mutex use kiya, toh priority inversion nahi ho sakti."

Ulta hai — mutex hi woh cheez hai jo inversion create karti hai (ek low task woh lock hold karta hai jise ek high task ko chahiye, bottom strip). Fix hai mutex with priority inheritance, dekho Priority Inversion and Mutexes.

"Hamara ISR heavy sensor processing karta hai taaki main loop free rahe."

Long ISRs saare lower-or-equal interrupts block karte hain aur system ko starve karte hain. ISRs short hone chahiye — ek flag set karo/event queue karo aur return karo; kaam loop ya ek task mein karo.

"Utilisation 0.9 hai, 1.0 se kaafi kam, toh hum Rate-Monotonic ke under safe hain."

U = 0.9

~0.693 RM bound se upar hai, toh simple test kehta hai "unknown," na ki "safe." Tumhe exact response-time analysis chalani chahiye.

"RTOS har task ko uski apni CPU deta hai."

Sirf illusion deta hai ek ki. Abhi bhi ek single CPU hai jo scheduler dwara time-sliced hai; total work

U

abhi bhi feasible honi chahiye warna deadlines miss hongi.

Why questions

Super-loop worst-case latency mein sum

\sum C_{i}

kyun use hota hai, max nahi?

Kyunki ek job jo apna check abhi miss kar gayi use loop mein har doosri job ke khatam hone ka wait karna hoga apni baari se pehle — waits accumulate hoti hain, isliye add hoti hain (figure ki top strip).

Response-time recurrence mein ceiling

⌈ R_{i} / T_{j} ⌉

kyun use hoti hai?

Kyunki period

T_{j}

wala ek higher-priority task

j

ek puri extra baar fire kar sakta hai chahe window

R_{i}

mein uske period ka sirf ek fraction fit ho — tum "aadhi" arrival pre-empt nahi kar sakte, isliye round up karo.

Liu & Layland bound 1 se kam kyun hai (hum CPU ka 100% kyun nahi use kar sakte)?

Kyunki task periods perfectly align nahi hote; harmonic mismatch woh gaps chhodta hai jinhe tum safely fill nahi kar sakte aur phir bhi fixed-priority rule ke under deadlines guarantee kar sako.

Ek RTOS bare-metal se zyada RAM kyun cost karta hai?

Har task ka apna stack chahiye taaki ise pause aur resume kiya ja sake, saath hi kernel ke apne data structures — bare-metal mein ek hi stack hota hai.

Real-time systems mein raw speed se zyada predictability kyun value ki jaati hai?

Ek airbag ya motor controller mein missed deadline ek failure hai chahe average speed kuch bhi ho; ek slower-but-bounded system correct hai, ek faster-but-occasionally-late system broken hai.

Bare-metal design mein RTOS ki jagah sirf zyada ISRs kyun nahi add kar sakte?

ISRs ek interrupt-priority hierarchy share karte hain aur short rehne chahiye; heavy concurrent, blocking, ya many-priority kaam us model ko overwhelm karta hai — yahi exactly woh boundary hai jahan ek RTOS apna kaam karta hai.

Context-switch overhead RTOS ko worst case mein kam deterministic kyun banata hai?

Har switch variable number of cycles cost karta hai (cache/pipeline effects), jitter add karta hai jo ek straight-line super-loop mein simply nahi hoti.

Edge cases

Super-loop mein kya hota hai agar ek job infinite wait mein enter kar jaye (e.g. blocking I/O)?

Poora loop hang ho jaata hai — koi scheduler nahi hai jo switch away kare — toh har job stall ho jaati hai; sirf ek ISR ya watchdog system ko bacha sakta hai.

Ek task set ki utilisation exactly bound par hai,

U = n (2^{1/ n} - 1)

. Schedulable hai?

Haan — bound inclusive hai (

\leq

), isliye equality sufficient test pass karta hai aur RM saari deadlines guarantee karta hai.

MCU par sirf ek job hai. Bare-metal ya RTOS?

Bare-metal — ek single job ke saath schedule karne ke liye kuch nahi hai; RTOS zero concurrency benefit ke liye pure overhead hoga.

Saare tasks perfectly harmonic hain (periods integer multiples hain). Kya 0.693 limit abhi bhi apply hoti hai?

Nahi — harmonic period sets ke liye RM utilisation bound 1.0 tak badh jaati hai, toh tum CPU ko safely fully load kar sakte ho; pessimistic 0.693 arbitrary periods par worst-case hai.

Do equally urgent tasks dono ko "immediate" response chahiye. Kya ek RTOS dono ko ek saath satisfy kar sakta hai?

Koi bhi scheduler nahi kar sakta — ek CPU ek time par ek task serve karta hai. Agar dono ko simultaneously zero latency chahiye, tumhe zyada hardware chahiye (ek second core/MCU ya dedicated ISR), cleverer scheduler nahi.

Ek high-priority task ek lock par block karta hai jo ek low-priority task ke paas hai jo kabhi run hi nahi kar paata. Failure aur fix kya hai?

Unbounded priority inversion; fix karo priority inheritance se (temporarily lock holder ko boost karo) ya priority ceiling se.

Utilisation bound se kaafi neeche hai lekin ek task ka WCET galat hai (underestimated). Consequence kya hoga?

Guarantee void hai — schedulability poori tarah correct WCET (

C_{i}

) par resti hai; ek single galat number field mein silently missed deadlines cause kar sakta hai.

Tasks sporadic hain (event-triggered, fixed period nahi) periodic ki jagah. Kya utilisation bound abhi bhi apply hota hai?

Directly nahi —

\sum C_{i} / T_{i}

test strict periods assume karta hai. Sporadic tasks ke liye tum minimum inter-arrival time ko worst-case

T_{i}

ki tarah use karo; phir periodic tests ek safe over-approximation ban jaate hain.

Deadlines periods se chhoti hain (deadline < period). Kya Rate-Monotonic abhi bhi sahi priority order hai?

Nahi — jab deadlines aur periods diverge hote hain tum priority deadline ke hisaab se assign karo (Deadline-Monotonic), jo wahan optimal hai; Rate-Monotonic (priority by period) sirf tab optimal hai jab har deadline apने period ke barabar ho.

Rate-Monotonic ke comparison mein Deadline-Monotonic kuch task sets kyun schedule kar sakta hai?

Kyunki yeh urgent-deadline tasks ko priority deta hai chahe unke long periods hon, priority ko us cheez se match karta hai jo actually matter karti hai (deadline); RM unhe galat tarike se demote kar deta bade

T_{i}

hone ki wajah se.