Embedded on KnightLi Blog

How to Choose Between FreeRTOS, RT-Thread, and Zephyr: Architecture Differences and Use Cases

Sun, 17 May 2026 12:32:06 +0800

FreeRTOS, RT-Thread, and Zephyr are often compared as if they were the same kind of RTOS. They are not.

The better question is not “which RTOS is better”, but what your project actually needs: a small scheduling kernel, an RTOS with strong domestic MCU support, or a complete cross-platform embedded operating system.

At a high level:

FreeRTOS is a widely used scheduling kernel, plus a set of AWS-maintained IoT libraries.
RT-Thread is a kernel plus a richer component ecosystem, with strong Chinese documentation and long-tail domestic MCU support.
Zephyr is a Linux Foundation hosted RTOS that emphasizes unified subsystems, device models, Devicetree, and cross-vendor application reuse.

Bottom line

If your project only needs tasks, queues, semaphores, timers, and a very small footprint, FreeRTOS remains one of the safest choices.

If you mainly use Chinese MCU vendors and want ready BSPs, Chinese community support, ENV tooling, and a larger RTOS component set, RT-Thread has real advantages.

If you need to reuse application code across chips, boards, and vendors, and your team can accept the learning curve of Kconfig, Devicetree, west, and Zephyr’s driver model, Zephyr is the more future-facing engineering path.

This is not a simple “which one replaces which” question. They sit at different abstraction levels.

FreeRTOS: small, familiar, deterministic

FreeRTOS is strongest when you need something small and predictable.

The FreeRTOS-Kernel repository focuses on the kernel, ports, and core RTOS mechanisms: scheduling, semaphores, queues, event groups, software timers, and memory allocation. In many real projects, this is exactly what teams use.

Its advantages are straightforward:

Huge MCU coverage.
The most examples and learning material.
Easy integration into vendor SDKs.
Good fit for resource-constrained systems.
Short debugging paths because many teams already know it.

After AWS acquired FreeRTOS, it also maintained libraries such as coreMQTT, coreHTTP, OTA, Device Shadow, Jobs, and Defender. The FreeRTOS 202406 LTS release brings kernel and IoT libraries into a long-term support line.

The boundary is equally clear: FreeRTOS is not a complete OS platform. It does not define a unified cross-vendor model for GPIO, UART, I2C, boards, pin control, or HAL abstraction. Those parts come from vendor SDKs or your own architecture.

That is a design choice, not a flaw. It makes FreeRTOS flexible and easy to embed, but when you change vendors or boards, application code often gets pulled into the hardware migration.

RT-Thread: stronger domestic MCU coverage and components

RT-Thread is closer to a complete RTOS than FreeRTOS.

Besides the scheduler, it provides file systems, networking, device framework, USB, sensor framework, packages, and tooling. For many Chinese embedded teams, its Chinese documentation, ENV workflow, community, and BSP coverage are practical advantages.

It is especially useful for long-tail domestic MCUs such as AT32, HC32, N32, APM32, HT32, Luat, HPMicro, and similar families. Many projects do not use only the biggest international vendors, and RT-Thread often gives these projects a faster starting point.

RT-Thread fits when:

You use many domestic MCUs.
Chinese docs and community matter.
You need more components than a bare FreeRTOS setup.
You want file system, networking, shell, and device framework quickly.
You do not want to build all board and driver abstractions yourself.

Its limitation is that many BSPs still remain board-specific and vendor-library-oriented. From the perspective of cross-vendor hardware description and application reuse, it does not have the same systematic model as Zephyr.

RT-Thread is therefore best understood as a practical RTOS ecosystem above a kernel, especially strong in the Chinese MCU world, but not the same kind of full engineering platform as Zephyr.

Zephyr: an embedded system engineering platform

Zephyr is often described as a more complex RTOS. That is partly true, but the complexity is not random feature bloat.

Zephyr tries to bring into one OS project many things that are usually scattered across vendor SDKs, BSPs, HAL code, custom drivers, configuration scripts, and application code.

Its key pieces are:

Kconfig for feature and build configuration.
Devicetree for board-level hardware description.
Unified drivers for GPIO, UART, SPI, I2C, ADC, DMA, clock, reset, pinctrl, and more.
Subsystems for networking, Bluetooth, USB, file systems, input, power management, logging, and settings.
west and CMake for project, module, build, flashing, and debugging workflows.
Board / SoC / shield abstractions to keep hardware differences in configuration layers.

Zephyr feels like an MCU-sized cousin of embedded Linux: it borrows many Linux engineering ideas, but moves expensive runtime probing into build-time generation.

Why Devicetree matters

Devicetree is central to Zephyr.

In Linux, DTS is compiled into DTB, passed to the kernel, and parsed at runtime for driver matching and probing. That is reasonable for MPU-class systems, but too heavy for many MCUs.

Zephyr processes DTS and overlays during the build, generates headers such as devicetree_generated.h, and exposes hardware information through DT_ macros. Most hardware selection is settled at compile time, so runtime discovery stays light.

This gives Zephyr several benefits:

Hardware description is separated from application code.
Board changes mainly touch DTS / overlay files.
Drivers expose unified APIs.
Unused drivers and subsystems can be trimmed.
Application code does not need to know every register, pin, or vendor HAL detail.

For example, an LED or button in a traditional FreeRTOS + vendor HAL project may involve CubeMX configuration, GPIO init, interrupts, debounce logic, callbacks, and application code. In Zephyr, much of that can live in DTS and standardized subsystems, while application code handles events.

Why application code becomes cleaner

Traditional MCU projects often mix hardware init, pin numbers, interrupts, debounce, timers, state machines, UART redirection, event queues, and business logic in the same layer.

That is fast at the beginning, but it becomes painful when there are more peripherals, boards, and product variants.

Zephyr tries to separate them:

Hardware wiring goes into DTS / overlays.
Feature switches go into Kconfig / prj.conf.
Drivers live in Zephyr mainline or modules.
Applications handle business events.

For multi-board and multi-chip projects, the ideal is to change DTS instead of changing main.c.

Resource cost needs context

Zephyr may use more Flash than a minimal FreeRTOS project because it brings drivers, subsystems, and device objects. But that is infrastructure, not just overhead.

Once you add buttons, encoders, input devices, logging, or multiple drivers, that infrastructure is reused. FreeRTOS projects often start smaller, but every new peripheral may add custom state machines and glue code.

RAM also depends on configuration. FreeRTOS reports may include reserved heap and stacks; Zephyr often relies more on static objects and link-time trimming. The only fair comparison is with the same feature set and realistic configuration.

How to choose

Choose FreeRTOS when the hardware is fixed, resources are tight, the team knows the kernel well, and you only need scheduling primitives.

Choose RT-Thread when you need stronger domestic MCU support, Chinese documentation, ready BSPs, and a richer component ecosystem without taking on the full Zephyr learning curve.

Choose Zephyr when you need cross-board reuse, long-term maintainability, unified drivers, standardized subsystems, and a path closer to Linux-style embedded engineering.

When not to use Zephyr

Zephyr is not a silver bullet.

Avoid jumping into Zephyr when:

The project has one fixed board and simple features.
The team has no time to learn Kconfig and Devicetree.
The target chip or board has weak upstream support.
The product depends heavily on a vendor’s closed SDK.
The project is already stable in production.
The team is not ready for Zephyr’s build and debugging workflow.

A safer path is to start with a well-supported board, run LED, UART, GPIO, input, and I2C / SPI examples, then decide whether to migrate real projects.

Why reading good code matters in the AI era

AI can generate candidate code, but engineers still merge it, flash it, and ship it to customer devices.

The scarce ability is not typing more code, but judgment: why this abstraction exists, whether a driver interface is maintainable, whether a generated patch is production-safe, and whether a configuration change affects other boards.

Zephyr is valuable even if you do not use it immediately. Reading its subsystems, Devicetree bindings, Kconfig layout, and driver organization gives you an industrial embedded architecture reference.

Summary

FreeRTOS, RT-Thread, and Zephyr are not three interchangeable products.

FreeRTOS solves scheduling. RT-Thread adds a richer component ecosystem and strong domestic MCU support. Zephyr tries to reorganize MCU software engineering around unified subsystems, Devicetree, and application portability.

For a small fixed device, FreeRTOS may be the best answer. For domestic MCU product lines, RT-Thread is practical. For multi-platform, multi-board, long-lived products, Zephyr deserves serious investment.

References:

How to Choose an Embedded Development Environment in 2026: Keil, STM32CubeIDE, VS Code, and AI Collaboration

Wed, 22 Apr 2026 23:05:00 +0800

If you still work on microcontrollers or embedded systems, you will quickly run into a very practical question: in 2026, when AI-assisted coding has become increasingly common, what development environment actually makes sense?

On the surface, this looks like a comparison between several IDEs. But what it really asks is something else: do you want a tool that can simply get the project running, or a workflow that balances ecosystem compatibility, coding experience, and AI collaboration?

Seen from that angle, the answer is usually not to pick one out of Keil, STM32CubeIDE, VS Code, and CLion, but to recombine the parts each one does best.

First look at the main options and what each one really solves

In embedded development, the familiar names are still more or less the same:

Keil
STM32CubeIDE
VS Code
CLion

If you go back even further, people will still mention IAR. But for this discussion, what matters less is who has the oldest pedigree, and more who actually fits today’s development reality.

Keil: strong ecosystem, dependable entry point, but clearly outdated editing experience

Keil is still hard to avoid today, and the reason is simple: it is everywhere.

Whether you look at legacy company projects, online tutorials, shared examples, or older codebases, a huge amount of embedded work is still organized around Keil. Its build, download, and debug workflow remains mature, and if your main goal is to get code running on a board, it is still a very short path.

Its problems are just as obvious:

dated interface
average editing experience
not a natural home for AI-assisted coding

So Keil feels more like a project entry point and debugging foundation than an ideal editor for a 2026 coding experience.

STM32CubeIDE: friendly for STM32, but more of a learning and quick-start tool

If you mainly live inside the STM32 ecosystem, STM32CubeIDE is often the first environment you touch.

Its strengths are straightforward:

beginner-friendly onboarding
convenient peripheral configuration and project generation
a fairly complete debug chain

For students, beginners, and early project setup, that experience is direct and good enough.

But once you move into longer-running projects, heavier collaboration, and more customized workflows, its limitations become more visible. In commercial work or more complex team environments, it may not be the most comfortable primary environment.

So it fits better as a quick-start and STM32-centric all-in-one tool than as a long-term primary editor.

VS Code: not really an IDE, but increasingly strong in the AI era

Strictly speaking, VS Code is not a traditional IDE. More accurately, it is an extensible code editor.

That gives it a built-in dual nature.

Its weaknesses are:

it needs plugins and setup
it is not beginner-friendly enough
it cannot replace the full embedded IDE workflow out of the box

But its real strengths come from the same place:

strong extensibility
a much more modern coding experience
better highlighting, navigation, search, and refactoring
stronger momentum around AI tools and agent workflows

At this stage, many developers no longer just want something that lets them write code. They want to know whether AI collaboration can fit naturally into the same environment. From that perspective, the advantage of VS Code is hard to miss.

CLion: good experience, but not central enough in embedded practice

CLion often comes up because its C/C++ coding experience has long been considered solid.

But for many embedded developers, the question is not whether it is good. The question is whether it is worth switching to:

relatively fewer people use it in embedded workflows
it does not connect to existing embedded project ecosystems as directly as Keil
it may not offer a more practical AI-collaboration advantage than VS Code

So it feels more like a “theoretically good option” than the most natural center of a mainstream embedded workflow today.

A more practical answer: let Keil handle build and debugging, let VS Code handle coding

If you break these tools apart by role, a much more pragmatic conclusion appears:

use Keil to preserve existing project compatibility, build, flashing, and debugging
use VS Code for everyday coding, search, navigation, and AI collaboration

The value of this combination is that it does not try to force one tool to do everything. Instead, it puts each tool back in the role it is best at.

For many embedded projects, the Keil ecosystem is simply not optional. If that is true, then instead of forcing everything back into Keil, it makes more sense to treat it as the backend build-and-debug entry point, while handing the real editing experience to VS Code.

Why this combination makes more sense in the AI era

Today, the dividing line between environments is no longer just whether the editor feels smooth. It is whether AI can plug into the workflow naturally.

VS Code has several very practical strengths here:

more active support for AI plugins and agents
a code browsing experience better suited for AI reading and modifying projects
easier integration with modern plugin ecosystems

That means some of the most painful parts of embedded development can start to be offloaded to AI:

finding functions and call chains in an existing project
quickly generating initialization code
adding a simple UART print
explaining the structure of old projects
making small, localized edits in existing files

These tasks were never impossible before. They were just awkward. The meaning of VS Code is not only that it looks better. It is that it can more naturally become the workbench for AI collaboration.

The key patch: connect VS Code to Keil projects with plugins

Whether this workflow works in practice depends on one thing: can you actually connect VS Code to a Keil project?

A very practical class of plugins does exactly that by letting VS Code read Keil project structure and call Keil backend programs from inside the editor for tasks such as:

opening a project
building
downloading

That way, you do not have to constantly jump between two interfaces just to write code. You only return to Keil for the heavier debugging work such as stepping, breakpoints, and register inspection.

The real value of these plugins is not merely saving a few window switches. It is making the workflow continuous.

Do not overlook the basic C/C++ plugin setup

If you want to use VS Code as the main embedded editor, one basic but often ignored point is this: you must set up the core C/C++ plugin and project indexing properly.

Otherwise, you will run into a series of issues that seriously hurt the experience:

jump-to-definition does not work
false red underlines appear
completion quality is poor
header relationships become messy

Many people assume this means VS Code is not suitable for embedded work. In practice, it is often just that the indexing and plugin configuration are not connected correctly.

Once that layer is configured properly, VS Code can actually deliver on its strengths in reading large projects, searching symbols, and using AI to assist with targeted code changes.

Who this workflow fits best

I think this combination works especially well for the following groups.

1. People who already have a large amount of Keil-based projects

If your company projects, course materials, or historical code all revolve around Keil, there is no reason to throw that ecosystem away just for the sake of looking modern. Keep Keil, then add VS Code as the front end. That is usually the lowest-cost transition.

2. People who want AI to help with embedded coding

If you already like using AI to explain functions, generate boilerplate, or make local logic changes, VS Code will take on that role more naturally than traditional embedded IDEs.

3. People who want to balance learning materials and real projects

Many tutorials are still built around Keil, but your own workflow does not need to stay stuck in that era. Treat Keil as the compatibility layer and VS Code as the productivity layer, and the balance becomes much better.

Closing

By 2026, the key question in embedded development environments is no longer just which IDE has more features. It is which combination best fits how people actually work today.

If you only want to get started quickly, STM32CubeIDE still has its place. If you need to inherit a large amount of existing engineering reality, Keil is still unavoidable. But if you also want to bring in a modern editing experience and AI collaboration, the more practical answer is often this:

let Keil handle build and debugging, and let VS Code handle writing code.

It may not be the only answer, but it is very likely one of the least awkward answers available today.

CH347 Resource Guide: Drivers, Tools, and SPI Flash Programming

Fri, 03 Apr 2026 10:00:00 +0800

This post summarizes the CH347 resources I use most often, with one goal: get you from setup to debugging/programming as quickly as possible.

If you are new to CH347, prepare your environment in this order:

Check the official product page first
Install the correct driver for your use case
Prepare an SPI Flash tool and verify connectivity

Official Entry

CH347 product page: https://www.wch.cn/products/CH347.html

It is best to download from the official page first, to avoid outdated or unknown-source driver packages.

Common Drivers

1) `CH341PAR.EXE`

Purpose:

USB-to-JTAG / SPI / I2C / Parallel / GPIO interface driver

Typical use:

Multi-protocol communication and low-level interface debugging with CH347

2) `CH343SER.EXE`

Purpose:

Vendor Windows driver for high-speed USB-to-Serial

Typical use:

Using CH347 mainly as a serial tool, especially at higher baud rates

SPI Flash Programming Tool

AsProgrammer: https://github.com/nofeletru/UsbAsp-flash

Common tasks:

Detect SPI NOR Flash
Read chip ID
Back up original firmware
Erase / write / verify firmware

Recommended Workflow (to avoid common mistakes)

After installing drivers, replug the device and confirm detection in Device Manager.
Before first write, do one full read + backup of the original contents.
Always run verify after writing. Do not rely only on a “write successful” message.
If the chip is not detected, check power, voltage level, and wiring before checking software settings.

Quick Troubleshooting

Device is plugged in but not visible in tools: usually driver loading issues, or a power-only USB cable.
Device is detected but read/write fails: first check wiring order, shared ground, and power stability.
Unstable behavior at high speed: lower read/write speed first, then increase gradually after stability is confirmed.

Summary

CH347 is not hard to use. The key is to get four things right: driver, tool, wiring, and verification.

The resources above cover most beginner and day-to-day maintenance scenarios, and should get you to a stable workflow quickly.

Embedded on KnightLi Blog

How to Choose Between FreeRTOS, RT-Thread, and Zephyr: Architecture Differences and Use Cases

Bottom line

FreeRTOS: small, familiar, deterministic

RT-Thread: stronger domestic MCU coverage and components

Zephyr: an embedded system engineering platform

Why Devicetree matters

Why application code becomes cleaner

Resource cost needs context

How to choose

When not to use Zephyr

Why reading good code matters in the AI era

Summary

How to Choose an Embedded Development Environment in 2026: Keil, STM32CubeIDE, VS Code, and AI Collaboration

First look at the main options and what each one really solves

Keil: strong ecosystem, dependable entry point, but clearly outdated editing experience

STM32CubeIDE: friendly for STM32, but more of a learning and quick-start tool

VS Code: not really an IDE, but increasingly strong in the AI era

CLion: good experience, but not central enough in embedded practice

A more practical answer: let Keil handle build and debugging, let VS Code handle coding

Why this combination makes more sense in the AI era

The key patch: connect VS Code to Keil projects with plugins

Do not overlook the basic C/C++ plugin setup

Who this workflow fits best

1. People who already have a large amount of Keil-based projects

2. People who want AI to help with embedded coding

3. People who want to balance learning materials and real projects

Closing

CH347 Resource Guide: Drivers, Tools, and SPI Flash Programming

Official Entry

Common Drivers

1) CH341PAR.EXE

2) CH343SER.EXE

SPI Flash Programming Tool

Recommended Workflow (to avoid common mistakes)

Quick Troubleshooting

Summary

1) `CH341PAR.EXE`

2) `CH343SER.EXE`