#zephyeos

Introduction

The Zephyr Project RTOS (https://zephyrproject.org/), or simply “Zephyr” as it is known colloquially, is an increasingly popular real-time operating system due to its native support for over 450 boards and countless peripherals. Starting from a known baseline is the first step in any embedded software project. This can involve downloading a zip file that represents a particular source code version, as is typically the case with other RTOSes, or cloning a repository from source control, as may be the case with embedded Linux. In order to guarantee that Zephyr development starts from a known baseline, this blog post will outline a personal best practice. As a result, when a client or colleague takes over development of a Zephyr-based project, there are no surprises.

Zephyr is special because it retrieves all of the Zephyr components from various locations, possibly using different mechanisms, using a "meta-tool" called West. Contrast that with a standard software development process, which retrieves the source code from a single repository. A "manifest" file contains instructions for West on how to obtain the various components. A snapshot of the complete Zephyr codebase is provided by the manifest file, which is typically checked into source control.

Strategy

There are two parts to the strategy. We can start by making forks of the repositories where we plan to make changes. Having a dependable location that acts as a sandbox is still crucial, even though the objective is to generate pull requests for pertinent customizations. For instance, a previous blog post (https://zephyrproject.org/supporting-firmware-updates-with-zephyr-nrf/) showed how to add buttonless DFU to MCUBoot, which necessitated making a fork of MCUBoot. A bug we've found or a feature we want to add may also require us to change one of the Zephyr subsystems. We can make a fork of the Zephyr repository in the interim, but it would be best to submit a pull request (PR) following their guidelines (https://docs.zephyrproject.org/latest/contribute/guidelines.html).

We can describe our entire codebase in a custom West manifest file after the forks have been created. Nordic Semiconductor has done a lot of work to develop a complete, stable baseline firmware using Zephyr, and we can start by using their West manifest file (https://github.com/nrfconnect/sdk-nrf/blob/main/west.yml) to assist their customers in getting started. Nordic's manifest file can be modified as needed and used as our own. First, we can include a "remote" with the repository's base URL and a descriptive name:

remotes:

.

.

.

        - name: <a descriptive name>

          url-base: <base repository URL>

Second, we must tell West to use MCUBoot and our fork of Zephyr. When no remote is specified for a specific codebase, Nordic Semiconductor's repository is used as the "default" in their manifest file: In order to prevent West from using Nordic's repositories, we must include our remote in the Zephyr and MCUBoot entries: ...            - name: <zephyr repository name>                path: zephyr          revision: <git commit/branch>          remote: <a descriptive name>...        - name: <mcuboot repository name>          path: bootloader/mcuboot          revision: <git commit/branch>          remote: <a descriptive name>

Putting It All Together

Following the aforementioned modifications and uploading the updated West manifest file, we can use the modified West manifest file by running the following command, which will import our MCUBoot and Zephyr forks: $> west init -m <West manifest repo> --mr <commit/branch>

The “--mr” option can be used to specify a particular commit or branch; this may be useful if the default branch is not master (as in the case of Github, which uses “main” as the default branch).

To sum up, this blog post explained how to create a custom West manifest file, which is a good place to start when developing Zephyr firmware. Because a third-party repository might have changed, a custom West manifest file guarantees that there are no surprises during development. A deliberate choice to upgrade to a newer Zephyr version can be made once the firmware is stable and feature-complete.

Ready to optimize your hardware with customized Zephyr RTOS solutions? At Silicon Signals, we specialize in embedded hardware design, software development, and tailored solutions that align with your project requirements.