The Adoption of IoT (Internet of Things) technology has grown at an enormous pace. Forbes.com has reported that spending on IoT will increase to $267 billion by the year 2020, indicating how important that the technology will become to businesses around the world. Nevertheless, IoT is not without its challenges. These include security, connectivity, and choosing the right OS best suited to address those issues.
The open source Zephyr Project is setting out to resolve these issues. However, solving those problems is only one part of the IoT puzzle. What is needed is innovation and normalization — two specific components that fit well into the world of open source, giving IoT adopters the ability to delve deeper into the software that underpins IoT functionality.
The Zephyr Project entered into the small OS and RTOS market with the intent of reducing fragmentation for developers in the IoT and embedded arena. One of the biggest stumbling blocks for software with respect to IoT adoption is trying to provide a solution that solves the problems of embedded development like connectivity, security, safety certification, and in the case of small OSs and RTOSs, all with the intent of ultimately delivering real-time responsiveness.
The Zephyr Project leverages the best-known methods of open source community development, like the Linux OS, to build an RTOS for IoT that attempts to address these types of issues. This mission has helped to create a collaborative community, which is constantly growing. The community includes a broad swath of those working in the embedded development space and encourages communications, collaboration, and the sharing of knowledge to continuously improve the project.
Growing the community and encouraging more to participate will help to accelerate the evolution of the Zephyr project and bring more capabilities to the table. With that in mind, the Zephyr Project is creating opportunities for additional community outreach.
There is no doubt that the Zephyr OS codebase is evolving and becoming more important to the purveyors of IoT community. Nonetheless, strength comes in numbers and the Zephyr Project welcomes more participation from experts in the embedded community to help develop its open source platform.
The technical leadership from the project will be available at Booth L9 to answer questions about the code, discuss how to become involved with Zephyr Project, and convey the importance of the Zephyr Project to the future of IoT development.
What’s more, the Zephyr Project team will be offering demos on important components and capabilities that highlight the disruptive nature of the Zephyr OS and why it will be so important to the world of IoT. Those demos include:
Bluetooth controller on Nordic
At the event, the Zephyr Project team will bring together knowledge, action, and insight that will help to bring much needed normalization to the IoT market. Please visit us at the Zephyr Project booth at Embedded Linux Conference in Prague, Oct. 23-25 to learn more about the project and how to become part of the community.
There are a lot of benefits to being a Zephyr Project contributor. You’ll have the opportunity to improve your existing skill sets, find mentors, teach others, work with like-minded individuals, create public artifacts, build a reputation, and even learn some people skills in the mix.
Although submitting some code to improve the project can be its own reward, there is a bigger picture here. One where participants have the opportunity to become part of the innovation behind what Zephyr Project is all about, a new real time OS that will have a significant impact on IoT.
Contributing to any open source project for the first time may seem somewhat complex and intimidating. We at the Zephyr Project understand this and want to officially welcome your ideas and code contributions.
It’s pretty common for new contributors to face some basic hurdles on the path to getting a “successful pull request,” a situation where code can be reviewed and discussed for inclusion in a project, ultimately becoming part of the upstream repository. Pull requests are further covered in the Zephyr Project’s community guidelines documentation and getting to one takes following some outlined instructions in that document.
To help smooth the process, we’ve gathered some tips and tricks on how to get a contribution noticed — straight from the project’s maintainers.
Things to Do Before Submitting a Pull Request on the Zephyr Project
Before you create a pull request, it’s a good idea to orient yourself to the community a bit and make sure to address some basic issues. This will increase the likelihood that the community embraces the ideas presented in a new code snippet and the required number of reviewers approve moving ahead.
Look at Existing Zephyr Code. Contributors should always look at the existing Zephyr code before they write any new code. There may be identifiable patterns or snippets that may ease the creation of new code and can ultimately help out when developing new code.
Leverage Git-Extras. Many platforms support the git-extras package, which can greatly simplify interactions with GitHub, speeding the process and submission of code as well as handling some of the basic housekeeping chores.
Don’t Forget About IRC. Many community members are available via IRC and in many cases an simple answer to a complex question may just be one post away. IRC gives contributors the ability to share information, ask questions, get advice, and ultimately build comradery that improves interactions.
Check the Maintainers File. It’s always a good idea to do a little research before diving into creating any new code. At the very least, contributors should delve into the maintainers file to contact a maintainer of a particular subsystem directly. That in turn may provide additional background that will be useful for creating any code and also may help smooth the path to a successful Pull Request.
Remember non-Apache 2.0 Components: The Zephyr Project is robust enough to support non-Apache 2.0 components, allowing an added level of creativity. However, contributors should make sure they contact the TSC mailing list before submitting a pull request to validate component inclusion. That helps to ensure that no efforts are wasted and that the components can be included.
Taking the Next Steps
After going through what you should think of as due diligence, there are some other steps that can help smooth the path to successfully contributing code to the Zephyr Project.
Understand When to Make a Pull Request. In other words, make sure you have your ducks in a row before making a Pull Request, perform due diligence, make sure all required info is included and standards are considered.
Communicate Meta Info. Contributors often forget to include metadata, which is often a critical element that a reviewer wants to see.
Communicate Professionally. Be courteous and professional in all of your communications with the community. Disagreements need not ever turn into arguments.
Be Willing to Revise. Changes, requests, and revisions are a part of community life. Be accommodating and be willing to address concerns and make changes if need be.
Adhere to the Project Standards. The rules and standards do serve a purpose. Ultimately, they exist to keep the submission process smooth and hopefully quell any errors or bugs.
Initially Propose Small, Backwards Compatible Changes. It is the quality of the code and the purpose that it serves that counts the most. In the beginning, it’s better to focus on small changes than to try and make huge changes to the code base.
By following some simple guidelines, accepting sage advice, and communicating with the community, contributors can see their code incorporated upstream and help advance Zephyr and the broader community of embedded technologies that promotes innovation and the development of open source code.
The Zephyr™ RTOS has included support for Bluetooth™ Low Energy (BLE) connectivity since its inception. Zephyr OS 1.9 now includes a qualification-ready controller subsystem implementation to allow MCUs with a BLE radio to be connected to a processor running a BLE Host stack. Taking a closer look at the different layers that make up a full BLE protocol stack helps explain this capability.
There are 3 main layers that together constitute a full BLE protocol stack:
BLE Host: This layer sits right below the application, and it is comprised of the multiple (non real-time) network and transport protocols enabling applications to communicate with peer devices in a standard and interoperable way
BLE Controller: The BLE Controller implements the Link Layer (LL), the low-level, real-time protocol which provides, in conjunction with the BLE Radio Hardware, standard interoperable over the air communication. The LL schedules packet reception and transmission, guarantees the delivery of data, and handles all the LL control procedures
BLE Radio Hardware: The required analog and digital baseband functional blocks that permit the Link Layer firmware to send and receive in the 2.4GHz band of the spectrum
The Bluetooth Specification describes the format in which a BLE Host must communicate with a BLE Controller. This is called the Host Controller Interface (HCI) protocol. HCI can be implemented over a range of different physical transports like UART, SPI or USB. This protocol defines the commands that a Host can send to a Controller and the events that it can expect in return, and also the format for user and protocol data that needs to go over the air. The HCI ensures that different BLE Host and Controller implementations can communicate in a standard way making it possible to combine BLE Hosts and Controllers from different vendors.
The three separate layers of the protocol and the standardized interfaces make it possible to implement the Host and Controller on different platforms. The two following typical configurations are commonly used:
Single-chip configuration: In this configuration, a single microcontroller contains all three layers and the application itself. This can also be called a system-on-chip (SoC) implementation. In this case the BLE Host and the BLE Controller communicate directly through function calls and queues in RAM. The Bluetooth specification does not specify how HCI is implemented in this single-chip configuration and so how HCI commands, events and data flows between the two can be implementation-specific. The Zephyr OS supports this configuration on Nordic Semiconductor ICs, for those applications and designs that require a small footprint and the lowest possible power consumption, since everything runs on a single IC
Dual-chip configuration: Using two separate ICs, one running the Application and the Host, and a second one with the Controller and the Radio Hardware. This is sometimes also called a connectivity-chip configuration. This configuration allows for a wider variety of combinations of Hosts when using the Zephyr OS as a Controller. Since HCI ensures interoperability among Host and Controller implementations, including of course Zephyr’s very own BLE Host and Controller, users of the Zephyr Controller can choose to use whatever Host running on any platform they prefer. For example, the host can be the Linux BLE Host stack (BlueZ) running on any processor capable of supporting Linux. The Host processor may also run Zephyr and the Zephyr OS BLE Host.
The Zephyr software stack as an RTOS is highly configurable, and in particular, the BLE subsystem can be configured in multiple ways during the build process to include only the features and layers that are required to reduce RAM and ROM footprint as well as power consumption. Here’s a short list of the different BLE-enabled builds that can be produced from the Zephyr project codebase:
Combined build: This includes the Application, the Host and the Controller, and it is used exclusively for single-chip (SoC) configurations
Host build: A Zephyr OS Host build will contain the Application and the BLE Host, along with an HCI driver (UART or SPI) to interface with an external Controller chip
Controller build: When built as a BLE Controller, Zephyr project contains the Link Layer and a special application (hci_uart or hci_spi) that acts as a bridge between the UART and SPI peripherals and the Controller subsystem, listening for HCI commands, sending application data and responding with events and received data
The picture below shows the SoC or single-chip configuration when using a Zephyr OS combined build (a build that includes both a BLE Host and a Controller in the same image):
This configuration is only possible today on Nordic Semiconductor ICs, since they are the only IC family that is fully supported by Zephyr Project’s built-in BLE Controller. In the future however, the project intends to extend this support for many other SoC families, provided that their BLE Radio Hardware interfaces are publicly documented and therefore suitable for an open source implementation.
When using connectivity or dual-chip configurations, several Host and Controller combinations are possible, some of which are depicted below:
When using a Zephyr OS Host (left side of image), two instances of Zephyr OS must be built with different configurations, yielding two separate images that must be programmed into each of the chips respectively. The Host build image contains the application, the BLE Host and the selected HCI driver (UART or SPI), while the Controller build runs either the hci_uart or the hci_spi app to provide an interface to the BLE Controller.
This configuration is not limited to using a Zephyr OS Host, as the right side of the image shows. One can indeed take one of the many existing GNU/Linux distributions, most of which include Linux’s own BLE Host (BlueZ), to connect it via UART (SPI is not supported by BlueZ) to one or more instances of the Zephyr OS Controller build. BlueZ as a Host supports multiple Controllers simultaneously for applications that require more than one BLE radio operating at the same time but sharing the same Host stack.
In order to use a Zephyr OS Controller build in a commercial product, this needs to go through the Bluetooth Special Interest Group’s (SIG) qualification process. The Controller subsystem must adhere to the Bluetooth Specification and conform to the expected behavior in Bluetooth Low Energy devices. The qualification process is mandatory for all Bluetooth products, and consists of a series of tests defined by the SIG that are run against the particular implementation. Test evidence is then provided to the Bluetooth SIG to prove that the device is indeed compliant before a qualification is granted.
As part of this blog post, Nordic Semiconductor is happy to announce that Zephyr OS 1.9 passes all the required HCI and Link Layer conformance tests in order to qualify a design based on an IC of the nRF5x family as a Controller Subsystem. Pre-certification of the Zephyr OS Controller Subsystem allows end-product makers to rapidly develop BLE end-user product with confidence that their solution can be certified. Nordic will make available the qualification QDIDs (Qualified Design IDs) for the combination of the Zephyr OS 1.9 Controller build with our nRF5x series of ICs, which can then be used when qualifying end-products to fast-track product qualification, i.e. Link Layer and HCI tests do not need to be repeated by end-product makers.
The Zephyr OS Controller build, like the rest of the RTOS, is configurable. However, qualification listings include references to implemented features, which means that the features qualified for the granted QDID need to be incorporated into the Controller build. The following features have been incorporated and certified for the Controller build:
All Bluetooth 5.0 features except Advertising Extensions on nRF52x ICs
All Bluetooth 5.0 features except Advertising Extensions, Data Length Extension, 2Mbps and coded PHYs and Controller-based Privacy on nRF51x ICs
Note that Nordic’s qualification will only cover the BLE Controller, which means that whichever Host is used for a particular design will have to be qualified independently.
In order to test the BLE Controller yourself and verify if it suits the needs of your future product, feel free to grab the 1.9 release and test it out!
The frequent followers of Zephyr™ Project have probably picked it up already and are enjoying the new features of the latest Zephyr OS release. But in case you missed it: the Zephyr Project team has completed and released the Zephyr RTOS version 1.9, a next step towards our goal of best-in-breed, multi-architecture, small, scalable, secure RTOS optimized for the Internet of Things! Besides the steadily increasing number of supported boards, main new improvements are on connectivity and security. Highlights of the release are Bluetooth 5.0 including mesh support, Lightweight Machine to Machine (LwM2M) protocol support, new APIs for better compatibility with existing application code (Pthreads, BSD sockets), and additional robustness and protection features leveraging MPU and MMU hardware.
On the SoC and board-support side, Zephyr OS v1.9 for example adds support for a version of the ARC EM Starter Kit featuring SecureShield MPU (ARC EM7D with MPU), and many more: Atmel SAM4S Xplained, Olimex STM32-E407 and STM32-P405, STM32F412 Nucleo, STM32F429I-DISC1, TI SensorTag, VBLUno51 and VBLUno52 boards.
On the connectivity side, Zephyr Project’s built-in Bluetooth stack now supports all new Bluetooth LE (BLE) 5.0 features like mesh networking (except the BLE 5.0 advertising extensions). And even better, the controller part is proven qualification-ready by passing all required HCI and Link Layer conformance tests on an IC of the Nordic nRF5x family. I won’t go into details on the significance of this achievement, it deserves a blog on its own. But I do like to see this pre-certification as yet another example of the Zephyr OS’s high quality code-base and readiness for deployment. The other new connectivity feature to mention is support for the Open Mobile Alliance Lightweight machine-to-machine protocol (OMA LWM2M). This is an application layer communication protocol for device management and service enablement, designed for sensor networks and other M2M environments. It is typically used with the Constrained Application Protocol (CoAP) instead of HTTP, so LWM2M scales much better to the resource constrained devices targeted by the Zephyr RTOS than other protocols.
Last but not least, the Zephyr Project team continues to work on security enhancements by leveraging the hardware protection features found in many SoCs. In 1.8 initial support for MPU and MMU protection was added. Release 1.9 builds on that by adding stack sentinel support and initial work on thread isolation. Since this all is work in progress, these features currently might look confusing without understanding the bigger picture. The final goal of this work is to run applications at a lower privilege level and only with access to own data or explicitly shared data. That means sensitive application data can be better protected. At the same time, it enhances the robustness of the system, making it harder to maliciously exploit programming errors. Several pull requests towards this final goal have been queued up for the next release already, so stay tuned.
On behalf of the Zephyr Project team, we hope you enjoy this release. Please let us know what you think!
Bluetooth Mesh is a new standard that opens a whole new wave of low-power wireless use cases. It extends the range of communication from a single peer-to-peer connection to a true mesh topology covering large areas, such as an entire building. This paves the way for both home and industrial automation applications. Typical home scenarios include things like controlling the lights in your apartment or adjusting the thermostat. Although Bluetooth 5 was released end of last year, Bluetooth Mesh can be implemented on any device supporting Bluetooth 4.0 or later. This means that we’ll likely see very rapid market adoption of the technology.
Bluetooth Mesh Implementation in the Zephyr Project
The Zephyr OS implementation covers all layers and most optional features of the Bluetooth Mesh stack. The following is a list of some of these features and the c-files where the implementation can be found:
GATT & Advertising bearers (proxy.c & adv.c)
Network Layer (net.c)
Lower and Upper Transport Layers (transport.c)
Access Layer (access.c)
Foundation Models, Server role (health.c & cfg.c)
Both PB-ADV and PB-GATT based provisioning (prov.c)
Low Power Node support (lpn.c)
Relay support (net.c)
GATT Proxy (proxy.c)
Some notable features that are not yet part of the implementation:
Friend support (initial bits are already in place in friend.c)
Provisioner support (low-value for typical Zephyr devices)
Foundation Client models (low-value for typical Zephyr devices)
GATT Client (low-value for typical Zephyr devices)
We hope to see some of the missing features in future releases, and in particular Friend support.
Provisioning with the Zephyr OS
In order to make a Zephyr OS-based device a functional mesh node, it needs to be provisioned with network security keys as well as a unique unicast address. Since the Zephyr OS can’t (currently) act as a Provisioner for other devices, a non-Zephyr OS based implementation must be used for this. For prototyping purposes, it is possible to hard-code the address and keys in your application – an example for how to do this can be seen in the mesh_demo sample.
In practice the following options are therefore available for provisioning and configuring Zephyr OS based devices:
Self-provisioning (only for prototyping, not product-level usage)
BlueZ meshctl tool. Will be part of the next BlueZ release (BlueZ 5.47).
Integrating Bluetooth Mesh using the Zephyr OS
A mesh network consists of a fairly elaborate hierarchy of concepts. Each device participating in a network is called a node. Each node consists of one or more elements, which are the uniquely addressable entities in a mesh network. Each element in turn has a set of so called models, either standard ones or vendor specified ones.
In essence, a model defines certain states and behavior which can be influenced by sending or receiving messages. The Mesh Profile Specification includes a few so-called Foundation models, which every mesh node must support.
The Zephyr project provides an existing implementation for these, so there’s very little that an application writer needs to do about them. What remains for the application writer is then to either choose to implement suitable standard models (found in the mesh model Specification) or create custom vendor models in case the standard ones are not suitable.
In the Zephyr Project, a model is defined using the BT_MESH_MODEL() macro. The application provides as parameters: a model identifier, an array of message handlers, a message publication context, and optional user data to pass to the message handlers. The model in turn is included in an array of other models, which together form an element. To initialize mesh support, an application gives the bt_mesh_init() API call the device composition (mainly an array of elements) as well as basic provisioning capability information.
For inserting the foundation models where required (e.g. on the primary element) the application would use either BT_MESH_MODEL_CFG_SRV() or
BT_MESH_MODEL_HEALTH_SRV() instead of BT_MESH_MODEL().
To learn more about Bluetooth Mesh in the Zephyr Project and examples on how this all fits together, please check out the mesh code and sample code.
We are a Hack Space Society we believe in the use and reuse of electronics in creative ways.
We are tinkers. We believe in empowering people.
In the next 10yrs we may see an ever increasing technology growth empowering people to greater things than we can even imagine today.
In the next 10yrs we may be disempowered more than ever before, unable to repair our cars, our homes or electronics.
Every year it is increasingly easy to create low cost controllers electronic projects of all sorts.
The Zephyr Project has important role providing an Open Source RTOS platform for these electronic projects.
The Zephyr Project includes and extensive collection of unit and integration test that help refactor code required for constant and continued growth.
The Zephyr Project’s Open Source license is a compromise that we hope will encourage people and companies sharing innovation; and not keep innovation to themselves for short term private gain at the cost of fragmenting development.
Attached on one of our foundation Zephyr projects.
The Zephyr Project is happy to announce the release of Zephyr RTOS 1.8. This release was preceded by an important milestone in the Open Source project’s development that we hope will foster even further contributions and collaboration from the community: the relocation of the main source tree to GitHub. By implementing this change it is now easier than ever for developers and contributors in general to submit Pull Requests with changes and additions, simplifying and streamlining the review and acceptance process. With the transition complete and more than 300 Pull Requests already merged on Zephyr’s source code new home, we look forward to welcoming more code or documentation contributions to our repository.
In addition to being hosted on GitHub, the Zephyr source can now be built on Microsoft Windows with ease: the transition from MinGW to MSYS2 allows users to compile on this platform with ease and without the stability concerns that were a part of the previous Windows build environment. Furthermore, target platforms that require Device Tree support are now fully supported on Windows, making it possible to use, develop and contribute to the Zephyr project using Microsoft’s operating system.
But the core RTOS has also seen a slew of changes introduced since our last release. The introduction of a new tickless kernel option implements a “race to idle” approach to power management, allowing the kernel to sleep uninterrupted until an event that requires the attention of the system wakes it up without the need for periodic tick-based interruptions. Additionally, Memory Protection Units (MPU) are now supported and enabled in some of the platforms, which further reinforces Zephyr Project’s commitment to security as a fundamental tenet of the project’s philosophy. Memory protection between different execution contexts prevents interference and even malicious tampering, and this is only the beginning of an ongoing effort to harden the kernel and subsystems in the releases to come.
The networking subsystem now comes with an HTTP client and server library that allows applications to use the Internet’s most popular protocol from embedded systems directly and without the need for third-party software, and coupled with recent optimizations in its threading model (enabled by the new kernel polling APIs) and packet-based interfaces further enhances Zephyr’s built-in native IP stack to enable more than ever robust IoT applications and use cases.
Finally, the Bluetooth subsystem has gained support for new and exciting features straight out of the recently unveiled Bluetooth 5.0 specification. Nordic Semiconductor ICs running the Zephyr OS are now able to transfer data over Bluetooth Low Energy using the 2Mbit/s PHY, achieving real-world application throughputs above 1.3 Mbit/s as demonstrated in this video, as well as achieve long-range communication using the Coded PHY functionality available in our latest nRF52840 member of the nRF52 family of microcontrollers. And these are just the first steps towards full Bluetooth 5.0 support, which will continue next release with another of the hallmark features introduced: advertising extensions.
A sincere thank you to all those in the community who contributed. This release would not have been possible without your contributions!
We invite you to download Zephyr OS v1.8.0 and we welcome feedback and contributions from community.
How do you develop and sustain an operating system primed for the continuously evolving nature of the internet of things? You model it, in part, on the highly successful Linux platform, which is exactly the tactic of the Zephyr Project, an open, real-time operating system overseen by the nonprofit Linux Foundation along with a variety of other big-name industry players.
The project is pleased to announce that Runtime.io and Nordic Semiconductor have joined as Silver members of Zephyr Project!
Both Runtime.io and Nordic Semiconductor have been active contributors to the project since its launch. Both organizations bring development expertise in the development of IP and networking technologies, and in particular for resource constrained devices. We’re thrilled to formally include them as corporate sponsors.
While Zephyr Project is an open source project and welcomes contributions from the community, the project also has an established governing model to decide strategy and direction. The project has two levels of membership: Platinum where those at this level have a seat on the governing board to make decisions about the overall direction of the project and Silver where those at this level are represented by those who are voted into position. The goal of the governing and development model is to be lightweight and nimble, and leverage a proven method of open source development.
For more information about the project or to find out about membership, please contact the project at email@example.com
The Zephyr Project is still a babe in the technological woods, so it’s only fitting that the open source real-time operating system is driving an innovative wearables solution that aims to improve healthcare for infants.