5.5.15 · D5Embedded Systems & Real-Time Software
Question bank — Bare-metal vs RTOS — when to use each
Before the traps, three tools we lean on constantly. Read these first so no symbol ambushes you later.
The three strips above are the mental model for every trap below: top = super-loop (waits add up), middle = RTOS pre-emption (the urgent task cuts in), bottom = priority inversion (a lock traps the urgent task).
True or false — justify
Real-time means the system is fast.
False. Real-time means deterministic — bounded, predictable timing that meets deadlines. A system that always answers in 50 ms is more real-time than one that usually answers in 1 ms but sometimes takes 200 ms.
An RTOS makes your firmware run faster than bare-metal.
False, usually slower on average — Context Switching and kernel bookkeeping cost cycles. What an RTOS buys is predictable latency for critical tasks, not throughput.
Bare-metal has no way to respond quickly to an urgent event.
False. ISRs give bare-metal hardware-level pre-emption for time-critical events — that's how a super-loop stays "real-time" without a scheduler.
In a super-loop, a slow job only hurts itself.
False. Every job is serviced once per loop, so the worst-case wait for any job is the sum of all jobs' execution times — the slowest job poisons everyone (top strip of the figure).
Under RTOS pre-emptive scheduling, a slow low-priority task can delay a high-priority one.
Mostly false — that's the whole point (middle strip). A high-priority task's response time depends only on higher-priority work . The exception is priority inversion, where a shared lock lets a low task block a high one.
If CPU utilisation , all deadlines are guaranteed under Rate-Monotonic.
False. Since , the Liu & Layland bound is , which is below 1. Above the bound the test is inconclusive, not necessarily infeasible.
The Liu & Layland utilisation test is exact: if it fails, the task set is unschedulable.
False. It is sufficient, not necessary. Failing it means "run the exact response-time recurrence " — the set may still meet deadlines.
Adding an RTOS always improves timing behaviour.
False. If jobs are few and similar-rate, the RTOS adds RAM, context-switch jitter, and non-determinism for zero timing benefit — a super-loop is more predictable there.
A watchdog timer is only needed on RTOS systems.
False. Both need one; a stuck super-loop or a deadlocked task both hang forever, and only an independent watchdog can reset the MCU.
Two tasks at the same priority in an RTOS can pre-empt each other.
False. Equal-priority tasks don't pre-empt one another; they either run to a blocking point or time-slice cooperatively — pre-emption is strictly higher over lower.
Spot the error
"Our control loop misses its deadline, so we'll speed up the display code."
Wrong lever. In a super-loop the fix is architectural (pre-empt or move the display to lower priority under an RTOS), not shaving a few ms off one already-slow job.
"We picked an RTOS, so we no longer need to think about WCET."
Wrong. Every schedulability test — the utilisation bound and the response-time recurrence — is built on WCET numbers (). An RTOS needs them more, not less.
"Give every task the highest priority so nothing misses its deadline."
If everything is top priority, nothing is — you've recreated a run-to-completion queue with extra overhead. Priorities only help when they differ by urgency.
"We used a mutex, so priority inversion can't happen."
Backwards — the mutex is what creates the inversion (a low task holds a lock a high task needs, bottom strip). The fix is a mutex with priority inheritance, see Priority Inversion and Mutexes.
"Our ISR does the heavy sensor processing so the main loop stays free."
Long ISRs block all lower-or-equal interrupts and starve the system. ISRs should be short — set a flag/queue an event and return; do the work in the loop or a task.
"Utilisation is 0.9, well under 1.0, so we're safe under Rate-Monotonic."
is above the ~0.693 RM bound, so the simple test says "unknown," not "safe." You must run the exact response-time analysis.
"The RTOS gives each task its own CPU."
Only the illusion of one. There is still a single CPU time-sliced by the scheduler; total work must still be feasible or deadlines are missed.
Why questions
Why does the super-loop worst-case latency use a sum , not a max?
Because a job just missed its check must wait for every other job in the loop to finish before its turn comes again — waits accumulate, so they add (top strip of the figure).
Why does the response-time recurrence use a ceiling ?
Because a higher-priority task arriving with period can fire a whole extra time even if only a fraction of its period fits in the window — you can't pre-empt "half" an arrival, so you round up.
Why is the Liu & Layland bound less than 1 (why can't we use 100% of the CPU)?
Because task periods don't line up perfectly; the harmonic mismatch leaves gaps you can't safely fill and still guarantee deadlines under a fixed-priority rule.
Why does an RTOS cost more RAM than bare-metal?
Each task needs its own stack so it can be paused and resumed independently, plus the kernel's own data structures — bare-metal has one stack.
Why is predictability valued over raw speed in real-time systems?
A missed deadline in an airbag or motor controller is a failure regardless of average speed; a slower-but-bounded system is correct, a faster-but-occasionally-late one is broken.
Why can't you just add more ISRs to a bare-metal design instead of an RTOS?
ISRs share one interrupt-priority hierarchy and must stay short; heavy concurrent, blocking, or many-priority work overwhelms that model — that's exactly the boundary where an RTOS earns its keep.
Why does context-switch overhead make an RTOS less deterministic in the worst case?
Each switch costs a variable number of cycles (cache/pipeline effects), adding jitter that a straight-line super-loop simply doesn't have.
Edge cases
What happens in a super-loop if one job enters an infinite wait (e.g. blocking I/O)?
The whole loop hangs — there's no scheduler to switch away — so every job stalls; only an ISR or watchdog can rescue the system.
A task set has utilisation exactly at the bound, . Schedulable?
Yes — the bound is inclusive (), so equality passes the sufficient test and RM guarantees all deadlines.
Only one job exists on the MCU. Bare-metal or RTOS?
Bare-metal — with a single job there's nothing to schedule against; an RTOS would be pure overhead for zero concurrency benefit.
All tasks are perfectly harmonic (periods are integer multiples). Does the 0.693 limit still apply?
No — for harmonic period sets the RM utilisation bound rises to 1.0, so you can safely load the CPU fully; the pessimistic 0.693 is the worst-case over arbitrary periods.
Two equally urgent tasks each need "immediate" response. Can an RTOS satisfy both at once?
No scheduler can — one CPU serves one task at a time. If both truly need zero latency simultaneously, you need more hardware (a second core/MCU or dedicated ISR), not a cleverer scheduler.
A high-priority task blocks on a lock held by a low-priority task that never gets to run. What's the failure and fix?
Unbounded priority inversion; fix with priority inheritance (temporarily boost the lock holder) or priority ceiling.
Utilisation is well under the bound but one task's WCET is wrong (underestimated). Consequence?
The guarantee is void — schedulability rests entirely on correct WCET (); a single bad number can silently cause missed deadlines in the field.
The tasks are sporadic (event-triggered, no fixed period) rather than periodic. Does the utilisation bound still apply?
Not directly — the test assumes strict periods. For sporadic tasks you use the minimum inter-arrival time as a worst-case ; then the periodic tests become a safe over-approximation.
Deadlines are shorter than periods (deadline < period). Is Rate-Monotonic still the right priority order?
No — when deadlines and periods diverge you assign priority by deadline (Deadline-Monotonic), which is optimal there; Rate-Monotonic (priority by period) is optimal only when each deadline equals its period.
Why can Deadline-Monotonic schedule some task sets that Rate-Monotonic cannot?
Because it gives urgent-deadline tasks priority even if they have long periods, matching priority to what actually matters (the deadline); RM would wrongly demote them for having a large .