Written by David Leach, Software Architect at NXP Semiconductor and member of the Zephyr Technical Steering Committee
Last month, the Zephyr Project announced the release of Zephyr RTOS 2.1. A long list of enhancements and bug fixes contained in Zephyr 2.1 can be found in the release notes.
· Normalized APIs across all architectures.
· Expanded support for ARMv6-M architecture.
· Added support for numerous new boards and shields.
· Added numerous new drivers and sensors.
· Added new TCP stack implementation (experimental).
· Added BLE support on Vega platform (experimental).
· Memory size improvements to Bluetooth host stack.
This release is the result of the hard work and skill of over 350 individuals engaged with the project over the last 3 months with over 1500 PRs merged and 532 issues closed. We would like to thank all those who engaged with the project both in front and behind the scenes to help improve the Zephyr Project for this release.
Sample boards that now have support
Improvements to Zephyr Project never stops. Work continues on the new TCP stack implementation, many different activities with Bluetooth, converting GPIO drivers to the new GPIO API, and many other enhancements and bug fixes.
We invite you to try out Zephyr 2.1. You can find our Getting started Guide here. If you are interested in contributing to the Zephyr Project please see our Contributor Guide. Join the conversation or ask questions on our Slack channel or Mailing List.
ByMaureen Helm, Chair of the Zephyr Project Technical Steering Committee
The Zephyr community converges every year at the Embedded Linux Conference Europe, and 2019 was no exception. This year we traveled to Lyon, France for an engaging week full of technical talks, spontaneous hallway conversations and hacking sessions, team dinners, and perhaps a nice glass of wine or two. It was a wonderful opportunity to get to know some of our newer members in person and finally put faces to familiar names and voices.
After the main conference, the Zephyr technical steering committee stayed on for two days of face-to-face meetings, including a few dial-ins from those who couldn’t make the trip. Compared to our weekly calls, the longer format F2F meeting allowed us to discuss and debate issues in greater depth, and make decisions about the technical direction of the project.
#1 – Mainline releases: Historically we have aimed for
quarterly releases, but will shift to a 4-month cycle in 2020. More details,
including dates, are in the Program
Management wiki page.
#2 – LTS releases: We clarified that LTS releases will be
maintained for two years, and LTS2 will be released approximately two years
after LTS1. We did not decide on a cadence beyond LTS2.
#3 – Toolchains: We agreed that multiple members have an
interest in supporting commercial toolchains and will kickoff a new
toolchain-focused working group.
#4 – User Experience: We brainstormed possible solutions to
common problems encountered by new developers.
#5 – Roles and Responsibilities: We debated a contributor ladder towards maintainership, how to distribute merge rights, and how to fill the release manager role for future releases. This conversation has continued in subsequent process working group meetings.
This blog originally ran on the Antmicro website. For more Zephyr development tips and articles, please visit their blog.
Solving problems that require real-time calculations and precise control typically calls for using an RTOS. While we have been working with a wide variety of RTOSs for various applications (like Contiki-NG for IoT, RTEMS for space applications, eCos for satellite equipment, FreeRTOS in many other fields etc), Antmicro’s RTOS of choice these days has been Zephyr, a Linux-Foundation driven, well-structured, vendor-independent and scalable real-time OS. We’ve ported and adapted Zephyr to many platforms, encouraged its use as a standard on RISC-V, promoted it in less standard contexts like FPGA devices.
So if you have a single device with a real-time requirement, typically it’s not that hard to decide how to approach the problem – just use Zephyr!
The problem starts when there are multiple heterogeneous devices that have to communicate in a standardised and robust way, performing a complex operation involving a network protocol while never leaving the “real-time” world. Scenarios like this are typical in the aerospace, automotive, robotics industries, and increasingly those industries are looking to reuse technologies known from the commercial/consumer market to leverage the massive scale offered by omnipresent, commodity tech.
For your everyday use case, the easiest way to connect multiple devices is of course Ethernet, but plain old Ethernet does not list real-time capabilities in its dictionary – how then can it be used in a real-time use case?
The set of standards that define Time Sensitive Networking is the answer to that problem. Leveraging the physical and logical foundations of Ethernet and extends it to cover real-time use cases by defining different aspects of time sensitive communication: clock synchronization, traffic shaping, scheduling, fault tolerance etc.
TSN seems then like a good fit, and sure enough, open source support for TSN is widely available in Linux. In the RTOS world however, there has previously not existed a proper implementation of TSN, readily available and tested on real hardware platforms, well, not until Zephyr 1.13!
Initial work: towards a TSN implementation in Zephyr
As a member of the Zephyr Project, Antmicro is always excited to add new functionalities to the OS, especially in fields that open it up for adoption in new use cases. Here, we were happy to work with another Zephyr project member, Intel on getting gPTP support added to Zephyr. “gPTP” stands for “generic Precision Time Protocol” and is responsible for clock synchronization. When we joined the project it was already in progress, but far from being finished. We implemented the missing state machines and fixed various bugs in the existing code.
The initial target was making Zephyr’s clocks synchronize with external Grand Masters.
Our focus was getting it to work on Microchip SAM E70 Xplained. At that time, the platform already had a Zephyr port (including the Ethernet driver), but it lacked drivers for the PTP clock.
After initial support was done and merged, we proceeded with configuring Zephyr nodes as Grand Masters, as well as ensuring operational Zephyr-to-Zephyr clock synchronization.
Qav: an important part of TSN
PTP is only a part of Time Sensitive Networking. Another important part of TSN is queue management.
The platform of our choice (SAM E70 Xplained) has multiple hardware queues built into its MAC controller, which allowed us to use the same platform to extend Zephyr’s TSN capabilities.
Antmicro implemented support for credit-based shaper algorithms in Zephyr, which are described in the 802.1Qav standard.
The work in that area required us to design an API to manage the Qav-capable Ethernet queues. Through this API/management interface, we made it possible to set and read various parameters, like idle slope, delta bandwidth, traffic class, etc.
Additionally, some status parameters were implemented. These are now shown in the regular networking shell in Zephyr for the supported network interfaces.
A network stack plays a critical role in an operating system like Zephyr. It is also constantly under very heavy development by various parties. Our work on the TSN/gPTP support was heavily influenced by all the changes in the networking subsystem. As can be expected in large development campaigns, these completely unrelated things would break our implementation repeatedly.
The reason for that was lack of more sophisticated testing of the setup. Sure, there were multiple unit tests which directly tested our stack implementation, but Time Sensitive Networking can be broken by seemingly minor changes in other parts of the networking stack.
Obviously, network protocol testing is difficult. You can either use synthetic tests that easily get outdated and don’t really reflect real life scenarios or you can create complicated physical network setups connected to a CI system – which is costly, difficult to maintain and creates only a single, static configuration.
A much better, more scalable solution is to use simulation. With Antmicro’s Renode open source simulation framework you can create script-defined complex configurations, allowing you to verify virtually every scenario imaginable.
In Renode’s 1.7 release, Antmicro added support for the SAM E70 platform, along with Ethernet with gPTP capabilities. With these new features we were able to create a CI setup testing upstream Zephyr in a virtual environment.
And thanks to an integration with the Robot Framework, it’s very easy to create new test cases in Renode. That’s why, for Zephyr, we decided to create a suite of tests verifying a range of aspects of a single application.
This lines up perfectly with the introduction of Renode Cloud Environment – a new CI system introduced by Antmicro, that you’ll be able to read about more on our blog soon. Here is a sneak peek of the TSN testing setup running in RCE.
First, Renode verifies if the board sends a PTP packet, which means that the PTP stack is started properly. Next, we analyze its reception and the proper reaction from the recipient’s OS. We analyze whether the compile-time configuration of the PTP stack is properly reflected in its runtime, and the highest level properties: whether the correct Grand Master node has been selected and whether the slave nodes are properly synchronizing their clocks.
The whole testing setup can be easily recreated with upstream Renode and Zephyr. For instructions, please refer to the TSN testing tutorial.
Building a TSN system?
If you’d like to use TSN is your system, and feel that an RTOS like Zephyr is a good fit for your needs, be sure to reach out to us at email@example.com – we’d be happy to help you apply TSN on existing and new hardware, and perhaps in simulation, for real-world use cases!
The 16th Annual Workshop on Operating Systems Platforms for Embedded Real-Time Applications will be held at ECRTS 2020 in Modena, Italy from July 7-10, 2020. The OSPERT workshop itself takes place on July 7.
OSPERT is a satellite workshop of the 32nd Euromicro Conference on Real-Time Systems (ECRTS 2019), the premier European venue for presenting research into the broad area of real-time and embedded systems. OSPERT is open to all topics related to providing a reliable operating environment for real-time and embedded applications.
The Linux Foundation’s Kate Stewart will give a keynote on July 7 about the RTOS landscape and how Zephyr is the leading RTOS for IoT and embedded devices.
Stay tuned here for more details. For more information about the conference, please visit the ECRTS website.
Embedded World 2020 takes place on February 25-27, 2020 in Nuremberg, Germany. Now in its 18th year, the conference covers all aspects of the development and application of embedded systems, from fundamental technologies to development processes and special fields of application. With nearly 2,000 participants and 31,000 visitors the conference has over the years become an international meeting place for the professional embedded developer community.
Zephyr will be on display on the show floor again this year. Several Zephyr project members will be on-site in booth Hall 4-170. More details coming soon….
In addition to the booth, several of the Zephyr Project leaders will be giving presentations.
On Wednesday, February 26:
At 11:30 – 12 pm, Prof. Robert Oshana with NXP Semiconductors, will give a presentation titled, “Practical Software Testing Techniques and Guidelines for Embedded Systems.” Embedded technology has revolutionized sectors of the industry in ways that were previously never thought possible. For this reason, product testing is becoming increasingly important. Ensuring that our embedded technology functions properly is a priority for most companies, regardless of where that technology happens to be located. In this presentation we will explore white box and black box techniques for testing embedded systems, talk about system and performance testing, and summarize some of the unique testing requirements and approaches for real-time embedded systems. Topics include static and dynamic analysis techniques, exploratory testing, equivalence partitioning and boundary value analysis, and hueristics based testing methods.
At 12:30-1 pm, Kate Stewart with the Linux Foundation will give a presentation titled, “Safety Certification and Open Source – Can They Work Together?”
The last 20 years have seen a tremendous surge of new technologies and capabilities emerge from open source software. These open source building blocks have become increasingly attractive as the base for innovative new products. Safety critical applications are now using them as well, but we lack infrastructure to assess when this software is safe to use, that can keep up with the rate of change of open source development. Her talk will look at some of the challenges and approaches to building trust and confidence in open source used in safety critical software coming to new products. The approaches taken by 3 open source projects (Linux, Xen, Zephyr) will be discussed and contrasted.
At 12:30-1 pm, Pal Kastnes with Nordic Semiconductor, will give a presentation titled, “Bluetooth Security – A Technical Overview & Implementation Guide for Embedded Developers.” The Bluetooth specifications enable advanced security features to accommodate a wide variety of embedded applications and systems. This session will provide implementation guidelines to help embedded developers understand the range of security options available when developing with Bluetooth, as well as some best practices to follow when securing Bluetooth devices and solutions.
At 4-4:30 pm, Martin Woolley with Bluetooth SIG will give a presentation titled, “Bluetooth Location Services and High Accuracy Direction Finding.”Bluetooth can be used for many types of location service and it’s an area forecast to experience the biggest growth in the next few years, with 431 million location related devices shipping in 2023. In 2019, Bluetooth acquired a new capability which allows the direction of a signal to be accurately determined using one of two methods known as Angle of Arrival (AoA) or Angle of Departure (AoD). Come to this session and hear about this Bluetooth location services and the new direction finding feature, how it works and the uses it’s likely to be put to.
At 4-4:30 pm, Prof. Robert Oshana with NXP Semiconductors, will give a presentation titled, ” Guidelines, Tips and Tricks for Managing Open Source Software for Embedded Systems.” Open source software is ubiquitous in embedded computing. Whether you are using the Linux or Zephyr operating system, open source machine learning components, or any other form of community based software, its important to understand the basic guidelines and principles for developing and managing open source software. This presentation will use multiple actual industry examples to demonstrate practical tips and tricks for open source software development. Topics include developing an open source policy, understanding the basics of licensing open source software, how to update promptly, using a binary repo manager, how to particpate in the community and upstream software, how to use the proper build tools, tips for how and when to fork, and other practical examples. With the right framework and understanding, open source development for embedded systems can be more efficient, and less risky and error prone for the developer and the organization.
At 2-2:30 pm, Prof. Robert Oshana with NXP Semiconductors, is giving a presentation titled, “RISC-V Hardware and Software Technology for Industry.” RISC-V is a free and open ISA enabling a new era of processor innovation through open standard collaboration. The RISC-V foundation now has close to 300 member companies and universities, and growing. This talk will focus on the state of the technology for RISC-V. We will discuss the latest developments in the RISC-V foundation regarding technology development, discuss some of the new communites like openHW Group that are dedicated to creating high quality open source RISC-V implementations for the masses. We will discuss industry adoption of RISC-V, using actual examples of how to incorporate RISC-V into a corporate design flow. We will discuss what is being done to manage hardware and software fragmentation in this growing community, and the state of the RISC-V ecosystem. We will show examples of how to innovate by using the powerful instruction extension capability of the ISA.
Written by Ivo Clarysse, CTO at Blue Clover Devices
This blog previously ran on the Blue Clover Devices website. You can view the website here.
IOT OS LANDSCAPE
These days there’s no lack of operating systems to choose from for embedded systems; Wikipedia counts about 100 of them. The Eclipse survey still shows Linux leading the pack, with Windows, FreeRTOS and Mbed OS being widely used as well.
For devices that have the necessary resources, full-blown operating systems like Linux (Android) or Windows dominate the field, but for more constrained devices, there’s a wide range of systems being used.
The Eclipse IoT Developer Survey 2019 shows more use of actual operating systems in IoT device firmware, as opposed to bare-metal programming or building on top of a minimal kernel.
Linux is widely used for IoT applications, but requires at least a Cortex-A MCU (or equivalent), and is not the preferred choice for more limited systems, such as Cortex-M.
FreeRTOS is quite popular in the embedded world and gets more support after the acquisition by Amazon in 2017. However, FreeRTOS is a bare operating system. Everything else such as drivers, file systems, crypto modules, network stacks, middleware, and a bootloader must be added from other sources.
ARM’s Mbed OS has the out-of-the-box integration with ARM’s Pelion Device Management going for it, making it a great choice to learn about IoT device provisioning, connection and management through LwM2M. Provided by ARM, it obviously does not support popular IoT platforms like ESP32 or RISC-V.
Mynewt has everything you could wish for in an operating system for resource constrained IoT devices, but the BSP support is fairly limited.
Zephyr originated from the Virtuoso DSP operating system which initially got rebranded as “Rocket” kernel, following its acquisition by Wind River Systems, but became Zephyr in 2016 when it became a Linux Foundation hosted Collaborative Project. Major sponsors and contributors of this open source collaborative effort include Intel, Nordic Semiconductor, NXP, SiFive, Synopsys and TI.
Like many other operating systems, Zephyr provides:
Secure bootloader (MCU Boot)
File systems (NFFS, LittleFS, NVS)
Middleware (including the MCUmgr OTA mechanism and LwM2M client functionality)
Zephyr is mostly licensed under the Apache 2.0 license, but drivers from Nordic and NXP are licensed under the permissible BSD-Clause-3 version, although some of the build tooling is GPLv2.
Amy Occhialino is the Chair of the Zephyr Project Governing Board and Director of Software Engineering at Intel. She has more than 20 years experience in technology and has recently shared insight into the social change in open source software at several conferences. She recently gave the keynote at The Consortium for Computing Sciences in Colleges and the Society of Women Engineers. In this blog, Amy shares some of that insight from her talks.
You may know Intel only as a hardware company, and in many ways this is true. Intel’s core business is semiconductor design and manufacturing. What may be news to you is that Intel has spent close to two decades working in the open source software community, collaborating on projects that enhance Intel Architecture and advocating for the beauty, elegance, and possibilities that exist within open source software development.
Intel software engineers are key contributors to the Linux kernel, are Linux kernel maintainers, and hold many software standards and leadership positions within open source projects and communities. Open source software development is an enormous commitment and investment at Intel. In fact, we went from sponsoring 12 open source projects to 200 spanning cloud, edge, and device growth over the last decade. The Zephyr Project is a great example of this.
Leading the future will require a wide range of perspectives, backgrounds, and ideas to effectively solve the world’s toughest challenges. We, as a technology community, are bound to fail if we do not demonstrate a commitment and passion to increasing and achieving full representative diversity within the open source software industry.
Our success will be threatened in three ways:
Market Failure: Without diversity-fueled creativity, innovation is stifled. The same perspective and thoughts are generated and reinforced, preventing new solutions from emerging.
Customer Failure: We will lose customers because we don’t listen to them, engage with them, understand them, and learn from them in a full perspective of ways.
Talent Failure: We will lose top talent because individuals with diverse backgrounds feel out of place in our culture and environment.
The Zephyr Project is committed to achieving an inclusive and diverse open source environment. We encourage any and all developers interested in the RTOS landscape to join the conversation and share your interests and talents with the community. Change doesn’t happen all at once, it’s incremental, one person doing one thing every day.
For me, I personally increase diversity in my own teams through my hiring practices, I have spent a decade creating support systems through my leadership of women’s groups, and I actively advocate for social change within Intel and my tech community. I am proud that Zephyr is part of this as an open source project with a high amount of diversity
Open source software gives us the potential conditions, but we must actively engage with it, and monitor it, for it to be what we want it to be.
On Wednesday, November 13, the Society of Women Engineers will host its November meeting at 5:45 pm at the Shiley School of Engineering, located at 5000 N. Willamette Blvd in Portland. Zephyr Project Governing Board Chair Amy Occhialino, Director of Software Engineering at Intel, will give a keynote about “Social Change in Open Source Software.”
To learn more about this event, visit the Shiley website here.
The Internet of Things Helsinki is hosting a Zephyr RTOS Meetup on Tuesday, November 12 from 6-8 pm at Intel’s office, located at Westendgatan 7 (meeting room Halti). Several Zephyr Project Community Members will be on-site to provide an overview of the RTOS, insight into Bluetooth Mesh and share demos. The sample agenda is below:
Andrei Laperie will present an overview titled, “Zephyr OS: an introduction for engineers.” He’ll share a brief look at the project’s history continued with the walk though Zephyr’s key architectural modules and use cases.
Johan Hedberg will present a session about “Using Bluetooth for IOT: Bluetooth Mesh and other modern standards in Zephyr stack.” The BLE stack in Zepyhr is a de-facto SIG reference for embedded development; we will look at currently supported standards and the practicalities on using them.
Demos will be on-site that demonstrate Bluetooth, USB and networking technologies supported in Zephyr on the hardware and in emulator.
This is a half-day, single-track event designed to introduce you to the leading Open Source RTOS built with safety and security in mind. Attendees will learn why Zephyr is gaining the attention of developers, with its support for BLE, OpenThread, LTE-M/NB-IoT cellular communications, and more. Learn about the latest security enhancements with Zephyr OS LTS, as well as the progress toward Functional Safety Certification. In the second half of the session, attendees will receive hands-on experience with boards which have been graciously donated by Zephyr Platinum Member Nordic. Stay tuned for specifics.