How to Choose Between FreeRTOS, RT-Thread, Zephyr, and NuttX

When an MCU project chooses an RTOS for the first time, the first questions are often about size, speed, and API simplicity.

Those questions help, but they are not enough. Choosing an RTOS is not only choosing a scheduler. It is choosing how device software is organized: how tasks are created, how drivers are integrated, where networking and filesystems come from, how board differences are maintained, whether existing C or POSIX-style code can be reused, and whether the team can debug field failures.

The first map looks like this:

FreeRTOS: lightweight kernel and common MCU SDK entry point
RT-Thread: China-focused ecosystem, device framework, and IoT components
Zephyr: configuration system, hardware description, and cross-board platform engineering
NuttX: POSIX-like APIs, Unix-style abstractions, and a fuller device system model

They all run tasks, handle interrupts, and provide synchronization objects. The real differences are outside the scheduler.

A more practical decision order is:

check chip SDK and BSP support first
then check whether the product needs platform capabilities
then check which engineering model the team understands
compare kernel size and API preference last

If RTOS support for the target chip is weak, or if key drivers, wireless stacks, and certification packages are tied to another SDK, theoretical advantages rarely become project value.

FreeRTOS Fits Lightweight Kernel Use

FreeRTOS is direct, small, and widely integrated.

Many chip SDKs, module SDKs, cloud connectivity examples, and teaching projects include FreeRTOS. For resource-constrained MCU devices, it usually provides the core objects:

• tasks
• queues
• semaphores
• mutexes
• software timers
• ticks and delays

That model solves many problems that grow out of a bare-metal superloop. Multiple paths can block and wait, peripheral events can wake tasks, and communication, sampling, storage, and control logic can be separated with tasks and queues.

The boundary is also clear. FreeRTOS is closer to an RTOS kernel than a full device platform. Driver frameworks, board descriptions, filesystems, networking stacks, update logic, security, and logging usually come from the chip SDK, third-party components, or project-specific integration.

That has two consequences.

First, adoption and porting can be lightweight. A team can introduce tasks and queues around an existing bare-metal project without accepting a full platform.

Second, larger projects often build their own small platform around it. Each product may create its own driver interfaces, configuration style, logging, event model, and update path. That is flexible early and depends heavily on team discipline later.

FreeRTOS fits when:

• MCU resources are tight and the feature boundary is clear
• the chip SDK already integrates FreeRTOS deeply
• the team wants a gradual path from bare metal to RTOS
• the project mainly needs tasks, queues, and ISR-to-task coordination

Small does not automatically mean cheapest. If a product needs many board variants, complex driver models, unified configuration, and long-term component evolution, a lightweight kernel alone may not reduce total cost.

RT-Thread Fits Domestic Ecosystem and IoT Components

RT-Thread deserves a separate look in Chinese embedded projects.

Its value is not only that it is a domestic RTOS or that it has a scheduler. The more important parts are Chinese documentation and community, BSP coverage, a device framework, components, and a package ecosystem. Together, they make it closer to an IoT device software platform.

For many teams in China, the appeal comes from:

• Chinese documentation and community feedback
• existing BSPs for common MCUs and boards
• a device framework that reduces repeated peripheral adaptation
• optional components such as FinSH, filesystems, networking, and packages
• RT-Thread Nano for smaller MCU resources

This is not a question of which system is more advanced. The default boundary differs. FreeRTOS focuses more on the kernel and core primitives. RT-Thread puts drivers, components, tools, and packages into one ecosystem.

That matters in real IoT projects. The hard problem is often not whether the scheduler can preempt. It is whether the driver already exists, whether networking, filesystems, shell, OTA, and logging can avoid being rebuilt from scratch, and whether the team can read the documentation and examples quickly.

RT-Thread fits when:

• the team benefits from Chinese documentation, community, and ecosystem support
• the project wants a device framework and component system beyond the kernel
• the target MCU or board has a mature BSP
• the product should not assemble shell, filesystem, networking, and packages from scratch

The risk is treating ecosystem claims as project conclusions. Before choosing it, inspect the BSP quality for the target chip, component maintenance, license requirements, the team’s comfort with its object and device model, and how it interacts with the vendor SDK, wireless stack, and production tools.

Zephyr Fits Multi-Board Platform Engineering

Zephyr is often called an IoT RTOS. A more precise description is that it is a scalable RTOS for resource-constrained embedded devices, with connected devices and IoT as major use cases.

Its strongest feature is not one API. It is the platform engineering model:

• Kconfig for configuration
• devicetree for hardware description
• CMake and west for builds and modules
• driver model and subsystems with unified interfaces
• upstream board, driver, and protocol stack evolution

In many FreeRTOS projects, configuration can be scattered across headers, project options, and SDK menus. Zephyr makes board hardware, enabled features, and driver integration part of the project structure.

This can feel heavy for a small single-board project. When all you need is GPIO, UART, or I2C, Kconfig, devicetree, overlays, and west workspaces may look like overhead. But if a product line must support multiple chips, boards, and feature variants, that structure starts paying back.

Zephyr fits when:

• several hardware platforms share one software architecture
• the product must maintain multiple board variants over time
• the team accepts Kconfig, devicetree, and upstream workflows
• connectivity, security, device management, logging, and tests matter as integrated subsystems

The cost comes from the same mechanisms. The learning curve, build system, configuration dependencies, and abstraction layers are heavier than a lightweight kernel. If the device is small, short-lived, resource-tight, and already locked to a vendor SDK, Zephyr may not be the lowest-cost path.

NuttX Fits POSIX and Unix-Style Device Models

NuttX represents another RTOS direction.

Many RTOSes center the application around tasks, queues, and semaphores. NuttX emphasizes POSIX compatibility, VFS, device nodes, filesystems, networking, and a shell. It makes an embedded device feel more like a small Unix system than firmware with a handful of tasks.

That direction helps with reuse and abstraction:

• POSIX-style code is easier to reuse
• devices can be exposed through /dev-style nodes
• files, sockets, and poll can form a unified I/O model
• NSH gives debugging and interaction a Linux-like feel
• filesystems, networking, and driver frameworks are more complete

In China, NuttX is also tied to Xiaomi Vela. Xiaomi Vela chose NuttX as its base, with POSIX compatibility and broader system abstractions among the important reasons. That makes NuttX more than an educational example of a Unix-like RTOS; it has a visible consumer IoT platform case.

NuttX fits when:

• the product wants a POSIX or Unix-style model on an RTOS device
• the device needs filesystems, networking, shell, and a unified I/O abstraction
• some Linux or POSIX-style code should be reused
• the platform wants a fuller system model near the MCU/MPU boundary

The price is complexity. POSIX compatibility, VFS, device nodes, and system components make the model larger than a minimal RTOS. For a small MCU that only needs a few tasks, peripherals, and simple communication, NuttX may not be the easiest option.

Start With System Boundaries

The four systems can be judged with a few practical questions.

If resources are tight, the SDK already provides FreeRTOS, and the product mainly handles sampling, control, communication, and state machines, FreeRTOS is often the natural choice.

If a domestic team wants to reduce porting and component assembly cost, and needs Chinese ecosystem support, BSPs, a device framework, and common IoT components, RT-Thread should be evaluated early.

If a product line must span multiple chips and boards while maintaining hardware descriptions, feature configuration, drivers, and subsystems over time, Zephyr’s platform model is valuable.

If the device needs POSIX APIs, VFS, sockets, shell, filesystems, and Unix-like abstractions, or if the team wants to align with a Xiaomi Vela-like platform direction, NuttX is worth serious attention.

Do not ask only which RTOS is best. Ask:

• what the chip SDK supports by default
• whether the target board BSP is mature
• whether the project needs a kernel or a platform
• whether the team is stronger in bare metal, Linux, FreeRTOS, or POSIX
• whether multiple hardware variants must be maintained
• who provides networking, filesystems, OTA, security, and logging
• whether field debugging has shell, logs, task state, and stack watermark tools
• whether license, supply chain, and community maintenance fit the product

The core of RTOS selection is not finding a universal winner. It is matching system boundaries with team capability.

The short version is:

This table is not a substitute for real evaluation. Before committing, return to the target chip, board, key peripherals, team experience, and production maintenance path.

A Practical Rule

If a project is moving from bare metal to RTOS, FreeRTOS teaches the essential model: tasks, queues, semaphores, ticks, and ISR-safe APIs.

If the project sits in the Chinese MCU and IoT ecosystem, RT-Thread belongs on the shortlist, especially when components, BSPs, packages, and Chinese support matter.

If the product must handle multiple boards, configurations, and long-term platform maintenance from day one, Zephyr deserves earlier evaluation.

If the device should have Unix-like I/O, files, networking, and application structure, NuttX has the clearer direction.

These four systems are not a simple scale from small to large. They are four ways to organize device software. A wrong choice usually hurts not because one API is awkward, but because the project boundary, maintenance model, and debugging path do not fit.

Further Reading

• FreeRTOS Documentation
• RT-Thread Documentation
• Zephyr Project Documentation
• Apache NuttX Documentation
• Xiaomi Vela