DigiKey - Introduction to Zephyr Part 1: Getting Started - Installation and Blink | DigiKey
Zephyr is a real-time operating system designed for IoT devices, providing a full build system integrated with vendor development kits. It offers extensive libraries, including device drivers, networking stacks, and graphics drivers, making it suitable for professional-grade, cross-platform firmware development. However, the learning curve is steep, particularly for those without experience in Linux device driver development. Zephyr is recommended for projects involving more complex IoT applications rather than simple tasks like blinking LEDs or reading sensors, where simpler systems like FreeRTOS might suffice. The series aims to guide users through the setup and use of Zephyr, starting with a Docker image to simplify installation and progressing through various components like device trees, bindings, and debugging. The course also covers creating custom board configurations, essential for engineers working with custom PCBs. Zephyr's history traces back to the Virtuoso OS, and it has evolved with support from major companies, positioning itself as a promising open-source solution for embedded systems.
Key Points:
- Zephyr is ideal for complex IoT projects, offering extensive libraries and cross-platform capabilities.
- The learning curve is steep, especially for those without Linux driver development experience.
- Zephyr is best suited for 32-bit microcontrollers with at least 4KB of RAM.
- The series provides a step-by-step guide to using Zephyr, starting with a Docker image for easy setup.
- Custom board configurations are essential for engineers using custom PCBs, and the course covers this in detail.
Details:
1. 🔍 Introduction to Zephyr
1.1. General Overview of Zephyr
1.2. Technical Capabilities and Applications
2. 🚀 Getting Started with Zephyr
2.1. Introduction to Zephyr
2.2. Setting Up the Environment
2.3. Local Installation and Exploration
2.4. Introduction to CMake
2.5. Konig System Overview
2.6. Linux Tools Integration
2.7. Device Tree Introduction
2.8. Bindings and Driver Development
2.9. Writing Device Drivers
2.10. Debugging Techniques
2.11. Advanced Functionality
2.12. Graphics and Connectivity
2.13. Custom Board Configuration
3. 🛠 Prerequisites and Setup
3.1. Prerequisites
3.2. Setup Instructions
4. 📜 Zephyr's Origin and History
- In 2001, Wind River Systems acquired Eonic Systems, which developed digital signal processors, and subsequently open-sourced Virtuoso under the name of Rocket in 2015.
- The Zephyr Project was announced by the Linux Foundation in February 2016 as a new project to build a real-time operating system for Internet of Things devices, with support from Intel, NXP, and Synopsis.
- Zephyr version 4.0 was released at the end of 2024, but version 3.7 is used in this series because it was available when recording started.
- Since the project's inception, Analog Devices, Nordic, Qualcomm, Arm, Infineon, Renesas, Silicon Labs, STMicroelectronics, and Wind River have all been involved.
5. 📈 Evolution and Current Support
- Zephyr is evolving into an open-source professional operating system particularly for small embedded systems like IoT devices.
- The learning curve remains steep due to reliance on older Linux systems like the device tree.
- It is recommended to use the esp32 S3 devkit C for Zephyr projects due to compatibility with examples and documentation.
- Using non-supported boards can lead to difficulties, as Zephyr relies heavily on board and device tree definitions.
- For those following the course, setting up a breadboard with specific components such as an LED, buttons, and sensors is recommended.
- A detailed component list and diagram are provided for easy assembly, with links to purchase components from Digi-Key.
6. 🔧 Installing and Configuring Zephyr
- Zephyr supports multiple operating systems: Ubuntu, Mac OS, and Windows. Installation specifics differ per system due to its dependency on the OS.
- The development process for Zephyr is intertwined with West, a repository version control tool, which is integral for managing development projects.
- Zephyr's comprehensive nature means its size includes all necessary libraries and headers for supported boards, which can be cumbersome when developing multiple applications.
- The T1 or T2 topology is ideal for single, large applications; however, for multiple simple applications, a T3 Forest topology is recommended, separating applications from modules without a manifest file.
- Zephyr OS and SDK are distinct, each with separate repositories under the Zephyr project. The OS provides source code and libraries, while the SDK offers toolchains and tools for building target applications.
- To simplify installation, a Docker image provides a pre-configured Debian environment, beneficial for uniform setup across different systems.
- Windows users are required to install WSL and Docker Desktop to leverage the Docker image for Zephyr.
- The Docker image is substantial (4GB), reflecting the extensive resources included in Zephyr OS and SDK.
- Running the Docker image typically removes the container post-use, ensuring a clean environment for recurring educational purposes.
- Local ports and directories are mapped in Docker setup to facilitate seamless access and interaction with Zephyr components.
- For a smoother experience, especially on Windows, detailed steps for setting up WSL and Docker Desktop are recommended, along with troubleshooting tips for common installation issues.
7. 🖥 Using Docker for Zephyr Development
- The VS Code interface is accessible via Local Host Port 8800.
- The CMake extension may require configuration adjustments specifically for Zephyr's toolchain to ensure compatibility, with a focus on enhancing syntax highlighting in CMake files.
- The workspace is structured into two primary directories: the SL workspace, which is seamlessly mounted from the host, and the opt tool chains Zephyr, representing the Zephyr OS environment.
- Changes made within the SL workspace are automatically mirrored on the host machine, facilitating straightforward code backup processes.
- The root directory encompasses a Zephyr code workspace file that delineates the workspace setup, ensuring a cohesive development environment.
- To address potential configuration challenges, especially concerning the CMake extension, users should verify toolchain paths and compatibility settings.
- For optimal development flow, ensure the Docker container is correctly configured to interact with the host system, particularly focusing on file synchronization and network settings.
8. 🔗 Connecting via SSH and VS Code
- Install VS Code and the Remote SSH extension to work with ZHR without local installation.
- Connect to the container using SSH with root@localhost and port 2222.
- Remember the SSH fingerprint on initial setup and use 'zephyr' as the password.
- VS Code server version must match the local version, so it downloads a matching server version.
- Open the workspace from the /root directory within the copied Zephyr workspace.
- Install recommended extensions for Microsoft and Nordic when prompted.
- Extensions and VS Code are removed upon image shutdown to maintain a clean environment.
- If prompted by the CMake extension, choose 'unspecified' if no kit is set up.
- The workspace is mounted from the host machine, ensuring changes are reflected there.
- Pre-written course code is available in the apps directory.
9. 💡 Building and Flashing Your First Zephyr Application
- Begin with a basic 'Blink' application to test code functionality and compilation.
- Utilize a device tree source file to define hardware configurations, ensuring application code portability across different boards.
- Use 'West' as a meta-tool to manage builds, calling 'cmake' to create a build directory if it doesn't exist, and use '-p' (pristine) option to clean the build directory before compiling.
- Specify the board (e.g., esp32 S3 uncore devkit C) and CPU (e.g., pro CPU) during the build to ensure compatibility with the hardware setup.
- Device tree compiler (DTC) overlay files connect hardware components to GPIO controllers with specific flags (e.g., gpio active high) and aliases for code reference.
- A 'CMakeLists.txt' is required to define the project, and a 'prj.conf' file (even if empty) is needed in the application directory for a successful build.
- Troubleshoot common errors such as incorrect board specifications or missing configuration files to prevent build failures.
- Successful builds generate a build directory with compiled outputs like ELF and BIN files necessary for flashing.
- Flash the application to the hardware board using generated BIN files, ensuring alignment with defined hardware configurations.
10. 🛠 Flashing Firmware and Testing Output
10.1. Setting Up the Environment
10.2. Flashing the Firmware
10.3. Testing and Troubleshooting
11. 🔍 Checking Console Output
- Use the P serial package for accessing serial communication tools like miniterm on Python DM, which works across platforms.
- To identify your device's COM port, check device manager on Windows or use 'ls /dev/tty.*' on macOS/Linux, and then set the baud rate to 115200.
- Monitor boot messages and LED state changes from devices like ESP32 and Zephyr to diagnose issues or confirm operations.
- Example: If using an ESP32, observe messages that confirm successful booting and LED toggling to ensure correct setup.
12. 🎓 Conclusion and Further Learning
- Learning Zephyr requires patience and persistence, promising significant benefits, such as developing cross-platform firmware for embedded systems without Linux.
- Each video ends with a challenge to extend the demo, with solutions provided for self-assessment.
- The next episode will introduce Cake and its application in Zephyr.