Home > On-Demand Archives > Talks >
An Introduction to The Zephyr Project RTOS
Mohammed Billoo - Watch Now - Duration: 44:00
A Realtime Operating System (RTOS) is a staple of most embedded systems. The Zephyr Project RTOS is relatively young and borrows certain elements and paradigms from Linux that may stump experienced embedded software developers, who are accustomed to a more "traditional" RTOS.
This talk will introduce The Zephyr Project RTOS, demonstrating the similarities and differences between Zephyr and a traditional RTOS. The focus will be on how to use the data structures and paradigms offered by Zephyr to accomplish tasks common to most embedded systems. This talk will also highlight key differences that seasoned embedded software developers will need to keep in mind when incorporating Zephyr into their projects.
Topics Covered:
- Navigating The Zephyr Project RTOS code base
- Creating tasks
- Synchronizing data across tasks
- Creating interrupt handlers
- Incorporating peripherals
- User space vs kernel space
Devicetree is an abomination. OMG is it bad. Just about any vendor, NXP, Renasas and Cypress have serious tools to set up various subsystems, pin assignments and what things to include much, much, much better. Way better. Device tree is not even close to the abilities of any of those tools.
It's true that it gets some getting used to, unless one comes from the (embedded) Linux kernel build environment (the resemblance is a good design choice by Zephyr committee in my opinion). But the flexibility and modularity it brings in makes it well worth it, a testament to this are the overlays Mohammed alluded to and node aliasing so that application code can remain the same while targeting different hardware just by DT configutation, Mike Szczys covers this use case nicely in his presentation.
Agreed. While it takes a bit getting used to, the reusability that devicetrees offer makes for cleaner code, in my opinion.
If using Nordic tools, the new Device Tree action in the latest nRF Connect SDK VS code extension is pretty nice. Very easy to visualize pin assignments, peripherals, etc.
targeting different hardware: If your code isn't very, very interested in what's under it; you're not doing embedded. It is never the case that I change hardware without changes to the application above it. And when I do, I track it carefully along with the application. This idea that I'd take anything and willy nilly move it to another board is ridiculous; the code is part and parcel of the hardware it lives in context with. I absolutely DO NOT want layering of hardware setups as that makes it a lot harder to find what is going on really.
Thanks for the presentation. One question I have regarding custom hardware What is the best way to handle it in your opinion: copy dev kit board and create a new devicetree ? or use an overlay over a dev kit (and build using the dev kit name) ?
Great question. Creating a new devicetree is overkill. Instead, you can use an overlay over a dev kit (since you're most likely using a dev kit as a starting point and only adjusting the pinout).
Thanks Mohammed for an insightful presentation. I didn't appreciate how well integrated Zephyr & VSCode are! I think this is an important point for developers accustomed to a front end IDEs so very appropriate to cover it for an introduction to Zephyr.
Awesome! The integration with VS Code is a game-changer for Zephyr.
If you never used Zephyr, as I, this is a great Kick-Off to start with, thank you Mohammend for the compact presentation.!
Excellent! Glad you found the talk useful.
Thank you Mohamed, for this intro to Zephyr. Looking forward to my first go on it.
Perhaps they named it Zephyr because it's a breeze to use...