嵌入式 on KnightLi的博客

FreeRTOS、RT-Thread、Zephyr 怎么选？三大 RTOS 架构差异与适用场景

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

FreeRTOS、RT-Thread、Zephyr 经常被放在一起比较，但这三个项目其实不在同一个层级。

如果只问“哪个 RTOS 更好”，答案很容易跑偏。更准确的问题应该是：你的项目到底需要一个轻量调度内核、一个带国产 MCU 生态的 RTOS，还是一个面向跨平台工程化的完整嵌入式操作系统。

从这个角度看，三者的定位可以先粗略分成这样：

FreeRTOS：行业标配级调度内核，外加 AWS 维护的一组 IoT 库。
RT-Thread：内核加较完整组件生态，对国内长尾 MCU 和中文社区更友好。
Zephyr：Linux Foundation 托管的完整 RTOS，强调统一子系统、设备模型、Devicetree 和跨厂商应用复用。

先说结论

如果项目只是小 MCU、简单任务调度、信号量、队列、定时器，FreeRTOS 仍然是最稳的选择之一。

如果项目主要面向国内 MCU，尤其是 AT32、HC32、N32、APM32、HT32、合宙等长尾芯片，并且团队希望中文资料、BSP 和社区反馈更顺手，RT-Thread 很有优势。

如果项目需要跨芯片、跨板卡、跨厂商复用应用层代码，并且愿意接受 Kconfig、Devicetree、west、驱动模型带来的学习成本，Zephyr 更像是面向未来工程化的路线。

所以这不是“谁淘汰谁”的问题，而是三种工程抽象层级不同。

FreeRTOS：最强的是轻量和确定性

FreeRTOS 的核心优势，是足够小、足够熟、足够普及。

它的主仓库 FreeRTOS-Kernel 重点就是内核、移植层和核心 RTOS 机制。任务调度、信号量、消息队列、事件组、软件定时器、内存分配策略，这些是绝大多数项目真正使用的部分。

FreeRTOS 的好处很直接：

MCU 覆盖极广。
学习资料和工程案例最多。
可以很容易塞进芯片厂商 SDK。
适合资源很紧、需求很明确的小系统。
出问题时定位路径短，很多团队已有经验积累。

AWS 收购 FreeRTOS 后，又围绕它维护了 coreMQTT、coreHTTP、OTA、Device Shadow、Jobs、Defender 等 IoT 相关库。FreeRTOS 202406 LTS 也把内核、TCP、MQTT、HTTP、OTA 等组件纳入长期支持路线。

但 FreeRTOS 的边界也很清楚：它本质上不是一个“完整 OS 平台”。GPIO 怎么抽象、UART 怎么读写、I2C 怎么挂设备、不同厂商 HAL 怎么统一，FreeRTOS 自己并不负责。

换句话说，FreeRTOS 给你的主要是内核。驱动层、设备模型、板级抽象和应用框架，要么依赖芯片厂商 SDK，要么由团队自己搭。

这不是缺陷，而是设计选择。它让 FreeRTOS 非常灵活，也让它很容易和 ST、NXP、TI、瑞萨、乐鑫等厂商 SDK 组合。但代价是：换芯片、换板子、换 HAL 时，应用层往往也会被牵连。

RT-Thread：优势在国内 MCU 和组件生态

RT-Thread 比 FreeRTOS 更接近一个完整 RTOS。

它不只是调度器，还提供文件系统、网络协议栈、设备框架、USB、传感器框架、组件包和工具链。对很多国内团队来说，RT-Thread 的中文文档、ENV 工具、社区氛围和国产 MCU BSP 是很实际的优势。

尤其在国内长尾 MCU 上，RT-Thread 的支持面很有价值。很多项目并不使用头部国际厂商芯片，而是会选 AT32、HC32、N32、APM32、HT32、合宙、先楫等国产 MCU。对这类项目，RT-Thread 往往能更快拿到可跑的 BSP 和中文资料。

RT-Thread 适合这些场景：

团队主要使用国产 MCU。
需要中文社区和本土资料。
需要比 FreeRTOS 更完整的组件生态。
项目希望快速接入文件系统、网络、shell、设备框架等能力。
团队不想从零搭一套板级和驱动抽象。

但 RT-Thread 也有自己的限制。

第一，它的很多 BSP 仍然是围绕具体板卡和厂商库组织。虽然有设备框架，但从跨厂商统一硬件描述和应用层无感迁移的角度看，还没有达到 Zephyr 那种系统性。

第二，RT-Thread 对国内长尾 MCU 很友好，但在一些头部芯片和国际厂商主线维护上，Zephyr 的势头已经很强。比如乐鑫、Nordic、NXP、瑞萨等厂商，在 Zephyr 生态中的官方投入越来越明显。

第三，RT-Thread 的设备树路线还没有真正成为 MCU 侧的主流工作方式。它有 ofw 相关框架，但在 Cortex-M 这类 MCU 项目里，还不能像 Zephyr 那样形成贯穿构建系统、驱动匹配、应用层配置的统一机制。

所以 RT-Thread 的定位更像：在 FreeRTOS 之上补齐了很多常用系统组件，并且在国内 MCU 生态里非常实用。但它还不是 Zephyr 那种从构建、配置、驱动、设备模型到应用层都统一规划的工程平台。

Zephyr：不是“另一个 RTOS”，而是一套系统工程

Zephyr 容易被误解为“比 FreeRTOS 更复杂的 RTOS”。这个说法只说对了一半。

它确实更复杂，但复杂的原因不是单纯堆功能，而是它试图把 MCU 项目里长期散落在厂商 SDK、BSP、HAL、手写驱动、配置脚本里的东西，统一进一个操作系统工程。

Zephyr 的关键不只是调度器，而是这些东西：

Kconfig：管理功能开关和编译配置。
Devicetree：描述板级硬件和外设连接。
drivers：统一 GPIO、UART、SPI、I2C、ADC、DMA、clock、reset、pinctrl 等外设接口。
subsys：提供网络、蓝牙、USB、文件系统、输入、电源管理、日志、设置存储等子系统。
west 和 CMake：管理工程、模块、构建、下载和调试。
板卡 / SoC / shield 抽象：把硬件差异收敛到配置层。

这使得 Zephyr 更像一个“嵌入式 Linux 的 MCU 缩小版”：它继承了 Linux 世界的很多工程思想，但把运行时 probe 那套不适合小 MCU 的机制，改造成了编译期展开。

Zephyr 的 Devicetree 为什么关键

Devicetree 是理解 Zephyr 的关键。

在 Linux 里，DTS 通常会编译成 DTB，由 bootloader 传给内核，内核启动后再解析设备树、匹配驱动、执行 probe。这个运行时模型对 MPU 和大内存系统很合理，但对一颗几十 KB 到几百 KB RAM 的 MCU 来说太重。

Zephyr 的做法不一样。它在构建阶段处理 DTS / overlay，把硬件描述生成 devicetree_generated.h 这类头文件，再通过 DT_ 宏给驱动和应用使用。换句话说，硬件描述和驱动选择在编译期就基本确定，运行时不需要再做一套沉重的设备发现。

这个设计带来几个好处：

硬件描述和应用代码分离。
换板子主要改 DTS / overlay。
驱动通过统一 API 暴露给应用。
未启用的驱动和子系统可以被裁掉。
应用层不必直接关心具体寄存器、引脚和厂商 HAL。

比如一个 LED 或按键，在传统 FreeRTOS + 厂商 HAL 工程里，通常会散落在 CubeMX 配置、GPIO 初始化、回调、中断、去抖、状态机和应用代码里。到了 Zephyr，很多信息可以放进 DTS，应用层只通过 LED、GPIO 或 input 子系统接口处理事件。

这就是 Zephyr 的工程化价值：不是让简单 demo 看起来更短，而是让复杂项目的硬件差异尽量不污染业务代码。

应用层代码为什么会变干净

传统 MCU 工程里，应用代码经常混着这些内容：

硬件初始化。
GPIO 引脚号。
中断配置。
去抖逻辑。
定时器和状态机。
串口重定向。
事件队列。
业务处理。

项目一开始不大时，这样写很快。但随着外设变多、板卡变多、产品线变多，应用层会越来越像 BSP 的延伸。

Zephyr 的目标是把这些内容拆开：

硬件连接放到 DTS / overlay。
功能开关放到 Kconfig / prj.conf。
驱动放到 Zephyr 主线或模块。
应用只处理业务事件。

因此，同样是 LED 闪烁、按键短按、长按、双击、三击这类功能，在 Zephyr 里更容易变成“少量业务代码 + 配置文件”。换板卡时，理想状态是改 DTS，不改 main.c。

这对单板 demo 未必显得划算，但对多板卡、多芯片、多代产品的团队，价值会越来越明显。

资源占用不能只看第一眼

很多人第一反应是：Zephyr 这么大，资源占用肯定高。

这个判断要拆开看。

Zephyr 的 Flash 通常会因为统一驱动、子系统、设备模型而比裸 FreeRTOS 工程多一些。这部分不是纯“内核开销”，而是你买下了一套可复用基础设施。

比如 input 子系统、LED 驱动、GPIO 驱动、定时器、日志、设备对象等，都会占空间。但后续再加旋钮、编码器、更多按键、更多输入设备时，很多基础设施可以复用，不是每个功能都重新手写一套。

RAM 也类似。FreeRTOS 工程里常见的 heap 预留、任务栈预留、队列缓冲可能会让报表看起来更大；Zephyr 更强调静态对象和链接期裁剪。具体谁更省，要看配置、功能、编译选项和实际场景，不能只拿空工程对比。

更实用的判断方式是：

如果功能很少、板卡固定、资源极紧，FreeRTOS 可能更省。
如果外设多、板卡多、驱动复用多，Zephyr 的“基础设施成本”会被摊薄。
如果团队没有时间学习 Zephyr，复杂性本身就是成本。

三者怎么选

可以按项目形态来选。

选择 FreeRTOS

适合：

项目资源很紧。
只需要调度、队列、信号量、定时器。
硬件平台固定。
已经有成熟厂商 SDK。
团队对 FreeRTOS 很熟。
不需要跨厂商统一设备模型。

典型判断：你需要的是一个可靠内核，而不是一整套 OS 工程框架。

选择 RT-Thread

适合：

使用国产 MCU 较多。
需要中文社区和中文资料。
希望快速拿到 BSP、组件包和常用系统能力。
项目规模比纯 FreeRTOS 大，但还不想全面进入 Zephyr 学习曲线。
团队希望在本土生态里解决问题。

典型判断：你需要的是“FreeRTOS 之上更多组件 + 国产 MCU 友好生态”。

选择 Zephyr

适合：

项目要跨多块板、多颗芯片、多家厂商。
希望应用层尽量不绑死具体硬件。
重视长期维护和主线升级。
需要蓝牙、网络、USB、文件系统、输入、电源管理等统一子系统。
团队愿意学习 Kconfig、Devicetree、west 和 Zephyr 驱动模型。
未来希望和 Linux 工程思想接轨。

典型判断：你需要的是一套完整的嵌入式系统工程平台，而不仅是 RTOS 内核。

什么时候不该用 Zephyr

Zephyr 不是银弹。

这些情况下不建议上来就选 Zephyr：

项目只有一个固定板卡，功能很简单。
团队没有时间学习 Kconfig 和 Devicetree。
芯片或板卡在 Zephyr 主线支持很弱。
项目强依赖某个厂商 SDK 的私有闭源能力。
产品已经稳定量产，迁移收益不明显。
团队调试和构建环境还没有准备好。

Zephyr 的学习成本是真实存在的。它的错误信息、构建系统、Devicetree 绑定、Kconfig 依赖、module 管理，对传统裸机 / FreeRTOS 开发者来说都需要适应。

所以更合理的路线是：先选一块 Zephyr 主线支持好的开发板，用一个小功能跑通 LED、UART、GPIO、input、I2C / SPI，再决定是否迁移真实项目。

AI 时代为什么更要读好代码

现在很多人会说：有 AI 了，底层框架没必要学那么深，直接让模型写代码就行。

这个想法很危险。

AI 能把候选代码摆在你面前，但把代码合进去、烧进固件、交给客户设备运行的人，仍然是工程师。AI 不会为设备召回负责，人会。

嵌入式项目里，真正稀缺的不是“多写几百行代码”的能力，而是判断力：

这段代码为什么这么写？
这层抽象值不值得？
这个驱动接口能不能长期维护？
这个配置变更会不会影响别的板卡？
这段 AI 生成代码能不能进入量产固件？

Zephyr 的价值之一，就是提供了一套工业级嵌入式系统架构样本。即使最后项目不选 Zephyr，读懂它的子系统、设备模型、Devicetree、Kconfig 和驱动组织方式，也会提升你判断嵌入式架构好坏的能力。

总结

FreeRTOS、RT-Thread、Zephyr 不是同类产品的简单三选一。

FreeRTOS 是轻量、成熟、普及的 RTOS 内核，适合固定硬件和清晰任务调度场景。RT-Thread 是更完整的 RTOS 生态，尤其适合国内 MCU、中文社区和快速组件集成。Zephyr 则是更系统化的嵌入式操作系统工程，适合跨厂商、跨板卡、长期维护和应用层复用。

如果只做一个小设备，FreeRTOS 可能就是最省事的答案。如果做国内 MCU 产品线，RT-Thread 的生态会很实际。如果你面对的是多平台、多板卡、多外设和长期演进，Zephyr 值得认真投入。

真正的差距，不是 API 多几个少几个，而是工程抽象层级：FreeRTOS 解决调度，RT-Thread 补齐组件，Zephyr 试图重构 MCU 软件工程的组织方式。

参考链接：

2026 年嵌入式开发环境怎么选：Keil、STM32CubeIDE、VS Code 与 AI 协作

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

只要你还在做单片机或者嵌入式开发，很快就会遇到一个很现实的问题：到了 2026 年，在 AI 写代码已经越来越普遍的情况下，开发环境到底应该怎么选？

这个问题表面上像是在比较几个 IDE，实际讨论的却是另一件事：你到底是要一个“能把工程跑起来的工具”，还是一套“兼顾生态、编码体验和 AI 协作能力”的工作流。

如果按这个角度去看，答案往往就不是简单地在 Keil、STM32CubeIDE、VS Code、CLion 里选一个，而是重新组合它们各自最擅长的部分。

先看几个主流选项，各自解决什么问题

嵌入式领域这些年常见的环境，基本还是那几类：

Keil
STM32CubeIDE
VS Code
CLion

如果再往前追，当然还会有人提 IAR。只是从今天的讨论出发，更值得看的已经不是“谁资格最老”，而是谁更适合当前这套开发现实。

Keil：生态强、上手稳，但编辑体验已经明显落后

Keil 到今天仍然很难绕开，原因不复杂：它用得实在太广了。

无论是公司里留下来的老工程，还是网上大量教程、资料、示例工程，很多都还是围绕 Keil 组织的。它在编译、下载、调试这一整套流程上依然成熟，尤其是你真的要把板子跑起来时，它的路径非常短。

它的问题也同样明显：

界面老
编辑体验一般
不擅长承担 AI 辅助编码的主场

所以 Keil 更像是一个“工程入口和调试底座”，而不是一个面向 2026 年编码体验的理想编辑环境。

STM32CubeIDE：对 STM32 友好，但更多是学习和快速起步工具

如果你主要在 STM32 生态里活动，STM32CubeIDE 很容易成为第一个接触到的环境。

它的优点很明确：

上手友好
外设配置和工程生成方便
调试链路相对完整

对学生、新手和刚起步的项目来说，这套体验确实足够直接。

但一旦进入更长期、更多协作、更多定制的工程环境，它的局限也会慢慢暴露出来。尤其是在商业项目或者更复杂的团队工作流里，它未必是那个最舒服的主环境。

所以它更适合“快速启动”和“STM32 生态内的一体化体验”，不一定适合作为长期主力编辑器。

VS Code：严格说不是 IDE，但在 AI 时代优势越来越明显

VS Code 严格来说并不是传统意义上的 IDE，更准确地说，它是一个可扩展的代码编辑器。

这也意味着它天然有两面性。

它的弱点是：

需要插件和配置
对新手不够友好
不能开箱即用地替代嵌入式 IDE 全流程

但它真正强的地方，恰恰也在这里：

可扩展性强
编码体验明显更现代
语法高亮、跳转、搜索、重构体验更好
对 AI 工具和 Agent 工作流支持更积极

在今天这个阶段，很多人真正需要的已经不只是“能写代码”，而是“写代码时能不能顺手把 AI 协作接进来”。从这个角度看，VS Code 的优势几乎是肉眼可见的。

CLion：体验不错，但在嵌入式场景里不够主流

CLion 经常会被提到，因为它的 C/C++ 编码体验一直不差。

但对很多嵌入式开发者来说，它的问题不一定出在“好不好用”，而是“值不值得切过去”：

用的人相对少
与现有嵌入式工程生态连接不如 Keil 直接
在 AI 协作这件事上，也未必比 VS Code 更有现实优势

所以它更像是一个“理论上也能做得不错”的选项，但在今天的嵌入式主流工作流里，并不是最自然的那个核心。

更现实的答案：Keil 负责编译调试，VS Code 负责写代码

如果把上面这些工具拆开看，很容易得到一个更务实的结论：

用 Keil 保留现有工程生态、编译、下载和调试能力
用 VS Code 承担日常编码、搜索、跳转和 AI 协作

这套组合的价值在于，它不是试图用一个工具包打天下，而是让每个工具回到自己最擅长的位置。

对很多嵌入式工程来说，Keil 的生态根本绕不开。既然如此，与其强行把所有工作都塞回 Keil，不如承认它更适合作为后端编译调试入口；而真正的编辑体验，则交给 VS Code。

为什么这套组合在 AI 时代更有优势

到了今天，开发环境的分界线已经不只是“编辑器顺不顺手”，而是“它能不能自然接入 AI”。

VS Code 在这件事上有几个很现实的优势：

AI 插件和 Agent 支持更活跃
代码浏览体验更适合让 AI 读工程、改工程
更容易和现代插件生态结合

这意味着你可以把嵌入式开发里最痛苦的一部分工作，开始交给 AI 帮你分担：

在现有工程里找函数和调用链
快速生成一段初始化代码
帮你补一个串口打印
解释旧工程结构
在已有文件里做小范围修改

这些事情过去不是不能做，而是做起来不顺。VS Code 的意义不只是“更好看”，而是它更容易成为 AI 协作的工作台。

关键补丁：用插件把 VS Code 和 Keil 工程接起来

这套工作流能不能成立，核心不在口号，而在你能不能把 VS Code 和 Keil 工程接起来。

比较实用的一类插件思路，是让 VS Code 直接读取 Keil 工程结构，并在编辑器内部调用 Keil 后台程序完成：

打开工程
编译
下载

这样一来，你日常写代码不用频繁在两个界面之间来回切，只有到了更重的调试环节，再回到 Keil 里做单步、断点和寄存器观察。

这类插件真正有价值的地方，不只是“少切几个窗口”，而是它让工作流连续起来了。

不要忽视 C/C++ 基础插件配置

如果你打算把 VS Code 当作嵌入式主编辑器，一个非常基础但常被忽略的点是：一定要把 C/C++ 基础插件和工程索引配置好。

否则你会遇到一系列很影响体验的问题：

跳转不到定义
红线误报
补全不准
头文件关系混乱

很多人会误以为是 VS Code 不适合嵌入式，实际上往往只是工程索引和插件配置没接好。

一旦这部分配置完整，VS Code 才能真正发挥出它在阅读大型工程、搜索符号、配合 AI 辅助修改代码上的优势。

这套工作流最适合谁

我觉得下面这几类人，会特别适合这种组合式环境：

1. 已经有大量 Keil 工程的人

如果你公司项目、课程资料或者历史代码都围绕 Keil 展开，那就没必要为了“现代化”硬切掉原有生态。保留 Keil，再补一个 VS Code 前端，是迁移成本最低的做法。

2. 想用 AI 辅助写嵌入式代码的人

如果你已经习惯让 AI 帮你解释函数、补样板代码、改局部逻辑，那么 VS Code 会比传统嵌入式 IDE 更自然地承接这件事。

3. 想同时兼顾学习资料和真实项目的人

很多学习资料仍然建立在 Keil 上，但你自己的工作流未必要停留在那个年代。把 Keil 作为工程兼容层，把 VS Code 作为生产力层，会更平衡。

结语

到了 2026 年，嵌入式开发环境的关键问题，已经不再只是“哪个 IDE 功能更多”，而是“哪种组合最符合今天的工作方式”。

如果你只想快速起步，STM32CubeIDE 依然有它的位置；如果你要稳定接住大量既有工程，Keil 依然绕不开；但如果你还想把现代编辑体验和 AI 协作一起接进来，那么更现实的答案，往往是：

Keil 负责编译和调试，VS Code 负责写代码。

这不一定是唯一答案，但很可能是当下最不拧巴的一种答案。

CH347 开发常用资源整理：驱动、工具与 SPI Flash 刷写

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

这篇文章整理我在使用 CH347 时最常用的一组资源，目标是开箱就能开始调试和刷写。

如果你刚接触 CH347，建议按下面顺序准备环境：

先看官方产品页确认资料入口
按用途安装对应驱动
准备 SPI Flash 刷写工具并做连通性验证

官方入口

CH347 产品页：https://www.wch.cn/products/CH347.html

建议优先从官方页面进入下载区，避免拿到来源不明或版本过旧的驱动包。

常用驱动

1) `CH341PAR.EXE`

用途：

USB 转 JTAG / SPI / I2C / 并口 / GPIO 等接口驱动

适用场景：

你需要用 CH347 做多协议通信或底层接口调试时

2) `CH343SER.EXE`

用途：

USB 转高速串口 Windows 厂商驱动