• RTOS
• Software Development
• Tutorials

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. When starting with any embedded software project, the first task is to start from a known baseline. This can include cloning a repository from source control, which can be the case with embedded Linux, or downloading a zip file representing a specific source code version, which is usually the case with other RTOSes. This blog post will describe a personal best practice to ensure Zephyr development begins from a known baseline. Thus, there are no surprises when development on a Zephyr-based project is handed off to a client or colleague.

Quick Links

• Part 1: Getting Started With Zephyr: West Manifest Customization
• Part 2: Getting Started With Zephyr: Kconfig
• Part 3: Getting Started With Zephyr: Devicetrees
• Part 4: Getting Started With Zephyr: Devicetree Bindings
• Part 5: Getting Started With Zephyr: Devicetree Overlays
• Part 6: Getting Started With Zephyr: Saving Data To Files
• Part 7: Getting Started With Zephyr: Writing Data to EEPROM
• Part 8: Getting Started With Zephyr: Bluetooth Low Energy

Zephyr is unique because it uses a “meta-tool” called West to retrieve all the Zephyr components from different locations, potentially using disparate mechanisms. Compare that with a typical software development workflow, where a single repository is used to retrieve the source code. Instructions for West on how to retrieve the different components are contained in a “manifest” file. The manifest file is usually checked into source control, providing a snapshot of the entire Zephyr codebase.

Strategy

The strategy is twofold. First, we can create forks of repositories where we anticipate making customizations. While the goal is to create pull requests for relevant customizations, having a reliable location that serves as a sandbox is still essential. For example, a past blog post demonstrated adding buttonless DFU to MCUBoot (https://zephyrproject.org/supporting-firmware-updates-with-zephyr-nrf/), which required creating a fork of MCUBoot. Additionally, we may need to modify one of the Zephyr subsystems due to a bug we’ve discovered or a feature we wish to add. While submitting a pull request (PR) would be ideal using their guidelines ((https://docs.zephyrproject.org/latest/contribute/guidelines.html), we can create a fork of the Zephyr repository until then.

Once the forks have been created, we can create a custom West manifest file to describe our entire codebase. We can start by leveraging Nordic Semiconductor’s extensive work to create a complete, stable baseline firmware using Zephyr; Nordic includes a West manifest file to help their customers get started (https://github.com/nrfconnect/sdk-nrf/blob/main/west.yml). We can make the necessary changes to Nordic’s manifest file and use it as our own. First, we can add a “remote” containing a descriptive name and the base URL for the repository:

remotes:
.
.
.
        - name: <a descriptive name>
          url-base: <base repository URL>

Second, we need to instruct West to use our fork of Zephyr and MCUBoot. In Nordic Semiconductor’s manifest file, their repository is used as the “default” (the default is used if no remote is specified for a particular codebase):

  defaults:    
        remote: ncs

We need to add our remote to the entries for Zephyr and MCUBoot (instructing West not to use Nordic’s repositories):

.
.
.    
        - 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

After making the above changes and pushing up the modified West manifest file, we can execute the following command to use the modified West manifest file, which will pull in our forks of MCUBoot and Zephyr:

$> 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).

In summary, this blog post demonstrated the mechanics of creating a custom West manifest file, which is a good first step when beginning Zephyr firmware development. A custom West manifest file ensures that there are no surprises during development (because a third-party repository may have changed). Once the Zephyr firmware is feature complete and stable, a conscious decision can then be made to update to a newer version of Zephyr.

Sign in