This article explains the state of the successful nRF5 Software Development Kit (SDK) and why we are moving over to the scalable and future-proof nRF Connect SDK.
The nRF5 SDK has been the foundation for Nordic’s Bluetooth Low Energy (LE) offering since 2012. It is used in millions of consumer end devices and it is well-received as one of the best SDKs, if not the best, in the world of Bluetooth LE. The nRF5 SDK is a standalone software package supporting the nRF51 Series in the beginning, with current versions supporting the nRF52 Series. It offers developers a wealth of varied modules and examples right across the spectrum including numerous Bluetooth LE profiles, Device Firmware Update (DFU), libraries, and driver support for all peripherals on all nRF51 and nRF52 Series devices. It is worth noting that the nRF5 SDK is natively a “bare-metal” SDK which does not depend on an RTOS, however, the SDK also provides porting examples for some real-time operating system (RTOS) variants like FreeRTOS.
While the nRF5 SDK supports Bluetooth LE, there are multiple SDKs based on it available for different wireless protocol technologies. nRF5 SDK for Thread and Zigbee, nRF5 SDK for Mesh and nRF5 SDK for Homekit.
The Bluetooth LE stack used by the nRF5 SDK is called SoftDevice. It is a full stack including both host and controller layers in one binary file. There are several variants of SoftDevices containing different feature sets. SoftDevices are regarded as the most stable and the most popular Bluetooth LE stacks in the market as they provide cutting edge performance and outstanding interoperability.
As can be seen in the nRF5 SDK 17.1.0, we are still supporting the nRF5 SDK in maintenance mode. This means that bug fixes and security updates will be available as needed. However, support for new features beyond Bluetooth LE 5 will not be added to the nRF5 SDK. For instance, Bluetooth Direction Finding, Bluetooth LE Audio, and so forth are not supported and will not be supported in the nRF5 SDK.
The nRF Connect SDK was made publicly available in 2018. It contains support and features for both short-range and long-range devices and communication protocols including but not limited to Bluetooth LE, Bluetooth mesh, Zigbee, Thread, LTE-M/NB-IoT and GPS. nRF Connect SDK is distributed with a scalable RTOS and supports the nRF91, nRF53 and nRF52 Series. It integrates the Zephyr Real-Time Operating System (RTOS) and a wide range of applications, samples, application and networking protocols, libraries, the MCUBoot – bootloader, hardware drivers and more.
The Bluetooth LE stack is distributed differently in nRF Connect SDK compared to nRF5 SDK. The controller layer of the popular SoftDevice, with its best-in-class features, is now separately available as the SoftDevice Controller. While for the host layer, it now uses the open-source Zephyr Bluetooth Host. This separation offers a new level of flexibility to configure the Bluetooth LE stack for specific applications and better integrate with differentiating product features. The SoftDevice Controller still provides the multi-protocol support that was used in SoftDevices to run Bluetooth LE concurrently with other technologies. The SoftDevice Controller has a valid Bluetooth listing for each nRF Connect SDK release, facilitating a straightforward Bluetooth product qualification process.
It is also worth mentioning that the nRF Connect SDK includes another option for the Bluetooth LE controller, called the Zephyr Bluetooth LE Controller.
While Nordic does maintain the Zephyr Bluetooth LE Controller function on our devices, the SoftDevice Controller is supported, maintained and tested in the same way as the full SoftDevice stack has been since 2012 and is the default and recommended option for product development with nRF Connect SDK.
The nRF Connect SDK is our main SDK from now onward. It will include support for new features such as Bluetooth Direction Finding, Bluetooth LE Audio, and so forth. The SDK is distributed on GitHub which opens the doors for all forms of collaborations and enhances the speeds at which patches, and updates can be made available to customers.
All source code is pushed to GitHub during development and merged once it has been tested and proven in our Continuous Integration system. Everyone has access to the latest developed code in the main repository in addition to the “Tagged” versions that are tested in our rigorous release testing process. While only nRF Connect SDK versioned Tags are supported for product development, access to the latest development source code does give the opportunity to experiment with new features or adopt useful patches during a development cycle before a Tagged version can be taken into use.
With the increased hardware capabilities in the new generation of devices such as the nRF91 and the nRF53 Series, and due to the demand from product makers looking to reduce design time and increase code re-use between projects, it became crucial to adopt an RTOS natively. Therefore, the nRF Connect SDK was born as Nordic’s first fully RTOS-based SDK.
The nRF5 SDK is mainly focused on Bluetooth LE, ANT, and 2.4 GHz proprietary. While for Thread, Zigbee, and Bluetooth mesh, a separate flavor of the nRF5 SDK was needed per technology.
On the other hand, the nRF Connect SDK offers one configurable code base for all device series and technologies (Bluetooth LE, 2.4 GHz proprietary, Bluetooth mesh, Zigbee, Thread, LTE-M/NB-IoT, GPS, and several more). Combining multiple protocols in a single device is much easier now with nRF Connect SDK: one code base for all our products. Before, we had a separate SDK per technology. Now, with nRF Connect SDK it is all in one place.
The distribution model used by the nRF Connect SDK is through a public GitHub repository. This model is highly agile and enables us to provide updates and patches much faster than before. In addition to opening the doors for all forms of collaborations with 3rd parties, such as the vibrant and active Zephyr project members.
The table below compares the nRF5 SDK with nRF Connect SDK.
nRF Connect SDK
First release date
Latest Bluetooth LE version supported
Bluetooth mesh support
Find My Network integration
2.4 GHz proprietary support
Native RTOS support
nRF91 Series support
nRF53 Series support
nRF52 Series support
nRF51 Series support
Bluetooth LE stack options
SoftDevice controller + Zephyr host
Zephyr controller + Zephyr host
Native version control/collaboration
*Use nRF5 SDK v12.3.0 for nRF51 Series.
When to use the nRF5 SDK?
Is the nRF5 SDK deprecated?
No. The nRF5 SDK is not deprecated and it will be maintained for the foreseeable future, however, nRF5 SDK will not support new features beyond Bluetooth LE 5.
When to use the nRF Connect SDK?
How do I download nRF Connect SDK?
The recommended method to download the nRF Connect SDK is through the Toolchain Manager on Windows/Mac and the Getting Started Assistant on Linux.
What is the state of the nRF5 SDK for Thread and Zigbee?
The market-proven nRF5 SDK for Thread and Zigbee is also in maintenance mode. It supports Thread up to 1.1.1 and Zigbee up to 3.0 R22. New designs should use the nRF Connect SDK.
What is the state of the nRF5 SDK for Mesh?
The market-proven nRF5 SDK for Mesh is also in maintenance mode. It supports Bluetooth mesh up to 1.0.1. New designs should use the nRF Connect SDK.
What is the state of the nRF5 SDK for HomeKit?
It is deprecated and will not be upgraded to HomeKit Accessory Development Kit v5 (ADK v5) or any future version of the ADK. It is not possible to obtain a HomeKit certification for a new product using the nRF5 SDK for HomeKit, as it is based on the deprecated ADK v4. Use the nRF Connect SDK.
Comparing an implementation using Zephyr RTOS with an "old" bare-metal approach, how is power efficiency affected? Is Zephyr RTOS less optimized for energy efficiency due to multiple layers of abstraction…
That's the sort of thing that I'd expect with Zephyr; they are coming from a large model into a small model instead of the other way around.. It means that, in general, they are going to be bad at small. Similarly it is very difficult to take a desktop programmer and make an embedded programmer out of them -- the thought process isn't the same...
I'm hugely disappointed in Zephyr because of the basic theoretical model they are attempting to execute.
Comparing an implementation using Zephyr RTOS with an "old" bare-metal approach, how is power efficiency affected? Is Zephyr RTOS less optimized for energy efficiency due to multiple layers of abstraction?
This is coming with nRF Connect SDK v2.0.0, and it is already supported in upstream Zephyr. There are some limitations inherent to the driver model (you can only remap before you actually turn the device on, since there is no API for turning devices off right now) but those will also be resolved in time.
Runtime peripheral remapping is still not supported in Zephyr. It has been been open issue for more than a year now.
In general no, unfortunately. For Bluetooth for example the SoftDevice API is no longer available and the Zephyr Host APIs must be used. The driver library is the same - see below.