Zephyr – "The Linux for MCUs"

Re-inventing the Wheel

It is interesting how the Firmware development ecosystem is so different to other software disciplines. Each chip-vendor maintain their own suite of tools which are presented as the all-in-one solution designed to meet all your needs. Consequently, each vendor endeavors to establish the foundations of their own software development kit (SDK) and ecosystem to cover basic requirements (usually with very similar features). Likewise, application developers often find themselves rewriting drivers or creating OS primitives that aren’t supported. The drawback of this paradigm is that a significant amount of development effort is spent reinventing the wheel, leaving less room for addressing the unique intrinsic challenges of each application through innovation.

When we consider how software development works in other disciplines, we realize that these problems have been solved by reaching a consensus on a common foundation to build upon. From this perspective, it becomes apparent that there’s a need for an equivalent approach in firmware development, something akin to a “Linux for MCUs”.

Zephyr: more than an RTOS, an Ecosystem

The Zephyr Project, originating from the Linux Foundation, stands as one of the main contenders to change this paradigm. Compared to other real-time operating system (RTOS) offerings, Zephyr not only provides the essential OS primitives but also features a collection of drivers, subsystems, and libraries maintained by a diverse, multi-vendor community. Zephyr shares strong similaries its counterpart, Linux, on its very foundations by using two well-known Linux concepts:

1. Device-Tree: Zephyr implements a clear abstraction between hardware and applications through the use of the Device-Tree concept. Similar to board support packages (BSPs), each supported hardware target contains its own device-tree source, along with adjacent configuration files, allowing it to initialize properly based on the system configuration. Subsequently, each software component that depends on it retrieves the relevant nodes and operates based on their properties.

2. Kconfig: serving as the software configuration settings, allowing the build system to determine which libraries should be enabled and, if so, with which set of features.

Road towards the “Linux for MCUs”

As Zephyr contributors, we’re very excited on the potential the Zephyr Project has to effectively become the “Linux for MCUs” and shift the current paradigm on developing firmware. However, to truly fulfill the promise of becoming the Linux for MCUs, Zephyr is set to accomplish a set of goals:

1. Hardware Agnostic: ensuring reusability across various hardware vendors.

2. Extensive Library Support: offering mature drivers, subsystems, protocol stacks and OS primitives.

3. External Integration: facilitating integration with third-party modules.

4. Security: incorporating updated standardized security guidelines.

5. Community Contributions: continuously improving the ecosystem.

In upcoming posts, we will delve into each of these points with a hands-on approach, analyzing the advantages and disadvantages of this relatively new ecosystem. We will also point to valuable resources for anyone interested in getting started.

Leave your Feedback!

• Have you tried Zephyr? If so, what has been your experience?

• Are there any areas related to Zephyr that you would like us to analyze?

Very excited for the Purple Kite RTOS!

Continue Reading: Part 2: Hardware →