Leading MCU manufacturers have made successive moves. Will this open-source RTOS dominate the entire market?
"Will Zephyr surpass FreeRTOS and become the next dominant RTOS? It is high time for embedded engineers to take a close look at Zephyr RTOS." An engineer raised this question two years ago.
In recent years, Zephyr has gained extremely strong momentum. Some engineers even believe that if this trend continues, Zephyr may unify the entire RTOS ecosystem in the future.
This year marks the 10th anniversary of Zephyr. Recently, MCU vendors are also ramping up their support for Zephyr, adding further impetus to this open-source RTOS.
These Vendors Are All Ramping Up Their Efforts
TI: Upgrades to Platinum Member to Fully Join the Zephyr Ecosystem
On October 1, TI announced that it would expand the support scope of Zephyr across its MCU, MPU and wireless connectivity product lines, and at the same time upgrade its membership tier in the Zephyr Project to the highest Platinum level.
In fact, TI did not just start supporting Zephyr recently — it has been backing Zephyr ever since the project was founded 10 years ago. However, in the past, TI's Zephyr support was mostly limited to partial products, some development boards or specific software packages. Now, the company is extending full coverage to all its product lines, aiming to deliver a unified, mass-production-ready development experience to avoid software fragmentation.
Previously, different MCU vendors had their own dedicated SDKs, RTOSes, drivers and development tools. Every time the hardware was changed, the software engineering work usually had to be modified accordingly. By supporting Zephyr, developers can keep using their original open-source workflow and migrate the underlying hardware to TI's products seamlessly.
In the past, the software ecosystems of MCU vendors were usually sold as bundled packages: chips, SDK, RTOS, IDE, compiler and drivers all came as a set, and developers would get deeply locked into the ecosystem the more they used it. Zephyr takes a completely different approach: developers first create a Zephyr project, then decide which vendor's MCU to run at the underlying layer.
Of course, this does not mean TI's own software tools will disappear. Zephyr mainly unifies part of the development methods at the upper layer. Marian Kost, Vice President of TI's Wireless Connectivity Business, even directly referred to Zephyr as the "cornerstone" of TI's work to break down barriers between hardware and software.
Infineon: Also Upgrades to Platinum Member, Brings Zephyr to Automotive MCUs
Infineon, like TI, announced on October 1 that it would extend full Zephyr support to its TRAVEO, PSoC and AURIX product lines, while upgrading its membership tier in the Zephyr Project to the highest Platinum level.
Infineon started supporting Zephyr on products such as PSoC very early, but this time the company puts automotive MCUs in a very prominent position. Currently Infineon has been advancing Zephyr support on TRAVEO and PSoC, and has now brought AURIX and TriCore into the scope as well.
This is quite different from most people's past impression of Zephyr. In the early days, Zephyr was most commonly used in IoT, wireless MCUs and various resource-constrained devices. AURIX is a completely different category of products, long used in automotive control, real-time control and safety-related systems, which have much higher requirements for reliability, lifecycle and software maintenance.
What Infineon mentioned this time is far more than just "supporting a few chips". It also emphasized IoT security updates, lifecycle management, security concepts for automotive and industrial controllers, as well as long-term support.
Clark Jarvis, Zephyr Governing Board Representative at Infineon, said the company aims to improve software reusability and portability across MCUs, automotive MCUs and connectivity products. The inclusion of AURIX in Zephyr proves that Infineon is willing to deploy Zephyr on its product lines with the most stringent requirements.
Silicon Labs: Expands the Zephyr Ecosystem
Silicon Labs, a company currently being acquired by TI, has always been very active in this field. Silicon Labs joined the Zephyr community in 2021 and was upgraded to Platinum Member in 2025. Last month, Silicon Labs also co-hosted a Zephyr community exchange event with Dotstar Systems to further develop the Zephyr ecosystem.
As a Platinum Member, Silicon Labs continues to increase its investment in this ecosystem, and has launched the Simplicity SDK for Zephyr, which combines Zephyr's open ecosystem with Silicon Labs' hardware, software, documentation and technical support. Currently, this SDK supports a number of EFR32 and SiWx917 devices, allowing developers to build Wi-Fi and low-power Bluetooth applications using Zephyr based on Silicon Labs' hardware.
Silicon Labs also plans to further expand Zephyr's board support package and sample code, enhance security capabilities such as secure boot and OTA, and increase code contributions to the upstream community. This recent community event also reflects that Zephyr is gaining growing attention from more vendors and developers.
GigaDevice: Also Joins Zephyr
GigaDevice is also accelerating the integration of its GD32 MCUs with the Zephyr ecosystem. On August 31, GigaDevice officially joined the Zephyr Project. GigaDevice stated that the project is hosted by the Linux Foundation, and the company has officially become a dual Silver Member of both the Zephyr Project and the Linux Foundation.
At present, GigaDevice has completed Zephyr adaptation for multiple GD32 MCU series, including SoC, BSP drivers and board-level support, and the relevant code is available on the GD32 GitHub repository. GigaDevice's engineering team is also continuously contributing code and technical support to the Zephyr community.
In the future, GigaDevice plans to adapt more GD32 products, push more chip support into the Zephyr mainline, and participate in the construction of the domestic Zephyr ecosystem to provide developers with more software resources and development options.
Notable Moves From Other Vendors
NXP, one of the founding Platinum Members of Zephyr, has been actively involved in the project since its inception. NXP values Zephyr's open-source neutrality and cross-product portfolio scalability, and provides Zephyr support across multiple MCU/MPU platforms. It hopes to reduce fragmentation through Zephyr, build security and connectivity capabilities on a unified foundation, so that multiple companies can jointly build a more powerful ecosystem.
ST became a Silver Member of the Zephyr community in 2024. ST's contributions are focused on the STM32 series MCUs and related peripheral drivers. The latest Zephyr 4.4.0 release adds support for STM32C5, STM32H5, STM32U3, STM32WBA2X and other series of MCUs.
ADI's CodeFusion Studio 2.0 released in 2025 now supports a complete AI workflow, allowing developers to bring their own models and deploy them efficiently on ADI's processors and microcontrollers. The new Zephyr-based modular framework supports runtime performance profiling for AI/ML workloads to achieve layer-by-layer analysis, and can seamlessly integrate with ADI's heterogeneous platforms.
In June 2025, Renesas announced that it would upgrade its membership tier to Platinum. Aish Dubey, a senior executive at Renesas, said the company is committed to making "OSS-based RTOS solutions widely used across all industries", and will work closely with Zephyr's leadership to accelerate compliance with increasingly strict functional safety and cybersecurity requirements. Previously, multiple Renesas microcontrollers (including the RX and RA series) already had Zephyr support. This new upgrade indicates that the company will continue to increase investment to expand Zephyr's influence in the IoT and high-performance fields.
Zephyr is a core component of Nordic's nRF Connect SDK. In September 2025, Nordic introduced the integration of its new generation Wi-Fi SoC (nRF70 series) with Zephyr: through Zephyr RTOS, this solution implements low-power Wi-Fi 6 capabilities, delivering cloud-ready capabilities for third-party MCUs.
This September, Zephyr also announced seven new Silver Members: Canonical, Dojo Five, GigaDevice, Morse Micro, Northern.tech, Siemens and Space Cubics. This growth marks a decade of collaboration and business expansion in the embedded ecosystem.
Zephyr Will Not Hinder Product Differentiation
Supporting Zephyr does not mean that chip vendors have to replace all their own HALs, drivers and underlying capabilities. This is clearly stated in Zephyr's own white paper.
General-purpose GPIO, UART and SPI can use Zephyr's unified drivers; for code segments that are extremely sensitive to real-time performance, developers can also directly access registers, use Direct IRQ, DMA, or even directly call the vendor's HAL and DSP libraries.
In other words, Zephyr does not force all chips to be packaged in exactly the same way. Chips with their own DMA, special peripherals, accelerators and debugging capabilities can still make full use of these features.
This is also the reason why Zephyr is relatively easy for semiconductor vendors to adopt. Vendors do not need to rewrite all the HALs, drivers and middleware they have developed over years of investment — they only need to interface these components into Zephyr's project system.
This also gives vendors sufficient freedom of operation.
Why Zephyr Has Been Gaining Increasing Traction in Recent Years
The reason Zephyr is gaining so much attention is that MCUs are undergoing fundamental changes.
Software running on MCUs is becoming more abundant and more complex. Wireless protocols, secure boot, OTA, network connectivity, edge AI and remote maintenance are gradually moving from high-end systems to ordinary embedded products. As the amount of software increases, the cost for chip vendors to maintain basic software also rises accordingly.
Security is another changing factor. After devices are shipped, vendors need to continuously patch vulnerabilities, address CVEs and update software, and the product lifecycle can last for many years. TI specifically emphasized the EU's Cyber Resilience Act (CRA) in its announcement, and Zephyr's developer conference this year also listed security, CRA, connectivity, development tools, testing, as well as automotive and industrial applications as key topics.
In addition, tools such as Git, CMake, VS Code and CI/CD are gradually being adopted in embedded development. Developers do not want to rebuild a complete development environment every time they switch to a different MCU, and Zephyr perfectly caters to this trend.
What Engineers Think of Zephyr
One engineer thinks Zephyr is very easy to use. He previously used Zephyr when working on the Nordic platform, and now has gradually switched to using Zephyr for all his projects. One of its advantages is that it integrates very well with development tools such as west and CMake. He also built his own SDK based on Zephyr, and the development environment can be configured and accessed via west and Git. For project migration between different SoCs, a simple project can usually be completed in about half a day, making the overall development process very convenient.
Some engineers analyzed that Zephyr is now getting support from more and more chip vendors, with TI, Infineon, Nordic and other vendors all increasing their investment. Some domestic Bluetooth chip and MCU vendors have also started to integrate Zephyr. For chip vendors, supporting Zephyr can lower the migration threshold for developers; for developers, it means the software stack can be gradually decoupled from the underlying hardware.
However, many people still hold the view that you should use whichever technology is simpler and more mainstream, and never blindly chase a new technology just because others mention it, wasting time and energy learning niche technologies with little market demand that cannot bring you higher income.
"Zephyr is currently very unfriendly to newbies," a point repeatedly mentioned by many engineers. The device tree is a typical example. For developers who have long worked with Linux, the device tree is not unfamiliar, but for engineers accustomed to the traditional MCU development workflow, facing the entire toolchain consisting of device tree, Kconfig, west and CMake for the first time can easily drive them away.
Some people even encountered repeated failures in configuring the development environment. They tried several times following the official documentation without success, and finally rolled back to an older minor version to get the environment running, which took them a whole week.
There have long been debates between Zephyr and FreeRTOS. Some engineers analyzed that the most important features for an RTOS are security and controllability, simplicity, and easy troubleshooting. The core code of FreeRTOS is relatively simple, and the usage logic of tasks, queues, semaphores and other components is already familiar to a large number of embedded engineers, making it easier to control risks during development. In comparison, Zephyr has richer features that can indeed reduce part of the underlying development work, but the more components it introduces, the higher the cost of maintenance and troubleshooting may become. Especially in real-world products, once problems such as memory overflow or component incompatibility occur, the subsequent maintenance cost may far exceed the time saved during the development phase.
There is also a practical problem: many MCU projects have very long lifecycles. Enterprises usually do not frequently change MCU models just because a project needs to switch chips. A single chip may be used for many years from mass production to end-of-life, and project teams often do not have much demand for cross-MCU migration. In this scenario, the cross-SoC portability that Zephyr emphasizes may not be necessary for all projects.
Resource footprint is also a key concern for engineers. The MCU market is facing fierce cost competition, and even a tiny increase in RAM and Flash may directly push up the chip price. Zephyr has a relatively complete set of features. If a project only requires a simple control program, introducing more system components due to Zephyr may instead increase resource usage and hardware costs.
At present, FreeRTOS has a very large installed base in China, RT-Thread has already formed a complete community and software package ecosystem in the domestic market, and there are also ThreadX, NuttX and proprietary SDKs from various chip vendors. Many large domestic enterprises already have their own in-house software systems. Although Zephyr is gaining huge momentum, it still has a long way to go in the Chinese market. But judging from the attitudes of engineers, more and more engineers have started to learn and test this RTOS.
This article is from the WeChat Official Account "EE World" (ID: EEworldbbs), written by Fu Bin, and republished with authorization from 36Kr.