读前一句话：
这篇文章讲的是 RTOS 选型，但你只需要记住一件事：
FreeRTOS 是一把锤子，Zephyr 是一个工厂，RT-Thread 是一套家具。
你需要哪个，取决于你要盖的是什么房子。
如果你在嵌入式领域待过三年以上，一定经历过这个场景：
新项目启动，架构讨论会上有人说“上 FreeRTOS 吧，简单”，另一个人说“Zephyr 更现代，长期维护更好”，还有人悄悄补一句“RT-Thread 在国内生态挺好的”。
然后大家沉默了五秒钟，开始争。
这场争论为什么总是没有结果？
因为这三个 RTOS 从诞生的第一天起，就不是在解决同一个问题。
三个人，三条路，同一个起点
时间拨回到 2003 年。
一个叫 Richard Barry 的英国嵌入式工程师，在帮客户做项目时陷入了一个反复出现的困境：客户需要一个能跑多任务的操作系统，但口袋里只有一块内存极其有限的单片机。
商业 RTOS？VxWorks 的授权费能买一辆车。µC/OS-II 的 license 也不便宜，而且还不能随便商用。
他决定自己写一个。
2003 年，Richard Barry 创立了 FreeRTOS 项目，在此后十余年里，他通过自己的公司 Real Time Engineers Ltd. 独立开发和维护这个项目。
核心内核只有三个 C 文件。就这样，FreeRTOS 的哲学从第一行代码开始就已经确定：极简，够用，能跑就行。关于FreeRTOS更多的故事可以看下一个人写了23年的操作系统，今天跑在全球数十亿颗芯片上。
三年后的中国，2006 年，另一个场景在同时发生。
一个叫熊谱翔的工程师，正在为国内嵌入式项目选 OS，同样陷入了痛苦。他对当时数种开源嵌入式操作系统并不满意。他理想中的嵌入式操作系统，是类似 UNIX 系统那样拥有优雅代码风格的内核，包含可裁剪的组件，同时开放、易得、POSIX 标准兼容。
2000 年前后，他接触了 VxWorks、NucleusPLUS、ThreadX 等商业 RTOS，深刻体会到“东西确实是好东西，稳定可靠，但并不开放”。
2006 年，他创建了 RT-Thread 嵌入式操作系统，此后十余年持续推进其演化，从内核到 Shell、文件系统、UI 框架，到后来的 RT-Thread Smart 微内核系统。关于RT-Thread更多的故事可以看下他一个人，用一年时间，写出了中国装机量最大的操作系统。
还有第三条线索，更晚、更大、更复杂。
Zephyr 的起源，要追溯到比利时一家叫 Eonic Systems 的公司在 1990 年代末开发的 Virtuoso RTOS，这是一个专为数字信号处理设计的小型抢占式内核。2006 年，Wind River（VxWorks 的母公司）收购了 Eonic Systems，获得了 Virtuoso 的技术。
2015 年，Wind River 以此为基础，推出了名为 Rocket 的轻量级 RTOS，专为资源受限的 IoT 设备设计。到了 2016 年，Wind River 将 Rocket 捐献给 Linux 基金会，Zephyr 项目由此诞生。
Zephyr 项目的发起成员包括 Intel、Wind River、Synopsys 和 NXP，目标是打造一个被芯片厂商和嵌入式社区共同采纳的开源 RTOS。关于Zephyr更多的故事可以看下一个被巨头扔掉的内核，十年后成了嵌入式行业最热的RTOS。
一个英国工程师的个人作品，一个中国工程师对国产开源的执念，一个由大公司主导的 Linux 基金会项目。
三条不同的路，走到今天，形成了嵌入式世界里最重要的三角关系。
它们到底有多不一样？
如果你把 FreeRTOS、Zephyr、RT-Thread 各自的源码下载下来，第一感觉就能感受到设计哲学的差异。
FreeRTOS：一把锋利的锤子
一个有用的思考框架是：FreeRTOS 是一个库，而 Zephyr 是一个平台。使用 FreeRTOS，你自己决定所有东西如何组合在一起。
FreeRTOS 在 Cortex-M4 上使用 GCC 13、-Os 优化，最小 scheduler 的 Flash 占用约 9KB、RAM 约 2KB。
这意味着什么？意味着你有一个 32KB Flash 的 STM32F030，还能跑 RTOS。
它的核心功能只有这几件事：任务调度（抢占式 + 时间片）、队列、信号量、互斥量、软件定时器。其余的——TCP/IP、文件系统、蓝牙——你自己找库，自己集成。
这叫“够用”，也叫“什么都要自己搞”。如果你经常需要与这些底层技术文档打交道，你会发现 FreeRTOS 的优点和缺点都源于此。
乐鑫（Espressif）为什么选 FreeRTOS？
这是一个很有代表性的真实案例。
ESP32 是一颗双核芯片，内置两个 Xtensa LX6 核心，均运行在 240MHz。乐鑫把这两个核心分工得很清楚：Core 0 叫 PRO_CPU（协议核），负责跑 Wi-Fi 和蓝牙协议栈；Core 1 叫 APP_CPU（应用核），跑你的业务逻辑。
要管理两个核心上的任务调度、核间通信、中断优先级，必须有一个 RTOS 来统一协调。
乐鑫选择了 FreeRTOS，并在其基础上做了 SMP（对称多处理）改造，形成了 ESP-IDF 中的定制版 FreeRTOS。这个改造并不简单——原版 FreeRTOS 只支持单核，Vanilla FreeRTOS 的临界区保护靠的是关中断，但在双核上，关掉 Core 0 的中断对 Core 1 毫无影响，所以乐鑫用自旋锁（spinlock）重新实现了临界区机制。
选 FreeRTOS 而不是其他 RTOS，原因很直接：
- MIT 许可证，商用零成本
- 开发者基础最大，Arduino 社区、Maker 群体已经大量熟悉 FreeRTOS API
- 内核足够精简，留下足够空间给 Wi-Fi/BT 协议栈和用户代码共存
- 对接 AWS IoT 的路径最短，贴合乐鑫在 IoT 市场的商业定位
结果就是：今天你用 Arduino IDE 写 ESP32，看起来是在写 Arduino 代码，但 setup() 和 loop() 其实是跑在 FreeRTOS 的一个任务里的。你在不知情的情况下，已经用上了 RTOS。
Zephyr：一座可配置的工厂
与 FreeRTOS 的极简主义不同，Zephyr 配备了丰富的内置组件和模块化、高度可配置的设计。
Zephyr 支持多种架构，包括 ARM、x86、RISC-V 和 ARC，内置设备驱动、蓝牙协议栈，以及 Trusted Execution 等安全特性，是 Intel、Nordic Semiconductor、NXP 等公司的官方支持 RTOS。
Zephyr 用 DeviceTree（设备树）+ Kconfig + CMake 的三层配置系统来描述硬件和内核配置——这套系统直接从 Linux 内核移植过来。
它的代价是：Zephyr 需要更大的前期投入，学习曲线更陡，构建系统更复杂，如果你来自裸机或 FreeRTOS 背景，会感觉它很“重”。Zephyr 通常需要更多的 Flash 和 RAM，这是它提供的结构性和可移植性的代价。
Zephyr 的内核镜像在相同条件下约占 18KB Flash 和 4KB RAM。
但当你需要在同一块板子上同时跑 BLE + LoRaWAN + TLS + OTA 时，Zephyr 的原生支持会让你庆幸自己当初选了它。
RT-Thread：一套中国制造的完整家具
RT-Thread 是一个模块化、面向对象的 RTOS，架构从 3KB Flash 的极简内核（Nano 版）到拥有超过 450 个软件包的完整 IoT OS（Standard 版），跨越极大的资源范围。最小内核仅需 1.2KB RAM 和 3KB Flash。
RT-Thread 的设计哲学更接近“UNIX 小内核 + 丰富周边组件”的路线。它在内核层用 C 实现了面向对象的设计——所有内核对象（线程、信号量、消息队列、设备……）统一抽象为对象基类，可以用同一套接口遍历和管理。
这个设计在当时的开源 RTOS 里相当超前，也是 RT-Thread 能够在“极简内核”上叠加“丰富组件”的基础。如果你对内核源码分析感兴趣，RT-Thread 的这种设计非常值得深入阅读。
在国内，RT-Thread 还有一个独特的生态优势： Keil MDK、CubeMX、RT-Thread Studio 的深度集成，以及覆盖国产芯片（GD32、CH32、ESP32、全志等）的广泛 BSP 支持。这是 FreeRTOS 和 Zephyr 都做不到的。
商业化的代价：谁控制着你的 RTOS？
这是一个很多人忽略的维度，但它在 2023 年之后变得越来越重要。
FreeRTOS 在 2017 年被 Amazon 收购，ThreadX 则被 Microsoft 收购，两者都以各自的 IoT 云服务体系为背景。一些开发者担心这两个公司会把项目引向更符合商业利益的方向，开源性的独立性存在疑问。
尽管 Amazon 维持了 FreeRTOS 的开源状态，源码依然可以在 GitHub 免费获得，但 OTA 更新、AWS IoT Device SDK 集成、云端管理等附加服务只在 Amazon 的体系里才完整可用。
这是一把双刃剑。
如果你的产品要接入 AWS IoT，FreeRTOS 的路是最平滑的——AWS 把那条路修得很宽。但如果你不想绑定 AWS，就得自己往其他方向搭桥。
Zephyr 的处境更透明一些。Linux 基金会托管意味着没有单一企业控制方向，Intel、Nordic、NXP、Renesas 等多家公司都是 Platinum 成员，项目的治理是真正的委员会制。截至 2025 年 6 月，Renesas 和 Wind River 都升级到了 Platinum 成员级别，进一步扩大了 Zephyr 的硬件支持范围。
RT-Thread 的情况在三者中最特殊——它诞生和成长在中国，核心维护者是中国工程师，主要社区也在国内。在“国产替代”的大背景下，这既是优势（国内政策导向，国产芯片原生支持），也是一个需要认真评估的变量（国际社区参与度相对较低，文档英文版质量参差不齐）。
没有哪个选择是完全中立的。
你选的是技术，也是在选谁来控制你的技术命脉。
实际场景中，他们各自擅长什么？
理论讲完了，来说最关键的：不同项目，选哪个？
场景一：资源极度受限的 MCU（<64KB Flash）
选 FreeRTOS，或者 RT-Thread Nano。
这个场景下，Zephyr 的最小镜像都压力很大。FreeRTOS 的 9KB Flash 起步，RT-Thread Nano 的 3KB Flash 起步，是真正能塞进去的选择。
FreeRTOS 的优势是文档和社区：遇到任何问题，Stack Overflow 和官方论坛几乎一定有答案。
RT-Thread Nano 的优势是国产芯片支持：如果你用的是 GD32、CH32 这类国产 MCU，RT-Thread 的 BSP 往往比 FreeRTOS 的更完整、更新。
场景二：需要 BLE + 联网 + OTA 的 IoT 产品
优先考虑 Zephyr，其次是 RT-Thread Standard。
Nordic nRF52/nRF91 系列已经把 Zephyr 作为官方第一支持 RTOS——Nordic 的 nRF Connect SDK 本质上就是一个 Zephyr 发行版。如果你用 nRF 做 BLE 产品，用 Zephyr 几乎是必然的选择。
RT-Thread 的软件包生态（450+）在国内的 IoT 场景下也很完整，MQTT、CoAP、HTTP、TLS 一应俱全，且中文文档质量明显更高，国内工程师上手更快。
FreeRTOS 在这个场景下需要自己集成大量第三方库，工程量会显著增加。
有一个例外值得单独说：如果你用 ESP32 做联网产品，FreeRTOS 反而是最自然的选择。乐鑫的 ESP-IDF 本身就以 FreeRTOS 为底座，Wi-Fi、BLE、MQTT、OTA 全都以 FreeRTOS 任务的形式原生集成。你不需要自己搭建这套并发架构——乐鑫已经帮你搭好了。这是 ESP32 生态独特的优势，其他平台复现不了。
场景三：多芯片平台，需要跨平台复用代码
Zephyr 的优势无可替代。
DeviceTree + Kconfig 的组合，让你在换芯片时，应用层代码几乎不需要改动——你只需要换一个 board overlay 文件，重新编译。
这在大型工业产品线里价值极高：同一套固件框架，支持 STM32、nRF、ESP32、NXP RT 系列……这是 FreeRTOS 和 RT-Thread 都没有原生解决的问题。
场景四：快速原型 + 国内量产
RT-Thread 是最省心的选择。
RT-Thread Studio 提供了类似 STM32CubeIDE 的一键工程生成，配上 RT-Thread 的包管理器，添加一个 LVGL 显示组件、一个 MQTT 客户端，就是几分钟的事情。
国内供应链、国内芯片、国内文档、国内社区——对国内中小团队来说，这个生态优势是实实在在的。
场景五：安全认证（医疗 / 工业 / 汽车）
这三个都不是最佳选择——但如果必须选，倾向 Zephyr。
对于医疗（IEC 62304）、汽车（ISO 26262）、工业（IEC 61508）、航空（DO-178C）等安全关键场景，通常需要经过预认证的 RTOS。SafeRTOS、ThreadX 和 RTEMS 都有相关认证。
Zephyr 在积极推进 PSA Certified 和 SESIP 等安全认证，Linux 基金会背景也让它在合规层面更容易被大企业接受。FreeRTOS 有商业版 SAFERTOS 可选，但那是另一套产品，需要付费。
一张表让你看清全局
| 维度 |
FreeRTOS |
Zephyr |
RT-Thread |
| 内核大小（最小） |
~9KB Flash / 2KB RAM |
~18KB Flash / 4KB RAM |
3KB Flash / 1.2KB RAM（Nano） |
| 许可证 |
MIT |
Apache 2.0 |
Apache 2.0 |
| 背后支持方 |
Amazon AWS |
Linux 基金会（多厂商） |
独立社区（中国） |
| 学习曲线 |
低 |
高 |
中（国内资料丰富） |
| 生态包数量 |
较少（需自集成） |
丰富（原生驱动+协议） |
450+ 软件包 |
| 国产芯片支持 |
一般 |
一般 |
优秀 |
| 跨平台移植 |
需手工适配 |
DeviceTree 原生支持 |
一般 |
| 适合规模 |
小型 MCU 到中型产品 |
中型到复杂 IoT 系统 |
小型到中型产品 |
| 中文资料 |
一般 |
较少 |
丰富 |
让人沉默的细节
在 AWS 宣布接管 FreeRTOS 之前，Richard Barry 用“极其有限的人力资源”，独自维护这个关键基础设施长达 15 年。
一个人，15 年，几乎不停歇地回复 issue、合并 PR、写文档。
全球数亿台设备的实时调度，就跑在这个一个人维护的三个 C 文件上。
而熊谱翔在 2021 年的一篇回顾文章里这样写道：他希望打造的操作系统，是“路虽远行则将至，事虽难做则必成”——一个中国工程师对开源的执念，用了整整 15 年，才让 RT-Thread 出现在全球数千种商业产品里。
Zephyr 的故事则更像一部合奏：它没有一个孤独英雄，它是几十家公司、几千名工程师的集体作品——代价是它的方向有时候比你想象中移动得更慢，但它也比任何一家公司都更难死去。
没有哪个 RTOS 是完美的。
它们都是在特定条件、特定约束下，由特定的人做出的特定选择。选型的本质，不是找最好的，而是找最匹配的。
选型的终极建议
一句话：
先看芯片，再看连接需求，最后看团队背景。
- 芯片原厂推荐什么，通常有理由的。Nordic → Zephyr，乐鑫 ESP32 → FreeRTOS，国产 MCU → RT-Thread，这几条线基本不会错。
- 有复杂联网需求（多协议、安全认证、跨平台），Zephyr 的前期投入值得。
- 团队以前用 FreeRTOS 用得很熟，没有强迫换的理由，就别换。知识债比技术债更难还。
- 国内中小团队做消费类产品，RT-Thread 的国内生态会让你省掉大量踩坑时间。
最后一条是真心话：
不要因为选 RTOS 而拖延立项。
三个都是成熟工具，任何一个都能帮你把产品做出来。真正决定产品成败的，不是 RTOS，是你在上面写了什么。
云栈社区一直关注这类来自一线的技术选型难题，如果你在某个项目上深度使用过其中一个，踩过坑，有自己的判断——欢迎来分享你的看法，我们很想听。
发表于 2 小时前
|
查看: 5|
回复: 0
