Application development

Zephyr is packed with a wide range of add-ons, features, and examples. In addition to that, it has a highly flexible and customizable source base thanks to its build system. Speaking of the build system, it deserves its own series of articles, but for now, let's focus on two important tools: CMake and west. CMake is a well-known build system, while west is Zephyr's CLI meta-tool that provides a multiple repository management system. Yes, you heard it right — multiple repositories! This opens up three different approaches to application development.

Before we move forward, let's familiarize ourselves with a few more terms that will come in handy later on. The multiple repository model means that one project can consist of various repositories such as the Zephyr source code, necessary SDKs, and requested add-ons. All the required information about these repositories and their versions are documented in a manifest file called west.yml, which is typically located in what we refer to as the west manifest repository. All these components can be conveniently stored in a common workspace known as the west workspace.

Zephyr repository application

The division we describe is based on a directory where our application (let’s call it app) is placed. In the first option, our app directory is placed directly under the zephyr repository. How to get started with such an application? First, let's set up a new workspace.

In that place, you'll discover something like:

The application we are focusing on is referred to as the “hello_world” application, which is the one we need to develop. However, for the purpose of this article, let's utilize a customized sample application to demonstrate how straightforward it can be. After you have your app ready, you can proceed with building and flashing a target like this:

It's a great way to run an application, but we believe there are more convenient ways of working on an application. Let's explore them in the following sections!

Zephyr-workspace application

If you have heard about three ways to set up a new project and have got shocked, then please take few deep breaths because one of these ways consists of 3 different flavors. So yeah… you have five different ways to set up a new Zephyr project.

Zephyr-workspace application is a constellation in which our application is directly under zephyr workspace, like below:

So what are these three different flavors in zephyr workspace? We can distinguish the following:

• T1 topology — star topology and zephyr directory is the manifest repository,
• T2 topology — star topology and our application is the manifest repository,
• T3 topology — forest topology with separate repository as manifest repository.

Let’s focus on T1 and T2 topologies and check out how to set up new applications. We'll skip T3 topology for now because we believe it deserves a separate article. :)

You can use the same workspace as in the case of zephyr-repository application or create a new one — as you wish. One disclaimer: this article is aimed at giving you a sense of how to start developing a new Zephyr application — we won’t cover topics like CMake, device tree, and KConfig. In the case of T1 topology, we can use an example application to get started really quickly. So let’s do that!

Ok, so you've got a skeleton of an application that can be extended according to your needs. Or you can just build it like follows:

If you're thinking about adding your own repository as a dependency to your application, you can definitely use west for that purpose. However, it's important to note that updating the manifest file is necessary. It's not recommended to go with T1 topology because the manifest file belongs to the zephyr repository. In this case, T2 topology would be the best option! You can create such a workspace by following these steps:

Zephyr freestanding application

Some may argue that the overhead associated with a workspace can overshadow what is truly important in projects — specifically, the business logic described in the application. And some others may agree `:wink:`.
For all of those, the scheme may be the one that is most frequently chosen. Zephyr freestanding application — in simple terms, an application that can be located anywhere without any connection to either the west workspace or the Zephyr repository. So the structure looks as follows:

For the sake of this part, let’s use zephyr sources that we have downloaded in previous sections. We will use the same example application as previously. So let’s check this out!

Everything is going well so far. Now, the key is to specify the location of Zephyr sources by setting a ZEPHYR_BASE environment variable. Additionally, in our situation, we also need to indicate where the build system should search for extra modules by setting an environment variable.

Now we can build the application:

Please note that we needed to add one more variable, namely BOARD_ROOT. Without this addition, we would have encountered an error regarding the missing definition of the custom_plank board. However, if you intend to use predefined boards, then this declaration is unnecessary. This concludes the final approach to developing an application with Zephyr.
Let's summarize!

‍
Summary

The Zephyr Project, hosted by the Linux Foundation, offers a comprehensive set of options for developers with its wide range of features, add-ons, and configurable modules. It is designed to be extensible, allowing custom drivers to be seamlessly integrated into projects. Zephyr's documentation reflects this complexity. The project provides three recommended approaches for application development, each with its own unique setup and advantages. These approaches include the Zephyr repository application, Zephyr workspace application, and Zephyr freestanding application, each offering different flavors and methods for setting up new projects.

Below, you can find all approaches gathered in one table with properties that are unique for each of them.

Addendum no. 1

Our experiences and opinions have been gathered on each of the methods we described.

• Repository application: We don't particularly favor this solution, as we prefer clear project structures. However, it may serve its purpose, especially for proving concepts or quick prototypes.
• Freestanding application: The absence of Zephyr version information posed challenges in one long-lasting project we participated in. Other than that, the clear project structure proved beneficial.
• Workspace application – T1 topology: We don't have much experience with this topology. While I appreciate the ease of integration facilitated by West workspaces, we’re cautious about the potential drawbacks of reduced flexibility in the long run.
• Workspace application – T2 topology: For us personally, it’s our favorite way of working. It's simple to keep track of versions and great for long-term projects because it ensures clear versioning and management, making it easier to maintain projects over time.

References

‍