The choice between embedded Linux and an RTOS fundamentally shapes your hardware requirements, software architecture, development workflow, and time-to-market. Embedded Linux requires an MMU-equipped processor (Cortex-A class or RISC-V with MMU), typically 16+ MB RAM and 32+ MB storage, and boots in 1-10 seconds. It provides POSIX APIs, mature networking stacks, filesystem support, package management, and access to thousands of open-source libraries. An RTOS like FreeRTOS or Zephyr runs on Cortex-M microcontrollers with as little as 8 KB RAM and 32 KB flash, boots in microseconds to milliseconds, and delivers deterministic real-time response with interrupt latencies under 1 microsecond. Choose embedded Linux when you need rich networking, display output, complex application logic, or rapid integration of existing Linux software. Choose an RTOS when you need hard real-time guarantees, minimal power consumption, instant boot, or when your hardware budget limits you to microcontroller-class processors.
What Are the Hardware Implications of Each Choice?
Embedded Linux requires a processor with a Memory Management Unit (MMU) to support virtual memory and process isolation. The minimum practical platform is a Cortex-A5 or A7 with 32 MB SDRAM and 16 MB NOR/NAND flash, though most production systems use 128+ MB RAM and 256+ MB eMMC/NAND. Typical processors include NXP i.MX6ULL, TI AM335x (Sitara), STM32MP1, and Raspberry Pi (BCM2711). An RTOS runs on MCUs without an MMU: Cortex-M0 through M7, RISC-V (GD32V, ESP32-C3), and legacy architectures. The BOM cost difference is significant—a Cortex-M4 MCU costs $1-3, while a Cortex-A7 SoC with DDR3 starts at $5-15 plus $1-3 for external RAM ICs. For cost-sensitive, high-volume products, this difference is multiplied across millions of units.
How Does Real-Time Performance Differ?
Standard Linux is not a real-time operating system. Its scheduler (CFS - Completely Fair Scheduler) optimizes for throughput and fairness, not worst-case latency. Interrupt latency on vanilla Linux ranges from 50-500 microseconds, with occasional spikes into the millisecond range due to lock contention, page faults, or kernel preemption delays. The PREEMPT_RT patch reduces worst-case latency to 20-100 microseconds on Cortex-A processors, but this still falls short of hard real-time requirements. A properly configured RTOS delivers deterministic interrupt-to-task latency of 1-10 microseconds, with guaranteed worst-case response times. For applications like motor control (requiring PWM updates every 50 microseconds) or safety-critical systems (requiring response within microseconds of a fault detection), an RTOS is the only viable option.
What About Boot Time and Power Consumption?
An RTOS application on a Cortex-M4 executes its first instruction within microseconds of power-on and reaches the main application loop in under 10 milliseconds. Embedded Linux on a Cortex-A7 takes 2-10 seconds to reach userspace, even with boot optimization techniques like kernel XIP (execute in place), device tree pruning, and systemd-less init. For products that must respond instantly when powered on (automotive body controllers, safety interlocks, alarm systems), RTOS is necessary. Power consumption follows a similar pattern: an RTOS-based Cortex-M4 system idles at 10-100 microamps, while a Linux-based Cortex-A system idles at 10-50 milliamps—a 100-1000x difference that determines whether battery operation is feasible.
Can You Combine Embedded Linux and an RTOS?
Yes, heterogeneous architectures combining Linux and an RTOS on the same SoC are increasingly common. The STM32MP1 pairs a Cortex-A7 running Linux with a Cortex-M4 running FreeRTOS, communicating via shared memory and RPMsg (Remote Processor Messaging). NXP i.MX8M Mini provides Cortex-A53 cores for Linux and a Cortex-M4 for real-time tasks. This architecture lets you run complex applications (GUIs, networking, cloud connectivity) on Linux while offloading time-critical control loops to the RTOS. The tradeoff is increased system complexity, dual-toolchain development, and more complex debugging. OpenAMP (Open Asymmetric Multi-Processing) provides a standardized framework for managing this heterogeneous setup.
/* STM32MP1: Linux (Cortex-A7) communicating with RTOS (Cortex-M4) */
/* Linux side - using RPMsg via /dev/rpmsg_ctrl */
#include <linux/rpmsg.h>
int fd = open("/dev/rpmsg_ctrl0", O_RDWR);
struct rpmsg_endpoint_info ept_info = { .name = "motor_ctrl", .dst = 0x1 };
ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &ept_info);
/* Send setpoint to M4 */
float setpoint = 1500.0f; /* RPM */
write(fd, &setpoint, sizeof(setpoint));
/* M4 side - FreeRTOS receiving via OpenAMP */
void rpmsg_callback(struct rpmsg_endpoint *ept,
void *data, size_t len, uint32_t src, void *priv) {
float *target_rpm = (float *)data;
motor_set_speed(*target_rpm);
}What Decision Framework Should You Follow?
Use these criteria to make your selection:
- Choose embedded Linux when: you need TCP/IP networking with TLS, USB host support, display/GUI, filesystem with wear leveling, or rapid integration of existing open-source software.
- Choose RTOS when: you need sub-100-microsecond response times, your hardware budget is under $5, battery life exceeds 1 year, or boot time must be under 100 milliseconds.
- Choose both (heterogeneous) when: you need rich application features AND hard real-time control, such as industrial HMI with motor control, or automotive infotainment with CAN gateway.
- Consider bare-metal when: your application is simple enough to run in a superloop without preemption, typically single-function devices with one or two interrupt sources.
Key takeaway: Choose embedded Linux when you need rich networking, filesystem support, display output, or rapid integration of open-source software on Cortex-A processors with 16+ MB RAM. Choose an RTOS for hard real-time guarantees, sub-microamp sleep current, instant boot, and microcontroller-class hardware under $5. Heterogeneous Linux+RTOS architectures on multi-core SoCs provide the best of both worlds.
How Did We Navigate the Linux vs RTOS Decision for a Product?
At EmbedCrest, we faced the Linux versus RTOS decision when developing an industrial safety monitoring system that required a 7-inch touchscreen HMI displaying real-time process data, Ethernet/Wi-Fi connectivity to the plant network, USB barcode scanner integration for operator authentication, AND a 100-microsecond control loop for a safety-rated pressure relief valve. No single OS could satisfy all requirements. We selected the STM32MP157 dual-core SoC: the Cortex-A7 running embedded Linux (Yocto-built, kernel 5.15 with PREEMPT_RT) handled the HMI (Qt5/QML), networking (Nginx web server for remote monitoring), USB host, and data logging. The Cortex-M4 running FreeRTOS handled the safety-critical pressure monitoring loop at 10 kHz (100 us period) with deterministic interrupt latency under 3 us. The two cores communicated via RPMsg over shared SRAM, with the M4 publishing pressure readings and alarm status to the A7 at 100 Hz for display, and the A7 sending configuration parameters (setpoints, alarm thresholds) to the M4. This heterogeneous architecture added development complexity but was the only way to meet all requirements within a single SoC at a $12 BOM cost.
What Are the Hidden Trade-offs of Each Approach?
Embedded Linux hidden costs include build system complexity (Yocto builds take 2-6 hours initially and require 50+ GB disk space), kernel configuration expertise (2,000+ kernel config options), and security maintenance (Linux CVEs require regular kernel and userspace updates throughout product lifetime). The GPL v2 license for the kernel means you must release kernel modifications as open source, which can conflict with hardware-specific IP protection requirements. RTOS hidden costs include the lack of standard package management (every library must be manually integrated and maintained), limited debugging tools compared to Linux (no strace, ltrace, or /proc filesystem), and the need for bare-metal peripheral drivers on platforms without mature HAL support. The heterogeneous approach has the highest hidden cost: dual-toolchain development (GCC ARM for both, but separate build systems, debuggers, and flash tools), complex inter-core communication debugging (RPMsg failures are difficult to diagnose without specialized multi-core debug probes like SEGGER J-Link PRO or Lauterbach TRACE32), and the need for separate safety certification of each core's software.
How Do You Optimize Embedded Linux Boot Time?
Embedded Linux boot time optimization can reduce time-to-application from 10+ seconds to under 2 seconds through systematic elimination of bottlenecks. Start by profiling with systemd-analyze blame to identify the slowest init services. Replace systemd with a minimal init (BusyBox init or a custom init script) to save 500-1500 ms. Use kernel XIP (eXecute In Place) from NOR flash to eliminate kernel decompression time (saves 200-500 ms). Prune the device tree to include only peripherals your board actually uses, reducing device probing time by 100-300 ms. Defer non-critical driver initialization to after the application launches using kernel module loading. Enable kernel PREEMPT and disable CONFIG_PRINTK for production builds. Use squashfs for the root filesystem with LZO compression (faster decompression than gzip). The most impactful optimization is often the simplest: move the application to run as the init process itself (PID 1) if no other services are needed, eliminating all init system overhead. For applications requiring sub-500ms boot, consider a hybrid approach where the RTOS core starts immediately and handles time-critical I/O while Linux boots in the background.
