8 Strong Reasons to Select Zephyr OS to Boost Firmware Development

#Zephyr, #OS, #firmware, #embeddedsystems, #embeddedsoftware, #nordicsemiconductor, #hyperstone, #qa, #time to market

Based on our own experience, we provide a summary (discussed below) of the benefits of using Zephyr OS to develop embedded systems’ firmware.

Executive summary:

Introduction: Zephyr – more than RTOS

and the 8 reasons:

Multiple platform support
Modular design – component selection
Modern build system – CMake – quality & time2market
Package manager – West meta-tool
Device tree platform description – simplified form
Security – architecture and release process
Documentation – easy access
Open source – great!

Zephyr is more than just an RTOS kernel

In previous years a new OS started to gain popularity in the embedded systems market – the Zephyr OS. At some point in history, it became part of the Linux Foundation open-source projects portfolio and gained lots of interest from well-known companies like Intel, NXP, and Texas Instruments. Then also Nordic Semiconductor, one of the market leaders in Bluetooth connectivity, during the introduction of new products like nRF9160 and nRF5340, decided to migrate its internal SDK into Zephyr based product – nRF Connect SDK. That was also a turning point for us at Embevity, as a significant part of our projects targets the IoT market and most of them make use of Nordic chips. And it turned out that we liked each other.

At Embevity we develop embedded systems taking care of various product aspects. Part of our jobs is to write code that can be classified as software where we mostly use C++, but occasionally implement some parts in higher-level programming languages like Python or .NET (C#). Seeing how those technologies could boost product development by providing generic library components that could be easily integrated into an application working with firmware projects seemed like an unnecessarily time-consuming struggle. We believe that Zephyr is here to close this gap.

Zephyr is far more than just an RTOS kernel. It can be considered a framework for embedded firmware development. All the components shared in every, even the smallest project are already here ready to be used: logger, memory management, connectivity stacks, filesystems, or shell implementation to just name a few. And all of those thoroughly tested and already deployed on hundreds of existing devices. That’s definitely a good place to start your new project development.

There are of course other possibilities on the market like MbedOS, FreeRTOS with companion libraries now managed by Amazon AWS, or even the recently new Microsoft Azure IOT approach. Although those alternatives could turn out to be better for a specific project the Zephyr provides greater flexibility and coincides well with how we see firmware development at our company.

The rich Zephyr feature list can be found on its documentation portal but here allow us to discuss things that we appreciate very much from a development perspective and that helps us lower implementation time and as a result, reduce project cost and time to market which lots of our clients find very important.

1. Multiple platform support

We completed multiple projects in different market domains and although there are always some common parts we optimize products for a given application. That means that we tend to switch MCUs between projects to balance cost, computation power, and power consumption. Zephyr supports us here by providing support for multiple architectures and CPUs. The samples are ready to be used on over 450 available boards.

2. Modular design

There’s a dedicated configuration subsystem (Kconfig) developed that makes it easy to select the required components for your application. That wouldn’t be possible if the OS design wasn’t modularized properly. The internal architecture to some extent follows best practices from the Linux system. That way we can compile only needed files and reduce the output executable memory footprint. That’s very important that we have control over various parameters, like for example memory buffer sizes, and can adjust it properly for the target appliance.

3. Modern build system

For many years firmware projects tight close to vendors SDKs had no other choice than to use their build system. That has a strong advantage of low entry-level as you get everything ready just after IDE installation. But this doesn’t scale well with project size and restricts your control over the whole process severely. Not to mention how badly project files were suited for version control systems. One IDE that we had to use in the past even mixed project settings with information about files opened in an editor in the same project file.

Then at some point at Embevity, we decided to take an alternative path where we control all aspects of the building process. We make use of CMake to define the whole process and integrate some other components like unit test frameworks, versioning scripts, or static code analyzers. We are very happy that Zephyr decided to take the same path here.

4. Package manager

That’s one of the things that’s mostly missed compared to high-level language environments. For example, for the already mentioned languages above there is pip for Python and NuGet for .NET. Now in the firmware world that’s of course much more complicated as we have so many different architectures that maintaining prebuilt libraries for all of them is not possible. That means we have to integrate different components during the build process and compile the as main application dependencies.

Zephyr was also aware of that and that’s mostly why the West meta-tool was designed. It allows projects to specify their dependencies in a manifest file and then at some point during project creation everything gets set up automatically. An example here would be the filesystem subsystem – Zephyr internally holds some generic logic and virtual implementation while concrete implementation is provided by 3rd party projects like LittleFS or FATFS.

5. Device tree platform description

Zephyr adapted a simplified form of device tree description known from the Linux system. Everything gets resolved at compilation time but the syntax remains the same. And it’s much more readable and clearer than anything that we saw or used internally before.

Figure 1. Comparison of platform description for DW1000 UWB transceiver in bare-metal (left) and Zephyr (right) project.

6. Security

The awareness of security in embedded systems rose greatly together with the IoT concept spread. After all none of us would like to lose control over all those smart devices, lose confidential data or even money. And history is full of various less or more severe incidents.

Zephyr approaches security topics very seriously just as they should be treated. There are qualified cryptographic libraries already integrated like mbedTLS or TF-M, proper design concepts in system architecture for layers separation and privileges management, secure bootloader and firmware update, well-defined quality assurance process, and of course publicly available vulnerability journal. All of that is making our job easier and less prone to faults that could be very harmful to clients when the product gets to the market.

Figure 2. A secure SSD project where Zephyr OS was implemented in three microcontrollers – 2 x Nordicsemiconductor and STM, assisted by Hyperstone SSD controller.

7. Documentation

Documentation available for Zephyr is on a very high level. There are lots of pages describing not only the available API but mostly components architecture and design details. Since the documentation sources are kept next to the code in the main repository everything gets updated together with code changes. You can also browse all the historic versions bound to the individually released version. That’s definitely a superior approach to navigating over tons of PDF files and trying to locate that one thing you need.

8. Open source

That’s the last point on the list but definitely not the least one. Zephyr is distributed with Apache 2.0 license and sources are publicly available on GitHub. There are lots of contributions both from professionals and amateur developers that both share passion for embedded systems. That connected with proper integration procedures creates a great environment for great product development. The popularity of the system and thus size of community is something also in our favor. Almost every time we struggle with a problem, we find out someone that had it as well and found a solution or if it happened to be a code bug that it was already reported and fixed by maintainers.

We thank devzone.nordicsemi.com for their great support!

8 Strong Reasons to Select Zephyr OS to Boost Firmware Development