Electronics Guide

Transparency and Auditability

Safety and security reviews benefit directly from access to source. An engineer can confirm that a system call has bounded execution time, verify that an interrupt service routine does not disable interrupts longer than specified, and inspect the exact memory layout of kernel objects. Proprietary kernels often document these properties, but open source allows independent verification rather than reliance on vendor assertions.

Auditability also supports supply-chain assurance. Because the entire kernel is present in the build, an organization can reproduce binaries deterministically, generate a software bill of materials that names every kernel source file, scan for known vulnerabilities, and maintain the code even if the original maintainers move on. This durability matters for products with service lifetimes measured in decades, and it has grown more important as regulators in several jurisdictions have begun to require component inventories for connected devices.

Cost and Ecosystem Effects

Eliminating royalties matters most in consumer and industrial products manufactured in large quantities, where even a modest per-unit license fee aggregates into substantial cost. Beyond direct savings, a large user base produces network effects: silicon vendors port their chips to popular kernels, tool authors add kernel-aware debugging, and engineers arrive already familiar with the application programming interface. These effects compound, concentrating activity around a handful of dominant platforms.

The clearest evidence of this concentration is the way vendor software development kits are built. Espressif's ESP-IDF ships FreeRTOS as its scheduler, and Nordic Semiconductor's nRF Connect SDK is built on Zephyr. In both cases the choice of silicon effectively supplies a default kernel, and the surrounding drivers, examples, and application notes assume it.

Limitations to Weigh

Open source does not eliminate every cost. Integration, configuration, certification evidence, and long-term maintenance still require engineering effort, and a freely licensed kernel shifts responsibility for these activities onto the adopting organization. Communities vary in responsiveness, and not every platform provides the certification artifacts that safety-critical domains demand. Warranty and liability disclaimers in permissive licenses are broad, so an organization that needs contractual recourse must buy it separately. These considerations motivate the commercial support arrangements discussed later in this article.

Permissive Licenses

FreeRTOS, Zephyr, RT-Thread, and NuttX are distributed under permissive licenses. FreeRTOS adopted the MIT license at version 10, when Amazon Web Services assumed stewardship in 2017, replacing its earlier modified GNU General Public License. Zephyr uses the Apache License, Version 2.0, as does RT-Thread for releases from version 3.1.0 onward, after migrating from the GNU General Public License, Version 2, in earlier releases. NuttX is likewise distributed under Apache 2.0 following its move to the Apache Software Foundation, which changed its terms from the original BSD license. Permissive terms allow the kernel to be linked with closed-source application code and shipped without disclosing proprietary modifications, which suits commercial products that combine open and private components.

The Apache 2.0 license additionally includes an explicit patent grant, offering recipients defined patent rights from contributors and terminating those rights for a licensee who initiates patent litigation over the work. This provision provides clarity that the MIT and BSD licenses do not address directly, and it is one reason several foundation-hosted projects selected Apache 2.0. The convergence of RT-Thread and NuttX on Apache 2.0 from earlier GPL and BSD terms reflects a broader trend toward permissive licensing for embedded kernels. Permissive does not mean obligation-free: all of these licenses require that copyright notices and license text accompany redistribution, which in practice means shipping an attribution notice with the product.

Copyleft and Weak Copyleft

RIOT departs from this pattern. Its kernel is released under the GNU Lesser General Public License, Version 2.1, a weak-copyleft license. The Lesser GPL requires that modifications to the licensed code itself be made available under compatible terms, yet it explicitly permits an application to link against the library, including by static linking under defined conditions, without imposing copyleft obligations on the proprietary application code. Those conditions typically oblige the distributor to supply object files or another mechanism that lets a recipient relink the application against a modified version of the library, an obligation that deserves attention in a locked-down embedded product.

Stronger copyleft licenses such as the full GNU General Public License go further, requiring that derivative works as a whole be distributed under compatible terms. Engineers must therefore read the specific license accompanying any third-party module, because a project may combine a permissively licensed kernel with components carrying different obligations. Networking stacks, file systems, and graphics libraries are the usual sources of mixed terms, and a single GPL-licensed driver can change the obligations for an entire firmware image.

Dual Licensing and Commercial Editions

Several kernels are offered under dual-licensing arrangements, in which the same or closely related code is available under an open-source license for community use and under a commercial license that removes copyleft obligations, adds indemnification, or supplies certification evidence. FreeRTOS illustrates the pattern: WITTENSTEIN high integrity systems offers OPENRTOS, a commercially licensed edition of the same functional model with warranty and support terms, alongside SAFERTOS, a separately developed safety-certified variant discussed later in this article. Awareness of these models helps engineers interpret a marketplace in which the same programming interface may be available on very different commercial terms.

Scheduling Policies

All five kernels implement fixed-priority preemptive scheduling, in which the highest-priority ready task runs and immediately preempts lower-priority tasks. Most support optional round-robin time slicing among tasks that share a priority level, distributing processor time fairly within a band. Zephyr extends this model with additional policies, including cooperative scheduling for threads that must not be preempted, an earliest-deadline-first option, and metairq priorities that let deferred interrupt work preempt even cooperative threads, giving designers finer control over mixed workloads.

The number of priority levels differs by platform and configuration. FreeRTOS sets its priority count through a single configuration constant, bounded chiefly by available memory, except where the architecture-optimized task selection is enabled; that path relies on a count-leading-zeros instruction over a 32-bit ready bitmap and therefore caps the system at 32 priorities on Arm Cortex-M and similar targets. Zephyr splits its range into negative cooperative priorities and non-negative preemptible priorities, so the numbering convention itself encodes scheduling behavior.

The choice of priority count and tick rate affects both responsiveness and overhead. A higher tick frequency improves the resolution of time delays at the cost of greater interrupt load, so tickless idle modes that suppress unnecessary ticks during quiet periods are common across the platforms to conserve energy. A tickless kernel also changes how timeouts are measured, since the kernel must reprogram a hardware timer for the next scheduled expiry rather than counting uniform ticks.

Synchronization and Communication

Each kernel provides the synchronization primitives that real-time applications require: mutexes, binary and counting semaphores, message queues, and event flags. Mutex implementations generally support priority inheritance to bound the priority inversion that arises when a high-priority task waits for a resource held by a lower-priority task. The richness of these services varies. Zephyr and RT-Thread offer broad sets including mailboxes, pipes, and memory slabs, while FreeRTOS provides a focused core supplemented by stream buffers, message buffers, and direct-to-task notifications, a lightweight signaling path that avoids allocating a separate semaphore object. These mechanisms and their timing implications are compared in Inter-Task Communication.

Memory and Footprint

Footprint distinguishes the platforms sharply. FreeRTOS and RIOT target severe memory constraints. The FreeRTOS project documentation cites a typical kernel binary of roughly 4 to 9 kilobytes, rising toward 10 to 12 kilobytes when optional features such as software timers and event groups are enabled; kernel random-access memory use is small, and the practical floor is set by the application's task stacks and queue buffers rather than by the kernel itself. RIOT is designed to the same order of magnitude for constrained nodes. Zephyr and RT-Thread scale from small microcontrollers upward but pull in more code as networking and subsystems are enabled. NuttX, which presents a POSIX (Portable Operating System Interface) compatibility layer, typically occupies more memory in exchange for a programming model familiar to developers of larger systems. All offer configuration options to compile only the features an application uses. Allocation strategies and their determinism are examined in Memory Management in RTOS.

Memory Protection and Isolation

Hardware memory protection separates a fault in one component from the rest of the system, and support for it varies more than the basic scheduling model does. Zephyr implements a user mode in which threads run unprivileged behind a memory protection unit or memory management unit, with kernel objects reached only through validated system calls and with guard regions that catch stack overflow. FreeRTOS offers memory-protection-unit ports for Arm Cortex-M in which tasks run unprivileged with a restricted set of accessible regions. NuttX can be configured in flat, protected, or kernel build modes, the latter two separating application code from the kernel using protection hardware. RT-Thread provides a separate variant, RT-Thread Smart, that adds memory-management-unit-based user-space processes on application-class cores.

Isolation is not free. Crossing a protection boundary costs cycles on every system call, the region granularity of a protection unit constrains how data may be laid out, and the configuration effort is real. Products that must contain the blast radius of a defect, or that partition trusted and untrusted code, generally judge the cost worthwhile; simple single-purpose controllers often do not.

Symmetric Multiprocessing

As multicore microcontrollers proliferate, symmetric multiprocessing support has grown in importance. Zephyr, RT-Thread, and NuttX include symmetric multiprocessing capabilities that schedule tasks across multiple cores under a single kernel. FreeRTOS merged symmetric multiprocessing into its mainline kernel with version 11.0.0, released in December 2023; before that release, multicore users depended on vendor forks such as those maintained for the ESP32 and the RP2040. RIOT, oriented toward the smallest constrained nodes, focuses on single-core deployments.

Multicore scheduling introduces concerns that single-core analysis does not. Tasks on different cores contend for shared memory, caches, and interconnect bandwidth, so worst-case execution times measured on an isolated core no longer bound behavior. Kernels must also replace simple interrupt-disable critical sections with spinlocks, and applications may need core affinity to pin latency-sensitive work. Platform maturity in this area should be evaluated carefully, and asymmetric arrangements that run a separate kernel instance per core remain a common alternative where interference must be minimized.

Interrupt Handling

All five kernels distinguish between interrupt context and thread context and restrict which application programming interface calls are legal in each. FreeRTOS marks interrupt-safe entry points with a FromISR suffix and requires the application to observe a maximum interrupt priority above which the kernel does not mask. Zephyr supports both statically and dynamically registered interrupt service routines and offers offload mechanisms, including metairq threads, for deferring work out of interrupt context. The general principles of latency, nesting, and deferred processing are covered in Interrupt Management.

Architecture Coverage

FreeRTOS provides official ports for a wide range of architectures, with the Arm Cortex-M family being the most common deployment target, alongside ports for Cortex-A and Cortex-R, RISC-V, Xtensa, and several 8-bit and 16-bit microcontroller cores. Zephyr supports Arm Cortex-M, Cortex-A, and Cortex-R, RISC-V, x86, ARC, Xtensa, and additional architectures, and it emphasizes a hardware abstraction layer that standardizes device access. RT-Thread covers Arm, RISC-V, MIPS, and other cores with an extensive board-support collection oriented toward the chips common in its user base.

RIOT targets low-power microcontrollers and supports Arm Cortex-M, 8-bit AVR and 16-bit MSP430 cores from its historical lineage, RISC-V, and Xtensa, with an emphasis on the constrained devices typical of the Internet of Things. RIOT also ships a native port that builds the operating system as an ordinary process on a Linux or macOS host, which allows application logic and network stacks to be tested and debugged with desktop tools before hardware is available. NuttX runs across Arm, RISC-V, Xtensa, and other architectures, and its design favors portability of its operating-system interfaces across this range.

Board Support and Device Models

Beyond the processor core, practical adoption depends on drivers for peripherals such as timers, serial interfaces, analog converters, and communication controllers. Zephyr's devicetree-based configuration describes hardware declaratively, decoupling driver code from board specifics and easing the addition of new boards; a board file names the peripherals and their addresses, and the build system generates the bindings the drivers consume. RT-Thread and NuttX maintain large driver collections, while FreeRTOS relies more heavily on silicon vendors and reference projects to supply peripheral drivers, since its kernel deliberately scopes itself to scheduling and synchronization.

This difference is a genuine trade-off rather than a defect. A kernel with its own device model imposes a structure that must be learned but delivers portable drivers across boards. A kernel that leaves drivers to the vendor integrates trivially into an existing vendor project but leaves portability to the application team.

Build Systems and Configuration

Zephyr employs a CMake-based build system with the Kconfig configuration framework borrowed from the Linux kernel and a west meta-tool for managing repositories, producing a highly configurable but initially complex environment. RT-Thread offers its own configuration tooling and integrates with common integrated development environments, including a package manager for add-on components. NuttX uses a Kconfig-driven configuration similar in spirit to Linux and ships defconfig files for each supported board. RIOT builds through a make-based system in which an application declares the modules it requires. FreeRTOS, by contrast, is frequently integrated directly into vendor-supplied development environments and is distributed as source files that drop into an existing project, with behavior controlled by a single FreeRTOSConfig.h header, lowering the barrier to a first build.

Debugging and Trace

Kernel-aware debugging, which displays task states, queue contents, and synchronization-object status, is supported across the platforms through popular debuggers and trace tools. Recording trace utilities capture context switches and interrupt events to a buffer for timeline analysis with minimal disturbance to timing, an essential capability given the probe effect that intrusive debugging introduces. Zephyr additionally supports a common tracing format and integrates with several external trace tools, and its native simulation targets allow much application logic to be exercised under host debuggers. The depth of integration varies, and engineers should confirm that their preferred toolchain offers kernel awareness for the chosen platform before committing to it.

Testing and Continuous Integration

Automated testing separates the larger projects from the smaller ones. Zephyr maintains an extensive regression suite executed across many boards and emulated targets on every change, and RIOT and NuttX likewise run continuous integration across their supported hardware. For an adopting organization this matters twice over: it raises confidence in the upstream code, and it supplies a working example of how to test embedded software on emulated targets, a technique that transfers directly to application code.

Connectivity and Middleware

Connectivity stacks differentiate the larger platforms. Zephyr bundles networking that includes a Bluetooth Low Energy host and controller, an IPv4 and IPv6 stack, and constrained-device protocols such as the Constrained Application Protocol. RIOT emphasizes low-power and mesh networking for the Internet of Things, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN), routing for low-power and lossy networks, and lightweight application protocols. RT-Thread ships a broad middleware collection spanning file systems, graphical interfaces, and network protocols. FreeRTOS pairs with companion libraries for transport security, Message Queuing Telemetry Transport messaging, and over-the-air updates, oriented toward but not restricted to Amazon Web Services, while keeping these outside the kernel proper. NuttX provides a substantial set of subsystems consistent with its POSIX heritage, including a virtual file system, BSD-style sockets, and the NuttShell command interpreter.

Support Windows

FreeRTOS designates periodic long-term support releases that receive security updates and critical bug fixes for two years, and a paid extended maintenance program lengthens that window for organizations that need it. Zephyr publishes feature releases roughly every four months and designates a long-term support release every two to three years; version 3.7, released in July 2024, is such a release, and long-term support branches are maintained apart from the main tree for several years. RIOT uses date-based release names and issues feature releases on a regular schedule. NuttX releases numbered versions from the Apache Software Foundation on a frequent cadence.

A long-term support branch is valuable precisely because it does not change. Teams can absorb security fixes without re-qualifying against new features, which is the pattern that regulated and long-lived products require.

Vulnerability Handling

Each project maintains a documented process for reporting security defects privately, coordinating fixes, and publishing advisories once patches are available. Because these kernels are shipped inside millions of devices, the practical burden falls on the integrator: an organization must track advisories for the kernel and for every bundled stack it enables, and it must retain the ability to rebuild and redeploy firmware for the life of the product. A device that cannot be updated in the field inherits every future vulnerability in its software.

Corporate Stewardship

FreeRTOS is maintained by Amazon Web Services, which assumed stewardship from the original author, Richard Barry, in 2017 and continues to develop the kernel and associated libraries. Corporate stewardship concentrates resources and provides a clear point of accountability, though it also ties the project's direction to a single organization's priorities. Commercial long-term support and additional services are available for FreeRTOS through associated offerings, giving teams a path to vendor backing when required.

Foundation Governance

Zephyr is hosted by the Linux Foundation and governed by a consortium of member companies, distributing influence across silicon vendors, tool authors, and product companies. NuttX entered the Apache incubator in 2019 and graduated to a top-level Apache Software Foundation project in November 2022, governed under that foundation's meritocratic model. RT-Thread is developed by a company in association with an active community and is widely deployed, particularly in its region of origin. RIOT is a community-driven project with academic roots and broad institutional participation. Foundation governance reduces dependence on any single sponsor and tends to favor vendor-neutral decision making, which appeals to organizations wary of lock-in.

Functional Safety and Certification

Certification evidence, not the kernel source, is usually the gating item in a safety program. None of the five kernels ships as a certified product in its ordinary open-source form. Two responses to this gap are visible in the market. The first is a certified derivative: SAFERTOS, from WITTENSTEIN high integrity systems, reimplements the FreeRTOS programming model against a certified development process and is supplied with evidence packages assessed by an independent body for standards including IEC 61508 and ISO 26262, which gives teams that prototyped on FreeRTOS a migration path that preserves most application-level code. The second is certification of the upstream project itself: the Zephyr Project is pursuing IEC 61508 certification of its kernel at safety integrity level 3, following the standard's Route 3S pathway for assessing pre-existing software and treating the kernel as a safety element out of context. The project reported written concept approval from its assessor in 2024, and the assessment was still under way at the time of writing. The declared scope covers kernel components; particular target hardware, device drivers, and compilers fall outside it. Engineers planning a certified product should confirm the current status and, critically, the exact scope of any claim, since a certificate covers a named configuration and version rather than the project as a whole.

Support Channels

Commercial support for these platforms is available through silicon vendors, independent consultancies, and, in several cases, the sponsoring organizations themselves. Such arrangements provide service-level agreements, certification assistance, and indemnification that pure community support cannot guarantee. For products in regulated industries, the availability of paid support and certification evidence often weighs as heavily as the technical merits of the kernel.

Resource Budget and Workload

The available memory and the nature of the workload narrow the field quickly. Severely constrained nodes favor FreeRTOS or RIOT, whose minimal footprints leave room for application code. Products that integrate networking, file systems, and graphical interfaces may benefit from the bundled middleware of Zephyr or RT-Thread, accepting a larger footprint in exchange for ready-made subsystems. Applications that demand a familiar POSIX programming model, or that port code from a larger system, may prefer NuttX.

Licensing and Compliance

License compatibility with the product's distribution model must be confirmed early. Permissive licenses simplify combining open and proprietary code, while any copyleft components require careful handling and the attribution obligations of every license must be met in the shipped product. In safety-critical and security-sensitive domains, the availability of certification artifacts, a documented development process, and commercial support may prove decisive. Engineers should also consider the longevity of the platform and the health of its community, since maintenance must continue across the product's service life.

Hardware and Tooling Fit

An existing port to the target silicon, mature peripheral drivers, and kernel-aware debugging for the chosen toolchain reduce development risk substantially. Where a platform already supports the selected board, bring-up effort falls dramatically. Conversely, adopting a kernel that requires a new architecture port introduces schedule and quality risk that should be weighed against its other advantages.

Team Experience and Migration Cost

The cost of learning a platform is easy to underestimate. Zephyr's devicetree and Kconfig layers repay the investment on a long program but slow a short one, whereas FreeRTOS can be added to an existing bare-metal project in an afternoon. Migration between kernels is likewise uneven: applications written against a thin abstraction layer, or against POSIX interfaces, move far more easily than those that call kernel primitives directly throughout. Confining kernel calls behind a small internal interface at the outset preserves the option to change platforms later.