Get best of the week

What is the new nRF Connect SDK for Nordic? Evolution, revolution or alternative?

Last week, Nordic Semiconductor added nRF52 series support to the nRF Connect SDK.



The main question that most people have is what is it and why is it important? This question is especially relevant for those who have experience with the nRF5 SDK, and there are many of them.

I note right away that the article is primarily written for those who use traditional approaches in the development of Cortex-M level or close devices. Therefore, some definitions and analogies may not seem completely correct from the point of view of those who work at a high level (looks at what is happening on the Linux side), but it will be easier to understand for those who are just starting this way.

Comments and clarifications are always welcome.

A little about who Nordic is and how they are doing well now
Nordic . , , Bluetooth Low Energy, 90% . : Starline, Pandora, Scher-Khan . Redmond, Ready4Sky. . 2 .

Nordic Semiconductor 40%, 2.5 , (TI). , . , Samsung Xiaomi Nordic , , .

, Nordic, , . nRF5x STM ( ).

:

  • ( )
  • SDK
  • ( )
  • Altium

, Nordic Semiconductor .

Here the main question arises, why was the new SDK released and how does it differ from the current one? If so, everything is fine with the current solution.

The current nRF5 SDK works on the basis of a simple queue, and in most cases this is enough to implement almost any task (although some companies still use their own SDKs, but these are exceptions to the rules). The new nRF Connect SDK uses a radically different approach based on Zephyr RTOS. Consider the differences in more detail.
RTOS (RTOS) carry both certain advantages and known disadvantages. The latter include:

  • additional overhead for maintaining the OS
  • great complexity of development on simple projects
  • increased build complexity

The rest of the RTOS are:

  • increased reliability due to control of individual flows

Within Nordic, this has become interesting and relevant since the introduction of the new system in package (SIP) with LTE Cat-M / NB-IoT / GPS - the nRF91 series. This SIP has higher performance due to the new Cortex-M33 core and other requirements for the network component, which appeared due to the transition from BLE to cellular networks. Another innovation here was the SDR modem, which works on a separate core and with which it was necessary to organize internuclear interaction. For the first time, the RTOS-based SDK appeared here, and for those who first encountered a new approach, it raised a number of questions, starting from the preparation stage. A special assistant was also released for the correct assembly of the development environment - Getting Started Assistant. He tells you which components you need to install (there are a lot of them, see below), and checks that everything is installed correctly.

image

From this point of view, we can compare the transition to Zephyr with the appearance of the first mass ARM Cortex-M and the transition to 32 bits. Now the majority use 32-bit MKs as the main ones, about which there is an article on Habré. It also tells about the transition, which initially seemed unnecessarily complicated. But over time, almost everyone came to the conclusion that this has become the standard.

It is worth noting that Zephyr OS is not the only RTOS running on Nordic chips. Examples of projects with FreeRTOSAvailable in SDK v.11 starting in 2016, and even earlier in SDK v.9 there was Keil RTX support for the nRF51 family (2015). However, earlier these were more experimental functions and support was provided to a greater extent by RTOS manufacturers. Which, in principle, is true now.

Unofficial Zephyr support for the nRF5x families appeared back in 2016 .

Zephyr Nordic decided to make a completely new SDK on RTOS only now.

There are a number of prerequisites for this:

  • A number of technologies are inherited from Linux:

    • work with streams, queues in real time (especially important for time-dependent protocols such as BLE)
    • libraries for networking and security
    • flexible hardware description model with energy optimization
    • libraries for working with peripherals (sensors, etc.)

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

To understand how dramatic changes have occurred, the structural diagram from the official documentation is well suited. Gray indicates the components that are part of Zephyr.

image

In practice, when implementing this approach, a number of cognitive problems arise. Developers accustomed to the product and solutions experience dissonance with a large number of changes.

Consider the version of development on Windows, as it will cause more questions regarding those who are used to developing on Linux.

The following packages are required:

  • Chocolatey (package manager)
  • Git (version control system)
  • Ninja (speed oriented build system)
  • CMake (high-level build system)
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

To someone who is faced with a similar set of utilities for the first time, it might seem that everything is unnecessarily complicated and the old paradigm could be used, that existing approaches to development are quite effective. However, if you look deeper, then everything becomes much more interesting.

For example, Chocolatey and pip allow you to install all the necessary packages through the console for OS and Python, respectively. And Python itself, like most of the software in question, is put in one command:

hoco install python xxx

It is also updated with one command:

choco upgrade all

The approach is a bit unusual for Windows users, for those who are familiar with console package managers in Linux (apt, zypper, etc.), nothing new. I have often noticed the situation that software developers for MK update software only when reinstalling the OS on a PC. About why it is bad we will not talk, I only note that here this problem is solved automatically.

The innovations in the field of configuration and assembly of projects are much more interesting.

Ninja was designed and positioned as a replacement for make and focused on build speed. It is especially good in applications when it is necessary to rebuild projects with a bunch of small files, where there were no changes. The effect can be an order of magnitude, or even two, see tests .

Cmakein turn, it allows generating configuration files for Ninja in a high-level (scripting) language for the platform on which the assembly will take place. About Cmake can be read on Habré, for example, here , here and here ,
GPerf generates a table of pointers, which saves memory, see step 3 of the assembly below.

We should also pay attention to a new approach to the description of iron. Devicetree appeared , describing the hardware structure of the device. This is a direct result of the support of Zephyr by the Linux Foundation.

The pluses are that the hardware description is now in a separate .dts file, which has a simple structure, it is easy to modify, and, as a result, port the code between different families of chips.
As an example, how much I can clearly illustrate the basic dtsi on nRF52840 , which in turn is used in the description of the nRF52840-DK nrf52840dk_nrf52840.dts
board. The number of motherboards supported by Zephyr is already over 200 .

As stated earlier, Nordic first released Zephyr on the nRF91 series, then on the nRF53, and now it has finally reached the most massive nRF52.

Switching to RTOS allows in turn to solve the problem of adapting code for new hardware. Even among the chips of one family, the transition required certain resources from the development side, if it was accompanied by a transition to another softdevice (the precompiled BLE library). Not to mention the transition, for example, from 51 or 91 series to 52, when the hardware platform itself changes significantly. Now this task will be solved much easier and faster.

Iron at Nordic is constantly being improved, but this must be written separately. In the framework of this article, we can only note that the focus is on integration with RTOS, safety, energy efficiency and improvement of the radio channel (BLE 5.2). Thank you can say the dual-core Cortex-M33, ARM Cryptocell and ARM TrustZone.

To build devicetree usedDevice Tree Compiler , which is part of MSYS2 (improved build system based on Cygwin and MinGW-64).

The second part of the project configuration is in KConfig (Kernel config), which was also inherited from Linux. It allows you to select the necessary blocks through a graphical interface and set parameters for assembly for a specific task, which is especially important in the conditions of limited resources of systems on a chip.

You can use traditional utilities like menuconfig, or within the framework of Segger Embedded Studio (the official recommended IDE) there is a built-in interface that can be launched through the corresponding menu item: Project> Configure nRF Connect SDK Project



An example project configuration with SSL / TLS based on nRF9160 is presented below. As you can see in it, you can configure both the hardware features of the project (platform, number of threads, plug-in kernel modules), and software (keys, addresses, etc.).





Consider the stages of the project assembly: There are five in total:

  • Configuration - preliminary processing of all configs (devicetree, KConfig), at the output we get header files describing the hardware and config for Ninja
  • Pre-assembly (I) - processing structures at a high level, compiling system files and offsets (offset), creating call tables
  • Initial assembly (II) - compilation of the main source codes and packing them into archives, linking
  • (III) — (GPerf),
  • - (IV) — hex, bin

You can read more about the Zephyr assembly system with pictures in the official documentation . There are quite a lot of text and pictures, so we will not consider the details in the framework of this article.
It is important to understand that the tools used here are not a substitute for the C preprocessor (cpp) and the C linker (ld). Both are used at all stages except post-processing. However, the result of their work is subject to additional improvements, which allow both to significantly reduce the assembly time and memory requirements.

You cannot directly compare the results of programs created on two SDKs. Since libraries and approaches are very different and there are no such tests yet. One can definitely say that the solution feels good on medium and top-end chips in the line (nRF52832 and higher), and there remains a large reserve of resources. However, it cannot be said that the new SDK is not applicable on younger chips like nRF52810. It is necessary to consider the problem in more detail.

Returning to the question in the title of the article, we can say that this paradigm is definitely a new reality. Which at first glance brings significant improvements. At least 2 new chip families from the largest BLE manufacturer in the world work precisely and only on this technology and no return is expected. In my opinion, this is a revolution that was prepared in advance.

Update : On May 14, Nordic held a webinar about the new SDK in which it announced that all versions of BLE older than 5.0 will be available only in the nRF Connect SDK. Accordingly, Directino Finding aka AoA / AoD (BLE 5.1) and LE Audio (BLE 5.2), which many are waiting for, will bring with them new tools this year and changes in development will come sooner than anticipated.

Findings:

  • The changes are radical, the code working with the current nRF5 SDK is not compatible with the new (nRF Connect SDK)
  • Switching to RTOS with Devicetree and KConfig allows you to get an additional level of abstraction for hardware, which in turn significantly speeds up the development and transfer of the project to a new platform
  • Switching to Zephyr brings support for a large number of protocols and libraries out of the box; for IoT devices, the most interesting are the network and security functions, where Linux is traditionally strong
  • Zephyr OS uses a number of tools during assembly, which can significantly reduce assembly time and memory requirements, which is especially important for embedded applications
  • The new SDK allows the use of higher-level developers, which are much more on the market than low-level ones. This solves the issue of personnel and increasing market share.

More articles:


All Articles