RAM is the most concrete cost: every task needs its own stack sized for its worst case (including interrupt nesting), plus the kernel's own data, task control blocks, queues, timers, so on a device with a few kilobytes of RAM, even a handful of tasks can be a tight fit, and undersizing a stack causes an overflow that, with no MMU, silently corrupts another task's memory. The bigger risk is a whole new class of bugs: the moment tasks share data you have race conditions, so you need mutexes and queues, and you inherit subtle hazards like priority inversion and deadlocks that simply don't exist in a single-threaded super-loop, these are hard to reproduce and debug. There's also runtime overhead (context switches and the periodic tick interrupt cost cycles), flash footprint for the kernel, configuration complexity, and a learning curve. And critically, the RTOS doesn't make the system real-time, a poorly prioritized or CPU-overloaded task set still misses deadlines, so you've added complexity that you must then manage to actually get the benefit. So you weigh flexible concurrency against RAM, determinism-engineering effort, and concurrency-bug risk.
RTOS & Real-Time Concepts · Interview question
What are the costs and risks of adding an RTOS?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Bare-Metal vs RTOS
When the super-loop stops scaling: what an RTOS buys you (tasks, priorities, blocking that yields), what it costs (RAM, complexity, concurrency bugs), and when bare-metal is still the right call.