Table of Contents

Embedded platforms: choosing between an RTOS and embedded Linux

The platform decision (bare metal, an RTOS, or embedded Linux with or without real-time patching) is made once and paid for over the product's whole life, because it sets the driver model, the toolchain, the update mechanism and the skills the team needs. It is decided by timing requirements and lifecycle obligations, not by what the team already knows. This namespace covers that layer: what real-time actually means, how the choice is made, and the BSP and driver work underneath it. AEI Corporation designs and implements the embedded platform for custom industrial devices, from board bring-up to application.

What does "real-time" actually mean?

Real-time means bounded, not fast. A system is real-time if the worst-case time from an event to the system's response is known and guaranteed, whatever else is running. A general-purpose Linux desktop is far faster than a small microcontroller on average and is not real-time; the microcontroller responds within a known number of cycles, every time.

The consequences of holding that distinction:

RTOS or embedded Linux — how is the choice made?

Work down these questions in order; the first one that binds usually decides it.

  1. What is the hard deadline, and what happens if it is missed? Single-digit microseconds with a hard consequence points at bare metal, an RTOS, or dedicated hardware, not a general-purpose OS.
  2. What else must the device do? Networking stacks, a web interface, TLS, filesystems, containers, an OPC UA or DDS stack and their dependencies all exist and are maintained on Linux. Reproducing that on an RTOS is a large, permanent cost.
  3. What are the memory and boot constraints? Linux needs an MMU-capable core and meaningful RAM and storage; a class of parts simply cannot run it. Boot-to-function time is often the constraint nobody costed.
  4. What is the certification and lifecycle obligation? Functional safety or security certification changes the calculus. The artefacts a commercial RTOS ships with can outweigh everything above.
  5. Who maintains it in ten years? Toolchain availability, kernel or RTOS version support, and the ability to hire for it are lifecycle costs, and they are where closed platforms become expensive.

The common answer in industrial devices is both: Linux for connectivity, protocol stacks, storage and remote management, with the hard real-time work on a dedicated core, a co-processor or an RTOS partition beside it. The architecture is deliberate, not a compromise: each requirement lands where it is cheapest to meet.

RTOS vs embedded Linux decision tree — five qualifying questions

Figure 1 — RTOS vs Linux decision tree. Work down the five questions in order; the first one that binds decides the architecture. The common answer in industrial devices is both: Linux beside a real-time partition.

Where does real-time Linux fit?

Between those poles sits Linux with the PREEMPT_RT real-time patch set, which makes the bulk of the kernel preemptible and moves interrupt handling into schedulable threads. It buys bounded latency for a large class of industrial work while keeping the Linux ecosystem, which is exactly why it is the common choice for edge controllers and gateways.

Two things to be clear about. First, the patch does not make an unconfigured system deterministic on its own: power management, CPU frequency scaling, SMI handling, driver behaviour and CPU isolation all still have to be dealt with, and the platform's hardware sets a floor the patch cannot go below. Second, any latency figure is a property of a specific board, kernel version and configuration under a stated load (measured with tools such as cyclictest and traced with ftrace or LTTng) and does not transfer to another board. Pin the versions whenever a number is quoted.

What is BSP and driver work, and when is it needed?

A board support package is what makes a specific board boot and expose its hardware to the OS: bootloader configuration, device tree or board initialisation, clock and pin configuration, and drivers for the peripherals that are not already supported. Silicon vendors supply a BSP for their evaluation boards; a custom board is always some distance from that reference, and closing that distance is the work.

Driver work becomes necessary when a peripheral has no upstream driver, when an existing driver cannot meet the device's timing or interrupt requirements, or when custom hardware (an FPGA fabric, a measurement front end) has to appear as a normal OS device so the application layer stays portable. The judgement call is customise or configure: a stock driver that can be made to fit through configuration is worth keeping, because the maintenance burden of a forked driver lasts as long as the product.

Real-time operating systems

Notes on the RTOS platforms we work with. These pages are being migrated and several are still short.

What about the silicon underneath?

The platform choice and the part choice constrain each other: an MMU-less core rules out Linux, and a lifecycle obligation rules out a part without a published longevity commitment. Silicon selection, vendor families and obsolescence handling are covered in the silicon: namespace.

Where does AEI's work sit?

Hardware and software designed together: microcontroller, SoC and FPGA-based development, board bring-up and BSP work, Linux and Windows driver development, and middleware from bare metal up to real-time Linux. The platform work is usually where a device's timing requirements and its connectivity requirements have to be reconciled, which is why it sits next to our protocol work rather than apart from it.

References