by  Taras Kurnytskyi

Introduction to Zephyr RTOS

  4 min read

According to Wikipedia, there are over one hundred operating systems (OS) for embedded devices, so why is there a need to develop another one? This blog will endeavor to clarify this issue and describe the key features that distinguish the Zephyr operating system from other embedded operating systems.

The Internet of Things (IoT) industry is developing at a rapid pace. There is a long list of boards used as hardware for IoT devices. Sometimes there are cases when different boards are to be used within a single application, or a quick switch from one board to another is required. Therefore, there needs to be a unified platform which can help to speed-up development under such circumstances. Creating such a platform was the driving force behind the development of the Zephyr operating system.

“The Zephyr operating system is intended to be open and collaborative environment that helps to deliver an open source Real-Time Operating System (RTOS), applicable in a wide diversity of use cases, and supporting as many hardware devices as possible, while providing possibilities for upstreaming code and participating in the future roadmap.”*

*Source: zephyrproject.org

There are a number of options on the market, with some of the most powerful operating systems being the following: FreeRTOS, Mbed, and Apache Mynewt. Generally, there is no single recipe or single operating system which can be recommended. The choice heavily depends on the specific use cases.

The Zephyr operating system provides the following, among others:

  • Secure bootloader (MCU Boot)
  • Kernel
  • Network stacks
  • File systems (NFFS, LittleFS, NVS)
  • Middleware (including OTA mechanism and LwM2M client functionality)
  • Device drivers
  • Sensor drivers
zephyr-social

So what makes Zephyr a unique operating system compared to others?

1. Supported boards

At the time this blog was written, the Zephyr supported around 170 boards, much more than any another embedded operating system has done. In case users have to move to another hardware device the only thing to do is to inform the Zephyr compiler which board the code is to be compiled for.

Thus, the Zephyr operating system essentially helps to reduce time and effort while moving to another board.

zephyr-application
Figure 1. The Zephyr system architecture. (Source: Zephyr.org)

2. Scalability

The Zephyr operating system is a highly configurable and modular operating system that implements memory protection, even for platforms without a Memory Management Unit (MMU) or a Memory Protection Unit (MPU). Zephyr operating system uses Device Tree Support (DTS) only when compiling code. Powerful configuration tools allow flexible inclusion of only those features that are really required in specific applications. The memory footprint can be as low as 8K.

The other specific feature of the Zephyr operating system is it only has one address space, meaning that the application code and the kernel are combined in the same binary compilation.

3. Build toolchain

Being an intrinsically cross-platform project, the Zephyr operating system naturally uses the CMake build system. It also extensively uses a command line tool named ‘West’, which is used for building, flashing, and debugging applications, as well as a Zephyr repository manager.

4. Sensor support

Expectedly, the Zephyr operating system has a great sensor support system, with high levels of abstraction. The process goes smoothly during enabling sensors that are already supported by the Zephyr operating system. While a number of boards and sensors are supported; however, the process is complicated if a new sensor is required to be enabled on a custom board.

5. Zephyr support and updates.

The Zephyr operating system has a very user-friendly software development kit (SDK) which is easy to adapt to. The SDK is developing all the time, and new releases are issued quite frequently. These new releases are quite challenging to track and sometimes the application development can become ‘clogged’ for an indefinite while. This is the author’s personal experience:

“At some point, I started observing unexpected device resets. I spent many hours debugging, and naturally first of all, I searched for the root cause of the problem in the application code. However, after of couple of weeks debugging, the reason was localized to be a Bluetooth controller. Only then, the Zephyr operating system was updated to the latest version. And voila, the resets magically disappeared and the problem was solved.”

The general conclusion is that the Zephyr operating system is very powerful and convenient instrument which can be used for embedded application development, and is highly recommended for use.

In the next blog, an application development process using Zephyr will be described in more detail.