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.