RTOS vs Embedded Linux: Which Should You Choose and When?

Choosing between a real-time operating system and Embedded Linux is one of the most consequential decisions in embedded product development, yet it is rarely as straightforward as vendor literature suggests. Both approaches have matured considerably over the past decade. FreeRTOS, Zephyr and commercial RTOSes such as INTEGRITY and QNX sit alongside Yocto-built Linux distributions in the same product portfolios at many leading engineering organisations. The decision is not simply a question of capability. It is a question of determinism requirements, safety obligations, hardware constraints, team skills and long-term maintainability. This article sets out the technical and commercial factors you should weigh before committing to either path, with reference to the platforms, standards and toolchains that matter in UK engineering practice.

Understanding the Core Difference: Determinism vs Feature Richness

The fundamental distinction between an RTOS and Embedded Linux is how each handles time. An RTOS is designed to guarantee that a task will complete within a bounded, predictable time window. This property, known as determinism or hard real-time behaviour, is essential in any system where a missed deadline has physical consequences.

Embedded Linux, by contrast, is a general-purpose operating system kernel adapted for constrained hardware. Even with the PREEMPT_RT patch applied, Linux cannot guarantee the same level of latency determinism as a purpose-built RTOS. Scheduling jitter, memory management interrupts and kernel path lengths all introduce variability that is acceptable in many applications but disqualifying in others.

When determinism is non-negotiable

Applications where RTOS determinism is genuinely required include:

• Motor control loops running at frequencies above 10 kHz
• Safety-critical actuator commands in aerospace or automotive systems
• Industrial fieldbus stacks requiring precise cycle timing (Profinet IRT, EtherCAT)
• Medical device sensor acquisition where timing accuracy affects diagnostic integrity
• Any system subject to IEC 61508, ISO 26262 or DO-178C, where timing behaviour must be formally analysed

In these contexts, the choice is rarely between RTOS and Linux. It is between which RTOS, and how to certify it.

When Linux's richness outweighs its timing limitations

Many embedded products do not need hard real-time behaviour at the application level. HMI platforms, IoT gateways, industrial edge computers, connected medical devices and avionics data concentrators all benefit from the broad driver support, networking stack, filesystem handling and package ecosystem that Embedded Linux provides. Building a TCP/IP stack, a USB host driver or a graphics compositor on a bare-metal RTOS is a significant engineering undertaking. On Linux, these capabilities are already present and well-tested.

RTOS Platforms: A Practical Overview

The RTOS landscape in UK embedded engineering spans both open-source and commercial options, each carrying different implications for certification, support and licensing.

FreeRTOS

FreeRTOS is the most widely deployed open-source RTOS, supported on hundreds of MCU targets including STM32 families from STMicroelectronics and NXP Kinetis and LPC series devices. Amazon now stewards the project and has added AWS IoT integration through FreeRTOS Plus components. Its strengths are its shallow learning curve, vast community and permissive MIT licence. Its weakness is that the kernel alone does not come with a certified safety case. For IEC 61508 or ISO 26262 applications, teams typically rely on MISRA C compliance tooling, formal code review processes and third-party qualification artefacts rather than a vendor-supplied safety certificate.

Zephyr RTOS

Zephyr, maintained by the Linux Foundation, has grown rapidly as a credible alternative for constrained IoT and industrial devices. It supports a wide range of architectures including ARM Cortex-M, RISC-V and x86, and has become a serious option for designs targeting nRF52/nRF53 series from Nordic Semiconductor as well as STM32 and TI CC13xx/CC26xx wireless MCUs. Zephyr's modular device tree configuration and west build system give it a more disciplined project structure than FreeRTOS. Safety certification artefacts are in development through the Zephyr Safety Working Group.

Commercial RTOSes for safety-critical applications

Where formal certification is mandatory, commercial RTOSes carry significant advantages:

• INTEGRITY (Green Hills Software): Widely used in aerospace and defence. Certified to DO-178C DAL A and compliant with ARINC 653 partitioning. Common in avionics systems across both civil and military platforms.
• QNX Neutrino (BlackBerry): Used heavily in automotive (AUTOSAR-adjacent stacks), medical devices and industrial automation. QNX holds ISO 26262 ASIL D and IEC 61508 SIL 3 certificates.
• SAFERTOS (WITTENSTEIN high integrity systems): A safety-qualified derivative of FreeRTOS, used in IEC 62304 Class C medical devices and IEC 61508 SIL 3 applications. Popular in UK MedTech programmes because it retains FreeRTOS familiarity while providing a documented safety case.
• LynxOS and VxWorks (Wind River): Long-standing enterprise RTOSes with broad aerospace, defence and industrial deployment.

For engineering teams working on safety-certified products, the RTOS choice is deeply connected to the certification strategy. Our article on DO-178C software certification in aerospace explores how that interacts with software planning and hiring decisions.

Embedded Linux Platforms and Toolchains

Embedded Linux development has consolidated around a relatively small number of build system approaches, each with distinct trade-offs in terms of flexibility, reproducibility and learning curve.

Yocto Project

Yocto is the de facto standard for production Embedded Linux in the UK engineering market. It uses a layered metadata approach (BitBake, recipes, layers) to produce a fully customised Linux distribution from source. The resulting build is reproducible, auditable and highly stripped-down compared to a desktop distribution. Yocto is the toolchain of choice for NXP i.MX 8 series SoCs, TI AM57x and AM64x processors, and many industrial SoC designs based on ARM Cortex-A cores.

The main challenge with Yocto is its steep learning curve. Engineers new to the project often underestimate the time required to get a stable BSP, maintain layer compatibility across LTS releases (kirkstone, scarthgap) and handle licence compliance obligations for open-source components. This is a meaningful contributor to the talent gap described in our article on Embedded Linux engineering and why that gap is widening.

Buildroot

Buildroot offers a simpler alternative to Yocto for smaller products where a minimal, fast-to-build Linux image is more important than long-term layered customisation. It is popular in industrial IoT edge devices and low-cost consumer electronics. Build times are shorter, the configuration model (Kconfig-based) is more accessible, and the output is lean. The trade-off is less flexibility for large, multi-team projects where Yocto's layer model becomes an asset.

PREEMPT_RT and the real-time Linux path

For applications that sit between hard real-time and standard Linux requirements, the PREEMPT_RT patch set converts most of the Linux kernel's non-preemptible sections into preemptible ones, substantially reducing worst-case latency. As of kernel 6.12, the core PREEMPT_RT patches are merged into the mainline kernel, which is a significant milestone for industrial Linux deployments. Worst-case latencies in the low hundreds of microseconds are achievable on capable hardware, which is sufficient for many soft real-time industrial control applications.

Hybrid Architectures: Getting the Best of Both

A growing number of embedded product designs use both an RTOS and Linux simultaneously on a single SoC. This is practical on heterogeneous multicore devices such as the NXP i.MX 8M Plus, which pairs Cortex-A53 application cores (running Linux) with a Cortex-M7 real-time core (running FreeRTOS or Zephyr). The TI AM64x follows a similar model with its dual Cortex-R5F real-time cores alongside Cortex-A53 application cores.

In this architecture, Linux handles connectivity, UI, over-the-air update, application logic and data aggregation. The RTOS handles time-critical tasks: motor control, safety monitoring, sensor acquisition or fieldbus communication. Inter-processor communication (IPC) is managed through shared memory, RPMsg or hardware mailboxes.

This approach is increasingly common in:

• Industrial drives and servo controllers
• Robotics platforms requiring both ROS 2 (on Linux) and deterministic motion control
• Medical devices combining data logging and connectivity with real-time biosignal processing
• Automotive body control and ADAS platforms where AUTOSAR Classic runs on dedicated MCUs alongside Linux-based infotainment or AUTOSAR Adaptive stacks

Engineers who can architect and implement these heterogeneous systems are genuinely in short supply. Our article on the UK embedded software hiring market in 2026 covers why cross-domain embedded expertise is increasingly valued.

Safety Certification: The Deciding Factor in Regulated Industries

If your product is subject to functional safety standards, your OS choice is constrained in ways that override most other considerations.

• IEC 62304 (medical device software): Requires software lifecycle process compliance. A pre-certified RTOS with a qualified safety case (SAFERTOS, QNX, INTEGRITY) simplifies your technical file considerably. Embedded Linux is used in Class B and Class C medical devices, but requires rigorous configuration management, vulnerability monitoring and a documented rationale for why a GPOS is acceptable in the safety context.
• ISO 26262 (automotive): AUTOSAR Classic runs on certified RTOSes meeting OSEK/VDX and AUTOSAR OS specifications. For ASIL B to ASIL D decomposition, OS certification is typically required.
• IEC 61508 and IEC 61511 (industrial functional safety): SIL-rated RTOSes provide a pre-qualified foundation. Using Linux in SIL 2 or SIL 3 applications requires extensive argumentation and is generally avoided for the safety layer, though it may be acceptable for non-safety application layers in a mixed-criticality architecture.
• DO-178C (aerospace): Mandates rigorous verification of all software including the OS. Commercial RTOSes with existing DO-178C qualification data (INTEGRITY, LynxOS-178, VxWorks 653) are the practical route to DAL A or DAL B compliance.

For more on how safety certification affects team composition and hiring, see our guides on functional safety recruitment and hiring functional safety engineers in the UK.

Making the Decision: A Practical Framework

When advising engineering teams on this choice, the following questions generally surface the right answer:

1. What are the worst-case timing requirements? If any task has a deadline in the sub-millisecond range with physical safety consequences, use a certified RTOS for that function.
2. Is the product subject to a safety standard? If yes, the standard's requirements for OS qualification will largely dictate your options.
3. What connectivity, UI or protocol complexity does the product need? If the answer involves TCP/IP stacks, TLS, USB, OTA updates or a graphical interface, Linux reduces engineering effort substantially.
4. What is the hardware platform? Cortex-M class MCUs (STM32, NXP LPC, TI MSP432) are natural RTOS targets. Cortex-A class SoCs (NXP i.MX, TI AM series, Broadcom BCM) are natural Linux targets. Heterogeneous SoCs invite hybrid architectures.
5. What skills does your team currently hold? Migrating from FreeRTOS to Yocto-based Linux involves a significant re-skilling investment. If speed to market is the priority, factor team capability into the decision.
6. What is the product's expected lifecycle? Yocto LTS layers receive two to three years of support. Long-life industrial products need a clear OS maintenance strategy regardless of platform.

Working with Vertech Group

Vertech Group places engineers across the full embedded technology stack, from bare-metal RTOS firmware on STM32 and NXP MCUs to Yocto-based Embedded Linux on production SoC platforms. Our Embedded and Product Engineering practice covers firmware engineers, embedded software engineers, BSP and Linux engineers, and safety-critical software specialists working to IEC 62304, ISO 26262, IEC 61508 and DO-178C.

We also work across Industrial Automation and Controls, where the RTOS vs Linux debate appears in a different form: PLCs running deterministic scan-cycle firmware alongside Linux-based SCADA and edge computing platforms in modern IIoT architectures.

Sectors we serve include aerospace and defence, automotive, MedTech, industrial automation, energy, and connected consumer electronics. If you are building or expanding a team with embedded OS expertise and want a frank conversation about candidate availability and hiring timelines, our consultants work with specialist engineers in this space every week. You can explore our services or get in touch directly to discuss your requirements.