MCU大厂接连出手，这个开源RTOS会一统天下吗？

“Zephyr会超过FreeRTOS，成为下一个RTOS王者吗？嵌入式工程师，是时候认真看看Zephyr RTOS了。”两年前就曾有工程师发问。

这几年，Zephyr势头非常猛。甚至有工程师认为，照这样的势头发展下去，Zephyr未来可能会一统江湖。

今年，Zephyr已经走过十年。最近，MCU厂商也在加大对Zephyr的支持力度，再给这个开源RTOS添了一把柴。

这些厂商，都在加码

TI：升级白金会员，全面加入Zephyr生态

10月1日，TI宣布宣布扩大Zephyr在其MCU、MPU和无线连接产品中的支持范围，同时，把自己在Zephyr Project里的会员级别升到了最高的白金会员。

事实上，TI不是刚开始支持Zephyr，而是从十年前诞生之初就开始支持Zephyr了。不过，过去，TI的Zephyr更多出现在部分产品、部分开发板或者特定软件包里。现在，则是进一步全面覆盖自己的产品，并希望提供一套统一、可面向量产的开发体验，避免软件碎片化。

以往，不同MCU厂商都有自己的SDK、RTOS、Driver和开发工具。硬件一换，软件工程往往也得跟着改。而通过支持Zephyr，开发者可以继续沿用原来的开源工作流，并把底层硬件迁到TI。

过去MCU厂商的软件生态通常是打包卖的。芯片、SDK、RTOS、IDE、编译器、Driver一套下来，开发者越用越深。而Zephyr换了一种方式。开发者先有一个Zephyr工程，再去决定底层跑哪家的MCU。

当然，这不代表TI自己的软件工具会消失，Zephyr更多是在上层把一部分开发方式统一起来。TI无线连接业务副总裁Marian Kost这次甚至直接把Zephyr称为TI打通软硬件壁垒工作中的“基石”。

Infineon：同样升级白金会员，把它带到汽车MCU中

英飞凌和TI同样在10月1日宣布，把Zephyr全面覆盖至TRAVEO、PSoC和AURIX，同时把自己在Zephyr Project里的会员级别升到了最高的白金会员。

英飞凌很早就在PSoC等产品上支持Zephyr，不过这次英飞凌把汽车MCU放到了很显眼的位置。目前英飞凌已经在TRAVEO、PSoC上推进Zephyr支持，同时还把AURIX和TriCore带了进来。

这和很多人过去对Zephyr的印象已经不太一样。Zephyr早期最常见的应用还是IoT、无线MCU和各种资源受限设备。AURIX则是另一类产品，长期用于汽车控制、实时控制和安全相关系统，对可靠性、生命周期和软件维护要求都更高。

英飞凌此次提到的内容也不只是“支持几颗芯片”。它还强调了IoT安全更新、生命周期管理、汽车和工业控制器的安全理念，以及长期支持。

英飞凌Zephyr治理委员会代表Clark Jarvis表示，公司希望提高MCU、汽车MCU和连接产品之间的软件复用与可移植性。所以AURIX进入Zephyr，证明了英飞凌已经愿意把Zephyr放到要求更高的产品线上。

Silicon Labs：壮大Zephyr生态系统

Silicon Labs作为一个正在被TI收购的公司，一直很活跃。Silicon Labs从2021年加入 Zephyr社区，2025年升级为白金会员。上个月，Silicon Labs还联合Dotstar Systems举办了Zephyr社区交流会，深化Zephyr生态系统。

作为白金会员，Silicon Labs持续加大对这一生态的投入，并推出Simplicity SDK for Zephyr，将Zephyr的开放生态与芯科科技的硬件、软件、文档和技术支持结合起来。目前，该SDK已支持部分EFR32和SiWx917器件，开发者可以基于芯科科技的硬件，使用Zephyr开发Wi-Fi和低功耗蓝牙应用。

Silicon Labs还计划进一步扩大Zephyr的板级支持和示例代码，加强安全启动、OTA等安全能力，并增加对上游社区的代码贡献。此次社区活动也反映出，Zephyr正在获得更多厂商和开发者的关注。

兆易创新：也加入了Zephyr

兆易创新也在加快GD32 MCU与Zephyr生态的融合。8月31日，兆易创新（GigaDevice）正式加入Zephyr项目。兆易创新表示，该项目由Linux基金会托管，兆易创新正式成为Zephyr项目与Linux基金会双银牌会员。

目前，兆易创新已经完成多个GD32 MCU系列的Zephyr适配，包括SoC、BSP驱动和板级支持，相关代码可从GD32 GitHub仓库获取。兆易创新工程团队也在持续向Zephyr社区贡献代码和技术支持。

未来，兆易创新计划适配更多GD32产品，并推动更多芯片支持进入Zephyr主线，同时参与国内Zephyr生态建设，为开发者提供更多软件资源和开发选择。

这些厂商的动态值得关注

NXP作为Zephyr的创始白金会员之一，自项目伊始就积极参与。NXP看重Zephyr的开源中立性和跨产品组合可扩展性，在多个MCU/MPU平台上提供Zephyr支持，希望通过Zephyr减少碎片化，将安全和连接能力建立在统一基础之上，从而让多家公司共同构建一个更强大的生态。

ST于2024年成为Zephyr社区银牌会员。ST的贡献集中在STM32系列MCU和相关外设驱动上。最新的Zephyr 4.4.0版即新增对STM32C5、STM32H5、STM32U3、STM32WBA2X等系列MCU的支持。

ADI 2025年发布的CodeFusion Studio 2.0 现支持完整的AI工作流，开发者可自带模型并高效地部署到ADI的处理器和微控制器上。基于Zephyr的新型模块化框架支持对AI/ML工作负载进行运行时性能剖析，从而实现逐层分析，并能与ADI异构平台无缝集成。

2025年6月，Renesas宣布将会员级别升级为白金。Renesas高管Aish Dubey表示，公司致力于使“基于OSS的RTOS解决方案广泛应用于各行各业”，并将与Zephyr领导层密切协作，加速满足日益严格的功能安全和网络安全要求。此前Renesas已有多款微控制器（RX、RA系列等）得到Zephyr支持，新提升表明其将继续加大投入，扩展Zephyr在物联网和高性能领域的影响力。

Zephyr是NordicnRF Connect SDK的核心组成部分。2025年9月，Nordic介绍了新一代Wi-Fi SoC（nRF70系列）与Zephyr的集成：通过Zephyr RTOS，该方案实现了低功耗Wi-Fi 6功能，为第三方MCU提供云就绪能力。

今年9月，Zephyr还宣布宣布了七个新的银级成员：Canonical、Dojo Five、GigaDevice、Morse Micro、Northern.tech、西门子和Space Cubics.这一增长标志着嵌入式生态系统中十年的合作与商业扩展。

Zephyr并不会阻碍差异化

支持Zephyr，不等于芯片厂商要把自己的HAL、Driver和底层能力全部换掉。Zephyr自己的白皮书就写得很清楚。

普通GPIO、UART、SPI可以走Zephyr统一Driver；如果某段代码对实时性特别敏感，也可以直接访问寄存器，用Direct IRQ、DMA，甚至直接调用厂商HAL和DSP库。

换句话说，Zephyr不是非要把所有芯片都包成一个样子。芯片有自己的DMA、特殊外设、加速器、调试能力，照样可以继续用。

这也是它比较容易被半导体厂商接受的原因。厂商过去投入很多年做出来的HAL、Driver和Middleware并不用全部重写，只需要接进Zephyr的工程体系。

这也让厂商拥有足够的自由度。

为什么这两年Zephyr越来越被重视

Zephyr之所以被重视，是因为MCU正在发生变化。

MCU上的软件越来越多，也越来越复杂。无线协议、安全启动、OTA、网络连接、边缘AI、远程维护，正从高端系统逐渐进入普通嵌入式产品。软件变多，芯片厂商维护基础软件的成本也随之上升。

安全也是一个变化。设备出货后，还要持续修漏洞、处理CVE、更新软件，产品生命周期可能长达数年。TI在新闻中特别强调了欧盟《网络弹性法案》（CRA），Zephyr今年的开发者大会也把安全、CRA、连接、开发工具、测试，以及汽车、工业等应用列为重点议题。

此外，Git、CMake、VS Code、CI/CD等工具也逐渐进入嵌入式开发，开发者不希望每换一颗MCU，就重新搭一套开发环境，Zephyr正好赶上了这个变化。

工程师怎么看待Zephyr

一位工程师认为，Zephyr非常好用。此前他在使用Nordic平台时采用了Zephyr，如今已经逐步转向全部使用Zephyr。其优势之一是与west、CMake等开发工具集成得比较好。他还基于Zephyr搭建了自己的SDK，开发环境通过west和Git即可完成配置和获取。对于SoC之间的工程迁移，简单的项目通常半天左右就能完成，整体开发流程比较方便。

有工程师分析，Zephyr现在正在得到越来越多芯片厂商支持，TI、Infineon、Nordic等厂商都在加大投入，国内也已经有部分蓝牙芯片和 MCU 厂商开始接入 Zephyr。对芯片厂商来说，支持Zephyr可以降低开发者迁移的门槛；对开发者来说，则意味着软件栈和硬件之间可以逐渐解耦。

不过，虽然很多人还是认为，谁简单用谁，谁主流用谁，千万别听别人说个技术，就无脑去追，浪费了时间和精力，学了没什么市场的技术，赚不到钱。

“Zephyr目前来说，新手劝退型。”这是许多工程师反复提到的。比如，设备树就是一个典型例子。对于长期做Linux的开发者，设备树并不陌生，但对于习惯了传统MCU开发方式的工程师来说，第一次面对设备树、Kconfig、west、CMake这一整套工具链，确实容易被劝退。

有人甚至遇到过开发环境反复配置失败的问题。按照官方文档尝试了几次都没有成功，最后退回一个小版本才把环境跑起来，前后折腾了一周。

对于Zephyr和FreeRTOS一直存在争论。有工程师分析，RTOS最重要的是安全可控、简单、故障好排查。FreeRTOS核心代码比较简单，任务、队列、信号量等使用逻辑也已经被大量嵌入式工程师熟悉，开发过程中更容易控制风险。相比之下，Zephyr功能更丰富，确实可以减少一部分底层开发工作，但引入的组件越多，维护和排查问题的成本也可能随之增加。尤其是在实际产品中，一旦出现内存溢出、组件兼容等问题，后续维护成本可能远高于开发阶段省下来的时间。

还有一个现实问题是，很多MCU项目的生命周期很长。企业通常不会因为某个项目需要换芯片，就频繁更换MCU型号。一款芯片从量产到停产可能要用很多年，项目团队也未必有那么多跨MCU迁移的需求。在这种情况下，Zephyr强调的跨SoC移植能力，未必是所有项目都需要的。

资源占用也是工程师比较关注的问题。MCU市场的成本竞争很激烈，RAM和Flash多出来一点，都可能直接反映到芯片价格上。Zephyr功能比较完整，如果项目只需要一个简单的控制程序，却因此引入更多系统组件，反而可能增加资源占用和硬件成本。

当前，国内FreeRTOS的存量非常大，RT-Thread在国内也已经形成比较完整的社区和软件包生态，还有ThreadX、NuttX以及各家芯片厂商自己的SDK。国内很多大厂已经有自己的软件体系。虽然Zephyr目前的势头很大，但好像在国内要走的路还挺长。但从目前工程师的态度来看，越来越多的工程师已经开始学习和试用这个RTOS了。

你怎么看Zephyr？欢迎讨论。

请将我们设为“星标”，这样就会第一时间收到推送消息。

欢迎关注EEWorld旗下订阅号：“EEWorld电源开发圈”