Contributed by Nordic Semiconductor, a Platinum Member of the Zephyr Project and the Zephyr Developer Summit
A few years ago at Nordic we took the decision to start working on a brand new Software Development Kit for our Integrated Circuits. Our existing software offering (the bare-metal nRF5 SDK) had served our customers well for years, but it was starting to show its age. In particular there were a few major issues with it we wanted to address.
Firstly, as our wireless MCUs were becoming more powerful in terms of CPU performance, and having more memory, a bare-metal SDK was progressively less suited for them. Instead, offering a modern and fully-featured real-time operating system (RTOS) as part of the SDK allows users to take advantage of the increasing capabilities of Nordic ICs.
Secondly, and in part due to the bare-metal nature of the SDK, Nordic had to develop and maintain a proprietary software framework. Fundamental data structures like queues or ring buffers, basic primitives such as mutexes and atomic operations, or even essential tools like a logging subsystem and a timer mechanism had custom implementations for the SDK and had to be maintained and ported to newer SoCs over time. Even more complex subsystems or protocol stacks, such as TCP/IP or USB, had to be either developed in-house or adapted from existing open source projects in an ad-hoc manner.
Thirdly, and partly as a consequence of the first two points, the Nordic software offering had become fragmented. The various teams within the company, each focusing on a different set of technologies, were putting out independent SDKs, each with their own release schedule, their own variants of the software framework mentioned earlier and their own peculiarities when it came to build and configuration systems. This made combining technologies (for example, Bluetooth Mesh and Zigbee) very cumbersome, since it had to be done manually by the user by taking code from multiple locations and then putting it all together and creating a configuration that was not built or tested by Nordic.
Finally, the distribution model of the SDKs had started to become a problem as well. All those SDKs were made available to Nordic customers as a downloadable .zip file. This had the advantage of being logistically very simple to manage, but also meant that updating to a later version of the SDK (or multiple SDKs in case of application making use of several technologies!) was a very complicated, slow and error prone manual process.
Nordic set out to design a next-generation SDK with the objective to address the issues identified, and to support a development model that would allow our engineers to add uniquely valuable software for our wireless SoCs, leveraging common source code and sharing framework implementations between technologies. This led us to an emerging open source RTOS, Zephyr. A lengthy prestudy and many upstream contributions later, we decided to adopt Zephyr as the foundation of our new SDK, now known as the nRF Connect SDK. This SDK is, in many ways, a complete departure from our previous offering, and adopts approaches and practices learned from Zephyr’s development community, applying them selectively to its development model.
Diagram of the nRF Connect SDK. Gray boxes are open source components:
The nRF Connect SDK was built to improve our development and distribution model, deliver software supporting Cellular IoT and Wi-Fi connectivity in addition to BLE, Thread, Zigbee and Matter technologies, and incorporate the Zephyr RTOS – maximizing re-use and minimizing the maintenance effort. It reuses many components and infrastructure from Zephyr, several of which were developed by Nordic engineers and contributed upstream to the project. Among those there are:
- The build and configuration system, including the hardware description language (Devicetree) and the software configuration tool (Kconfig)
- West and the module infrastructure, which allows the SDK to create its own distribution of multiple open source projects that are part of it
- The RTOS kernel, logging, shell, driver model, file systems and multiple protocol stacks (Bluetooth LE Host, Mesh, TCP/IP, …)
- Twister and the ztest framework that is used to verify the functionality above
While developing the new SDK, we made a few choices that proved to be consequential to the success of the approach.
For instance, keeping a very clean fork of Zephyr, almost free of downstream changes, means that updating it regularly to get the latest from Zephyr and staying in sync with all the upstream code we submit is easy. We decided the SDK would consist of multiple repositories to preserve clean forks, avoid filtering repositories and mixing code with different licenses. Doing this required a way to manage configurations of multiple repositories and resulted in Nordic engineers heavily contributing to the design and development of the West tool for Zephyr repository management now used both upstream in Zephyr and in the nRF Connect SDK.
Another key decision was to leverage, improve or altogether contribute all the functionality that makes sense in the Zephyr RTOS, and is not proprietary, to avoid out of tree patch maintenance, and the risk of duplicate implementations in Zephyr and the nRF Connect SDK that would confuse users. This includes the kernel, but also the logging and shell subsystems, file systems, the driver model and even multiple protocol stacks.
We use Devicetree, Kconfig, Twister and the ztest framework, as well the Zephyr build system. This made developing and maintaining the SDK easier, but also provided powerful features to our users to manage the build and configuration of their own boards in a scalable and maintainable manner.
Upstreaming all Nordic Development Kit board definitions and support builds for these boards in Zephyr was fundamental too. This means that nRF Connect SDK gets its board definitions and drivers “from Zephyr”. The advantage is that our customers can use our devices with Zephyr directly, or with nRF Connect SDK and our integrations can be tested upstream in CI.
Finally, we decided to maintain a fully open source Bluetooth LE Link Layer implementation. Even though Nordic has a proprietary implementation of this component, maintaining a full Bluetooth LE stack (including Host and Link Layer) in open source that works with Nordic devices allows upstream tests on real hardware of the complete stack, and facilitates joint developments in the stack – like Bluetooth LE Audio upstream – where multiple companies collaborated on the work.
Nordic’s SDK now includes a modern RTOS with all the functionality and performance that is expected today, as well as scaling from our smallest short range Bluetooth LE devices to our largest Cellular IoT (LTE) devices. Beyond the frameworks and components that nRF Connect SDK leverages from the upstream Zephyr project, the SDK’s development model is also inspired by the open source way of getting things done. Nordic has now a single SDK is that is entirely developed in the open on GitHub, with Nordic employees in different internal projects and working on different products contributing to the codebase exactly in the same way as any other person with a GitHub account can. This means that users of Nordic SoCs can open Pull Requests to modify or improve the code of the SDK, instead of having to keep local changes and carry them over to newer SDK versions. This democratizes access to the source code as well as introducing changes to it, which long-term benefits the quality of the firmware and its reliability.
The issues that Nordic set out to resolve with this next-generation SDK based on open source software are now a thing of the past.
By adopting the Zephyr RTOS and collaborating with the community on its development, Nordic now has a fully integrated SDK for all our wireless SoC products, a modernized software solution, and is able to leverage software not directly related to our core low power wireless competencies from open source projects, allowing our engineers to focus on the areas that are at the heart of Nordic’s value proposition. Users of Nordic SoCs obtain the source code using modern source control distribution technologies, including Git, which makes updating to newer releases of the SDK a much simpler process.
If you’d like to find out more about nRF Connect SDK and how it combines open source projects with Nordic proprietary technology to deliver cutting edge performance and scalability you can visit the following websites:
- The nRF Connect SDK documentation
- Nordic Academy: nRF Connect SDK fundamentals
- Webinar: Exciting new features in nRF Connect SDK v1.9
- Nordic’s webinar page
- Introducing nRF Connect for VS Code
Nordic is a Platinum Member of the Zephyr Project and the Zephyr Developer Summit, which takes place on June 8-9 at the Computer History Museum in Mountain View, CA. To learn more about the Summit, check out the sessions led by Nordic leaders or to register for the event, click here.
