The Question Behind the Question
"RTOS or Linux?" usually means "Cortex-M or Cortex-A?", because the OS choice and the silicon choice arrive welded together. An STM32 or ESP32 class MCU hasn't the RAM to boot Linux; a quad-core application processor running FreeRTOS wastes nearly everything you paid for. So before comparing kernels, be honest about which question you're asking: what does this product need to compute, and what deadline does any of it carry?
The clean dividing line is the memory management unit. Linux requires an MMU; MCUs don't have one. Everything else follows from that fact.
What Each One Guarantees
An RTOS guarantees the worst case: the highest-priority ready task runs within a bounded, measured latency, as we covered in the RTOS explainer. On a Cortex-M7, bare-metal interrupt entry sits near 53 ns and FreeRTOS ISR-to-task latency under a microsecond, numbers you can put in a datasheet and defend.
Stock Linux guarantees nothing about the worst case, and that's a design choice, not a defect. Its scheduler optimizes throughput and fairness across thousands of threads. Median wake-up latency is excellent; the tail is unbounded, because memory reclaim, filesystem journaling, or an unlucky lock can stall any thread at any time. The PREEMPT_RT patch set, mainlined into Linux 6.12 in 2024 after two decades of out-of-tree life, shrinks that tail dramatically, bringing worst-case scheduling latency into the tens-to-hundreds of microseconds on well-configured hardware. Real-time Linux is real. It's just a different weight class than a microcontroller kernel, in both directions: heavier floor, vastly richer ecosystem.
The Decision, As a Table
| You need | Choose |
|---|---|
| Hard deadlines under ~100 us, provable | RTOS on an MCU |
| Battery life measured in months | RTOS (microamps asleep; Linux idles in milliwatts) |
| Boot in under 100 ms | RTOS (Linux boot is seconds, heroic tuning gets ~1 s) |
| TCP/TLS/MQTT on a budget | Either; RTOS stacks handle this fine now |
| A display server, browser, or camera ISP pipeline | Linux |
| Python, containers, an app team's productivity | Linux |
| Safety certification (IEC 61508, DO-178C) | RTOS; certifying Linux is a research project |
| Deadlines ~100 us to ~10 ms plus rich userland | PREEMPT_RT Linux, measured on your hardware |
The memory gap is the visceral one. A FreeRTOS sensor node runs in 100-300 KB of flash and tens of KB of RAM. A minimal embedded Linux (kernel plus BusyBox userland) wants 8-16 MB of storage and 64 MB of RAM before your application exists. That's two orders of magnitude, and it's why the BOM decides more of these arguments than the software team does.
The Answer Most Products Actually Ship
Both. The modern pattern is asymmetric multiprocessing: an application processor runs Linux for connectivity, UI, and updates, while a companion Cortex-M core runs an RTOS for the hard-real-time work, motor commutation, sensor capture, power sequencing. NXP's i.MX 8 family, ST's STM32MP1, and TI's Sitara line all ship exactly this split in silicon, with an RPMsg shared-memory channel between the worlds. You stop choosing and start partitioning: deadlines on the M-core, ecosystem on the A-core, and a clean contract in between.
That's also the honest benchmark conclusion: the interesting number was never FreeRTOS-versus-Linux context-switch time on the same core, it's whether your deadline lives on a core that can miss it.
Frequently Asked Questions
Can Linux really do real-time now that PREEMPT_RT is mainline? For deadlines in the hundreds of microseconds with careful configuration (isolated CPUs, locked memory, vetted drivers), yes, and industrial robotics ships on it. For single-digit-microsecond determinism or anything needing certification evidence, no. Measure cyclictest on your actual board under your actual load; never trust someone else's histogram.
Is an RTOS harder to develop for than Linux? Different hard. Linux gives you process isolation, a debugger-rich userland, and the world's package ecosystem; its embedded pain is the build system (Yocto has a learning cliff measured in weeks). An RTOS gives you a single flat memory space where any task can corrupt any other, but the whole system fits in your head, and the kernel is small enough to read.
What about Zephyr as a middle path? Zephyr is still an RTOS, MMU-less class, but with Linux-style infrastructure: Devicetree, Kconfig, in-tree networking and BLE. Teams that want Linux's engineering culture at MCU scale land there, and it's scored against the field in our selection matrix.
Which is cheaper? At volume, the MCU wins on silicon, power, and certification. For a hundred units of an internal tool, Linux on a $25 compute module wins on engineering hours. Cross the two curves for your volume before the architecture review, not after.
