The explosive growth of Internet of Things (IoT) and connected devices has created an unprecedented demand for secure, scalable, and adaptable operating systems tailored to embedded platforms. While there are other Real-Time Operating System (RTOS), like FreeRTOS, ThreadX, VxWorks, MbedOS, NuttX, and such others, Zephyr RTOS has emerged as a standout solution with a focus on small systems, because of its small footprint kernel. Zephyr RTOS was launched by the Linux Foundation in 2016, and many vendors and several engineering organizations have now joined Zephyr RTOS project as member partners and started giving support for their System on Chips (SoCs). Zephyr RTOS is rapidly becoming the preferred RTOS for developers building next-generation products, often within comprehensive design-to-manufacturing workflows and embedded products.

In this blog, we will explore the unique features of Zephyr RTOS, examine why it is gaining popularity, and compare it with other real-time operating systems. Additionally, we will also highlight some of its unique features and an application skeleton.

What is Zephyr RTOS?

With its optimized-footprint kernel, Zephyr RTOS is a scalable and open-source real-time operating system designed for embedded devices. It offers broad hardware support across multiple architectures, including ARM Cortex-M, ARC, RISC-V, Intel x86, Xtensa, and more. Zephyr RTOS supports over 600 boards across various CPU architectures out of the box, giving developers the flexibility to choose hardware tailored to their specific use case and seamlessly switch to other supported platforms with minimal or no changes to their application. This makes it an excellent choice for applications like wearables, medical devices, industrial automation, and consumer electronics.

Why Zephyr RTOS?

When developing embedded systems, many developers run into a variety of challenges with traditional Software Development Kits (SDKs) like MCUXpresso, STM32CubeIDE, Code Composer Studio, and many others. These challenges are well-known in embedded development environments, which eInfochips helps address through robust embedded software solutions.

For one, getting started often feels like navigating through a maze of proprietary tools configurations. Take something as simple as blinking an LED; one has to go through several steps, like from configuring the environment for the board, setting up clocks and GPIO pins through a graphical interface to generating base code. Not just the process is complex; the different naming conventions, HAL/LL drivers, and even the quirks of the IDEs themselves can leave the developer struggling with the toolchain instead of focusing on the application.

In contrast, Zephyr RTOS makes all of this far simpler and more streamlined. Want to blink an LED? The developer can write a small, clean piece of code using the same consistent API that works across various hardware platforms. Zephyr’s build system is easy to grasp and can be used cross-platform, unlike the more isolated, vendor-dependent environments of traditional SDKs. With Zephyr, you do not need to worry about diving into an Integrated Development Environment (IDE)-specific setup or memorizing multiple ways of configuring hardware. Its approach is unified, reducing the guesswork that comes with handling different microcontrollers and peripherals.

Another pain point with older SDKs is the lack of portability. With such tools, the code you write is often tied closely to a particular vendor hardware, and moving to a different board can mean rewriting or reconfiguring significant parts of the project. The Zephyr build system, however, solves this by offering high portability, making it easy to port your application across different supported platforms with minimal changes to the core logic.

In addition to this, Zephyr’s configuration and documentation feel far more approachable. The use of Kconfig for system configuration and Devicetree for hardware abstraction makes it clear and consistent, as opposed to the sometimes fragmented and Graphical User Interface (GUI)-heavy configurations found in traditional SDKs. This makes Zephyr not only easier to use but also more powerful and maintainable. Zephyr also provides proper documentation, a community-driven ecosystem that results in a more seamless and less frustrating development experience than the vendor-locked approaches of older SDKs.

Zephyr’s learning curve is high. Once you get past the initial learning curve, it starts to feel like an embedded Linux – but for microcontrollers. You write less glue code, deal with fewer vendor quirks, and can focus more on your application logic. Whether you are building for Nordic, NXP, ST, or another supported platform, Zephyr build system gives you the same smooth development experience across the supported boards.

Unique Features of Zephyr RTOS

Zephyr RTOS is gaining traction due to its unique set of features that cater to the needs of modern, connected devices. Here’s why developers are turning to it:

• Open Source: Zephyr is an open-source project that fosters collaboration and gives developers the freedom to modify and contribute to its development.
• Security Focus: Zephyr places a strong emphasis on security, hence, provides several features such as memory protection, User space, MCUBoot, and Trusted Firmware-M (for compatible SoCs) to help safeguard data integrity and privacy in embedded systems.
• Modular and Scalable: Zephyr’s modularity gives developers the flexibility to choose and configure its subsystems and modules to optimize memory usage as per the application’s requirements. Developers can add and configure their own or third-party libraries to Zephyr.
• Built-In Networking: Native support for Wi-Fi and Ethernet including Socket, Secure socket over IPv4/IPv6, Bluetooth, Thread, LoRaWAN, and other networking stacks.
• DevOps Integration: Zephyr also provides features to make it configurable for CI/CD pipelines, for example using ‘pytest’ and GitHub Actions, allowing for automated builds, testing, and deployment. Zephyr includes its own testing framework Zephyr Test Suite (ZTest), supporting unit testing, integration, and system-level testing that helps maintain code quality. ZTest also supports Hardware-in-the-Loop (HIL) testing, enabling validating the functionalities on the actual hardware and generating the report.
• Cross-Platform Compatibility: Zephyr supports various hardware architectures, like Arm, Intel x86, Arc, RISC-V, Xtensa and others that help developers switch between platforms without putting much effort or even no changes in the application.
• No IDE Required: With its CMake-based build system and the ‘west’ command-line tool, Zephyr doesn’t require a dedicated IDE. Developers can customize IDEs of their choice to use and manage Zephyr.

Language Support in Zephyr RTOS

Zephyr supports multiple programming languages, making it versatile for different development needs:

• C: Core development, system APIs, and driver implementation.
• C++: Core development and object-oriented programming.
• Rust: Experimental support driven by the community.

How Zephyr RTOS Aligns with Linux

Zephyr RTOS is often referred to as “Linux for Microcontrollers.” Zephyr incorporates several architectural principles and tools from the Linux ecosystem:

• Kconfig and DeviceTree: Zephyr uses Kconfig for configuration and DeviceTree for hardware description, providing a familiar setup for Linux developers.
• Open Governance: Like Linux, Zephyr is developed collaboratively ensuring transparency and inclusivity.
• Toolchains and Build Systems: Zephyr employs CMake for building applications and west tools for project and application management.

Zephyr RTOS vs Other RTOS Comparison Table

Zephyr Application at a glance

Zephyr’s development environment setup can be done by following their Getting Started Guide. Once Zephyr’s environment setup is done, the Zephyr directory structure looks as follows:

Let’s consider a practical example to illustrate how Zephyr’s build system and application structure come together. Consider that we want to develop a smart home ecosystem that includes a group of sensor and gateway devices, where sensor monitors temperature, humidity, and air quality and the devices in the ecosystem should support communication over Bluetooth. A central gateway device should have the capability to communicate with sensors, and it should have the capability to send the sensor data to Cloud over Wi-Fi. Also, the application should be compatible with different SoCs, for example ESP32 and Nordic.

A typical directory structure for an application would look like:

Unlike traditional build systems, Zephyr’s approach is application-centric, meaning the application itself initiates the build process for Zephyr’s source code. This ensures that the application controls the configuration and builds process for both Zephyr and itself, resulting in a unified binary.

Application Directory: Linking Zephyr and Modules

The application directory acts as the main point where Zephyr RTOS features, its modules, and the application-specific files are configured for build process.
The application directory must include the following files:

• prj.conf

The `prj.conf `file defines application-specific configurations such as Kernel configurations, configurations from Zephyr subsystems, custom module, and/or application specific configurations. These configurations are then merged with other configurations to produce the final build configuration file.

Example Entries:

CONFIG_BT=y

CONFIG_WIFI=y

CONFIG_SENSOR=y

CONFIG_LOG=y

CONFIG_MAIN_STACK_SIZE=2048

CONFIG_HEAP_MEM_POOL_SIZE=4096

• Kconfig

The Kconfig file is used to define custom configurations required to manage and configure the application functionality. These options can be viewed via menuconfig or guiconfig.

Example Use Case:

menu “Smart Home Sensor Options”

config USE_DISPLAY

bool “Enable display UI”

default y

config ENABLE_WIFI

bool “Enable Wi-Fi connectivity”

default y

endmenu

• CMakeLists.txt:

The CMakeLists.txt file acts as the entry point for the build system, which links the application directory to Zephyr’s CMake build system. It is required to include the Zephyr boilerplate application, application’s name, and source file locations.

Example:

cmake

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})

project(smart_home_sensor)

target_include_directories(src)

target_sources(app PRIVATE src/main.c

src/app_ble_services.c

src/app_sensors.c

src/app_display_ui.c

src/app_wifi_service.c)

• board files

Board files, including Devicetree overlay and configuration files, customize hardware-specific features for a given board. <board>.conf files adjust parameters like board specific configurations, while <board>.overlay files modify the base Devicetree to add/modify components such as General-Purpose Inputs/Outputs (GPIOs), sensors, or displays.

Example Files:

`esp32s3_devkitc_procpu.conf`: ESP32S3 specific application configurations.

`esp32s3_devkitc_procpu.overlay`: ESP32S3 specific board overlay file to add or override board pin configurations.

`nrf52840dk_nrf52840.conf`: nRF52840DK specific application settings.

`nrf52840dk_nrf52840.overlay`: nRF52840DK specific board overlay file to add or override board pin configurations.

• `src/` directory

The `src/` directory holds the application’s source code or business logic implementation.

Conclusion

The introduction of Zephyr RTOS for embedded systems has redefined the landscape by offering a modern, community-driven platform that balances simplicity, scalability, and security. Its Linux-inspired design philosophy that includes a rich feature set and robust ecosystem, makes it an ideal choice for developers looking to build future-ready embedded applications. As embedded technologies are evolving rapidly, Zephyr RTOS features are going to lead the way, empowering developers to create innovative, secure, and connected devices.