The Institute of Embedded Systems at the Zurich University of Applied Sciences uses Zephyr both in research projects and for several lab exercises for BSc, MSc, and students in continuing education. These labs include topics like embedded security, bootloaders, and general operating system concepts. In this paper, we discuss the challenge of providing a uniform Zephyr development environment that can be set up quickly and reliably. At the Institute of Embedded Systems (InES), as an institute at a university of applied sciences, we have two main areas of activity. On the one hand, we teach in programs for undergraduates (bachelor's) and graduates (master's) and in continuing education. On the other hand, we work in research projects that are either publicly funded or funded by industry partners. Teaching about Real-time operating systems and their use is an essential topic in our electrical engineering, computer science, and systems engineering curricula. Zephyr is ideally suited for this purpose as it is open source, has momentum, and includes various communication stacks that enable the creation of small student projects with reasonable efort. In research projects, we need our firmware to support many diferent microcontrollers, transceivers, and sensors. At our institute, we have been working with Zephyr since version 1.14 (2019). After a first successful evaluation of the RTOS in a Master's thesis, we started using it in research projects of various kinds [1], [2] . At the same time, we have started introducing Zephyr into classes through lecture content, laboratories, and student projects like Bachelor's theses. As the students only work with Zephyr for a few hours, the efort of setting up a native Zephyr development environment on all the students' laptops seemed too high. In order to lower this efort for students to get a working Zephyr development environment, we discussed options. Initially, we used a standard Ubuntu desktop virtual machine (VM) to provide a development environment to the students. After testing this VM for one semester, we identified the following problems: • Not reproducible • Time-consuming to set up and maintain • Large (≈ 10 GiB) • Uses a lot of resources (storage, RAM, CPU) • Forces students to work inside the VM • File sharing is unreliable • Prompts the user to install updates Setting up a new VM is manual, time-consuming labor, and each time it is repeated, the output will be slightly diferent.
The student’s feedback for the VM solution revealed that the large size of the VM was especially problematic. Some students first had to free up space on their storage drives prior to the installation. Furthermore, VirtualBox’s integrated file sharing feature proved to be unreliable.
When using Zephyr in lab exercises, we need a way for the students to create, compile, and flash Zephyr applications. As time in the laboratories is limited, typically two hours per topic, we want the students to focus on the task instead of setting up their development environment. In other words, we try to maximize the time students spend on the laboratory’s content while minimizing the time spent debugging the development environment. Zephyr is new for the students; every student has a diferent setup on their laptop. Additionally, the laboratory supervisors must be able to provide help eficiently. We therefore seek an environment that has the following properties.
• Uniform
• Reproducible
• Easy to set up and use
• Easy to maintain
• Works on Windows, macOS, and Linux (aarch64 and x86_64)
The solution that we have now arrived at is based on a container. Students who use macOS or a Linux
distribution can run the container using a container engine like Podman [
• Suficiently reproducible
• Lean resource usage
• Small (≈ 2 GiB / ≈ 0.5 GiB compressed)1
• Reliable file sharing
• Students can use their familiar editor to work on the assignments
We are aware that there is an oficial Zephyr developer container image [
One inconvenience that we still face is that WSL2 does not provide access to USB devices by default.
This, for example, prevents us from flashing the firmware to the target from within the environment.
Microsoft’s solution to this problem is to use a tool that tunnels USB over IP [
Containers are built from a Containerfile. We use the latest stable Debian version as a base and install all required packages, the Zephyr SDK, and the Zephyr source code.
Our work is publicly available at [
The following is a simplified version of the Containerfile1that we use to build our container. # Install apt packages # Install pip packages # Install Zephyr SDK # Clone Zephyr A container image can then be built from this file using Podman2. Several build arguments are supported: • The Zephyr version • The SDK version • Which Zephyr modules to install (all modules are installed when this is not specified) • Which additional Python and system packages to install The following command builds a container image with Zephyr v4.2.0 for Nordic Semiconductor’s nRF platform. podman build \ --build-arg="ZEPHYR_VERSION=4.2.0" \ --build-arg="SDK_VERSION=0.17.2" \ --build-arg="MODULES=cmsis_6 hal_nordic mbedtls mcuboot segger" \ . -t zephyr_nrf_v4.2.0 1The complete Containerfile can be found in Appendix A. 2Podman is an application for managing Open Container Initiative (OCI) containers. Podman’s command line interface is designed to be compatible with Docker’s.
Depending on whether the students want to run the container in a container engine or on WSL2, the
following steps difer.
3.1. Container Engine
In order to provide the container to students who use a container engine, the container can be exported
(and compressed) to a file with the following command.
podman save zephyr_nrf_v4.2.0 | zstd -19 > zephyr_nrf_v4.2.0.tar.zst
The students can then import the container using Podman’s load command.
podman load --input zephyr_nrf_v4.2.0.tar.zst
3.2. WSL2
When using Windows, the container can be used as a WSL2 distro by importing the container’s
iflesystem. Microsoft calls this a custom distro [
We currently use the containerized environment in three separate courses: • Microcomputer Systems (BSc program) • Embedded Real-Time Software (MSc program) • Security in Embedded Systems (continuing education) In the Microcomputer Systems course and the Embedded Real-Time Software course, we use Zephyr to study real-world implementations of general operating system concepts. This includes threads, scheduling (priorities, cooperative vs preemptive, time slicing), and resource locks (mutexes, semaphores). We also look at diferent debugging methods with SEGGER Ozone and SEGGER SystemView (Figure 3). For these courses, we use a development kit with a custom carrier board (Figure 2 ) that adds additional peripherals and allows the design of intuitive lab exercises. With approximately 10 hours of Zephyr-based lab exercises per course, we believe that the use of the proposed container solution outweighs a native Zephyr installation, despite its described limitations. The container solution’s simplicity in terms of installation is especially appealing, considering the students’ heterogeneous laptop setups.
Figure 2 shows the development kit in action, displaying the current output of a lab exercise featuring the dining philosophers problem that is used to teach the use of semaphores and mutexes with Zephyr. Figure 3 shows the respective events recorded by SEGGER SystemView. Figure 2: STM32F429I-DISC1 development kit attached to a custom carrier board running a dining philosophers application. Finally, in the Security in Embedded Systems course ofered in continuing education, the participants study firmware security. The participants work on a proof-of-concept application that implements secure boot and secure over-the-air firmware updates using MCUBoot and Sysbuild. In another lab, we cover certificate-based authentication to a server using a secure element. In this course, we use a development kit with a secure element extension board (Figure 4).
On the one hand, we are still gaining experience with the current container solution and hardware boards. On the other hand, we are currently working on replacing one of the boards (Figure 2 ) with a new, adapted custom board that uses an STM32H5 chip. Because of a design constraint (multiple use of data connections) in today’s custom carrier board (see Figure 2 ), the display does not work with Zephyr versions newer than 3.1. Besides fixing this annoyance, the new chip that we plan to use has a Cortex-M33, which allows us to extend the security-related lab exercises on all course levels with ARM TrustZone.
Furthermore, we intend to gradually replace most of our course content with Zephyr-based versions. For instance, we are currently working on lab exercises for running tests on the target using Ztest and Twister.
As Zephyr sees wider adoption in our university, providing a uniform development environment for our students is important. Discussions with industry partners in our projects also suggest that Zephyr is becoming increasingly widespread in the industry.
We have tried several approaches to provide a uniform Zephyr development environment for our students. While a standard virtual machine has problems with reproducibility and uses a lot of resources, the container compensates for these disadvantages.
We have successfully used a container as a Zephyr development environment in several courses at our university, and it has proven its practicality in over 2 years of coursework.
The container is small, suficiently reproducible, and easy to set up and maintain. It allows students to use their familiar editor while providing a uniform development experience, and allows both students and lecturers to focus on the lab tasks.
The authors have not employed any Generative AI tools. # Set non-interactive frontend for apt-get to skip any user confirmations ENV DEBIAN_FRONTEND=noninteractive # Install base packages ARG ADDITIONAL_APT_PACKAGES="" RUN apt-get -y update && \ apt-get -y upgrade && \ apt-get install --no-install-recommends -y \ python3-pip \ git \ cmake \ device-tree-compiler \ wget \ xz-utils \ ninja-build \ ${ADDITIONAL_APT_PACKAGES} # Install Zephyr SDK ARG SDK_VERSION RUN test -n "${SDK_VERSION}" || (echo "SDK_VERSION build argument not set" && false) WORKDIR /opt/toolchains RUN HOST_ARCHITECTURE=$(uname -m) && \
wget --quiet -O sdk.tar.xz https://github.com/zephyrproject-rtos/sdk-ng/releases/download/\ v"${SDK_VERSION}"/zephyr-sdk-"${SDK_VERSION}"_linux-"${HOST_ARCHITECTURE}"_minimal.tar.xz && \ tar -xf sdk.tar.xz && \ rm sdk.tar.xz && \ cd zephyr-sdk-"${SDK_VERSION}" && \ wget --quiet -O toolchain.tar.xz https://github.com/zephyrproject-rtos/sdk-ng/releases/download/\ v"${SDK_VERSION}"/toolchain_linux-"${HOST_ARCHITECTURE}"_arm-zephyr-eabi.tar.xz && \ tar -xf toolchain.tar.xz && \ ./setup.sh -t arm-zephyr-eabi -c && \ rm toolchain.tar.xz zephyr-*.sh # Clean up stale packages RUN apt-get clean -y && \ apt-get autoremove --purge -y && \ rm -rf /var/lib/apt/lists/* # Install python dependencies ARG ADDITIONAL_PYTHON_PACKAGES="" RUN pip install --break-system-packages west pyelftools pylink-square ${ADDITIONAL_PYTHON_PACKAGES} && \ echo "export PATH=~/.local/bin:\"$PATH\"" >> ~/.bashrc