From System Design to Source Code: Tobias Kästner on Zephyr
Cette publication existe aussi en Français
In the run-up to the Elektor online conference “Zephyr – The Open RTOS for Tomorrow’s Devices”, which takes place on 5 November, we spoke to speaker Tobias Kästner about the importance of functional architecture in modern embedded projects. The Solution Architect (medical) IoT at the consulting firm inovex explains how the Zephyr framework helps developers translate complex system requirements into maintainable and flexible software structures.
Elektor: You will be giving the following presentation at the conference: ‘Zephyr in Practice: From Functional Design to Efficient Implementation’. Why is the topic of ‘functional architecture in Zephyr’ particularly relevant right now?
Tobias Kästner: Actually, the topic of functional architecture is always relevant. For me, it represents the first important step from analysing a system’s use cases to the relevant system functions that we need to implement with our software design.
As I would like to show in my presentation, Zephyr offers particularly exciting possibilities here, which make it much easier for me to arrive at a clean software design based on the results of my system analysis, i.e. the functional architecture.
Elektor: What would you recommend to developers who are starting with Zephyr and want to implement a functional architecture?
Tobias Kästner: Zephyr is a powerful and very comprehensive framework. Getting to grips with all the possibilities it offers takes time and a certain amount of perseverance. But you will be rewarded with the best technical framework for embedded software design available on the market today. For software architects in particular, it offers completely new possibilities for converting their architectural designs into source code.
Functional architectures originate from systems engineering, where they are a recognised method for analysing and describing complex systems. Zephyr is ideal for designing software for precisely such complex systems.
Elektor: How exactly does Zephyr help to achieve faster feedback and shorter development cycles?
Tobias Kästner: Zephyr comes with a wide range of ready-made services that only need to be ‘enabled’ in your own applications.
My favourite examples are the shell and the logging framework. As a developer, the shell in particular gives me the opportunity to try out initial partial functionalities at an early stage before combining them into larger applications. The driver model, which has produced several hundred drivers in recent years, also contributes to faster development cycles. Hardly anything that anyone has ever needed anywhere needs to be implemented again. This saves time and nerves.
Elektor: You are referring to the KConfig configuration system, which is also used in the Linux kernel, and the hierarchical data structure for hardware description, Devicetree, for modelling system features. Can you provide an example of how this works in practice?
Tobias Kästner: In practice, I use KConfig extensively to model my firmware projects. The integration with the KConfig symbols already existing in Zephyr is seamless and is mapped by the same tools and process steps in the build system. This allows me, for example, to ‘switch on’ only specific functions for testing purposes, because not all components are yet available on the prototype hardware in front of me. Or I can easily switch back and forth between multiple implementations against a common API by using either CONFIG_ACME_HEATER_TWOPOINT=y or CONFIG_ACME_HEATER_PID=y, for example.
These so-called feature toggles always leave all code on one branch and make integration much easier, especially in larger teams.
Elektor: You will talk about the importance of emulation for development and testing strategy. Which tools or approaches do you recommend here?
Tobias Kästner: As I just described, KConfig’s flexibility can also be used to enable either the ‘real’ implementation or an emulation. This can be decided separately and independently for each sub-functionality.
Add to this the excellent support for emulators that Zephyr offers, and you have powerful process models for test-driven development, which we value so highly in agile projects.
Elektor: What were your most important learnings when mapping architecture to Zephyr components?
Tobias Kästner: In order to exploit the full potential of the possibilities offered to me as a developer or architect by Zephyr, understanding the three components KConfig, Devicetree and CMake-based build system was certainly the most important lesson. It is precisely the interaction of these three technologies that results in many synergies that make working with Zephyr unique. The reward for this effort is maintainable architectures that are both stable and flexible and can be adapted to changing system requirements with minimal and, above all, predictable effort.
For more information on Elektor’s online conference “Zephyr – The Open RTOS for Tomorrow’s Devices” on 5 November, see the conference website.
Register today!
Editor’s note: eeNews Europe is an Elektor International Media publication.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
