Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18-20, 2026.
As part of the Zephyr track, Jacob Beningo from Beningo Embedded Group presented “From FreeRTOS To Zephyr: A Practical Migration Guide for Embedded Developers.” The session focused on how embedded developers can approach a migration from FreeRTOS to Zephyr with a clear strategy, while understanding the differences between the two RTOSes.
FreeRTOS has long been a go-to RTOS for embedded developers. But as projects grow in complexity and demand better modularity, richer middleware, long-term maintainability, and stronger ecosystem support, many teams are turning to Zephyr. Jacob opened the talk by explaining why Zephyr has become compelling for modern embedded systems development, highlighting its active community, growing ecosystem, broad architecture and board support, modern tooling, and support for more scalable development practices.
At the same time, the session made clear that migrating from FreeRTOS to Zephyr is not a simple one-to-one API replacement. The two RTOSes use different kernel strategies, APIs, build systems, configuration models, and hardware abstraction approaches. Jacob emphasized that developers need to pay close attention to these differences, especially when moving scheduling behavior, priorities, stack sizes, and kernel objects.
The talk outlined a practical migration strategy for teams moving existing FreeRTOS applications to Zephyr. The first step is to analyze the existing RTOS-based application and understand its architecture, including threads, inputs, communication paths, queues, and system behavior. From there, teams may choose to abstract common RTOS functionality, such as through a shim layer or CMSIS-RTOS v2, depending on the complexity of the application and whether they need portability across multiple RTOSes.
Jacob then discussed the importance of adapting the build system. Many FreeRTOS projects rely on vendor-generated projects or traditional Makefiles, while Zephyr uses a modern build environment based on tools such as CMake, Ninja, Kconfig, and West. Preparing the project structure early can help teams compare the FreeRTOS and Zephyr versions side by side, manage dependencies cleanly, and keep application code separate from Zephyr itself.
A major part of the session focused on Zephyr’s devicetree model. For developers coming from FreeRTOS or bare-metal systems, devicetree can be one of the steeper parts of the learning curve. Jacob explained that devicetree allows teams to describe hardware in a structured way, configure boards, pins, buses, bindings, overlays, and hardware defaults, and then use generated macros in application code. This helps decouple application logic from low-level hardware details and supports Zephyr’s hardware abstraction approach.
The core of the migration discussion centered on moving FreeRTOS kernel objects to Zephyr equivalents. Jacob compared tasks and threads, semaphores, mutexes, message queues, event flags, timers, and interrupt handling. He highlighted several common migration issues, including the difference in priority numbering between FreeRTOS and Zephyr, differences in how stack sizes are defined, and the need to carefully read API expectations rather than assuming direct compatibility.
For example, FreeRTOS and Zephyr handle task and thread creation differently. FreeRTOS uses task APIs and stack depth, while Zephyr uses thread APIs and stack size in bytes. Priority behavior also differs: in FreeRTOS, zero is the lowest priority, while in Zephyr, zero is the highest preemptive priority and negative priorities are cooperative. These differences make it important to review and remap priorities during migration. Similar care is needed when moving semaphores, mutexes, queues, and event mechanisms, since Zephyr often provides different object types, macros, and initialization patterns.
Jacob also highlighted differences in interrupt handling. In FreeRTOS, developers often need to use special “from ISR” APIs and explicitly manage scheduling behavior after an interrupt. In Zephyr, more of that behavior is handled by the kernel, which can simplify application code during migration.
The session also showed how Zephyr’s broader ecosystem can help teams build more scalable and maintainable systems. Beyond kernel primitives, Zephyr offers tools and subsystems that support modern embedded development, including configuration management, testing, simulation, hardware abstraction, and options such as Zbus for publish-subscribe style application design.
The talk closed with a reminder that while AI can help with parts of the migration process, such as understanding an existing architecture or assisting with devicetree setup, teams still need a clear engineering strategy. A successful migration requires careful analysis, validation, testing, and a strong understanding of how FreeRTOS and Zephyr differ.
For embedded developers considering the move from FreeRTOS to Zephyr, this session offered a practical roadmap: analyze the existing application, consider whether an abstraction layer is useful, adapt the build system, configure devicetree, migrate kernel objects carefully, integrate Zephyr subsystems, validate behavior, and then begin leveraging Zephyr’s ecosystem for scalability and long-term support.
Watch the session here. Check out the OSS NA 2026 playlist here.