Get best of the week

什么是适用于Nordic的新nRF Connect SDK？进化，革命还是另类？

上周，Nordic Semiconductor 向 nRF Connect SDK 添加了 nRF52系列支持。



大多数人的主要问题是它是什么，为什么它很重要？对于拥有nRF5 SDK经验的人来说，这个问题尤为重要，其中有很多。

我马上注意到，该文章主要是为那些在Cortex-M级或封闭式设备开发中使用传统方法的人撰写的。因此，从高水平工作的人员（看一下Linux方面正在发生的事情）的角度来看，某些定义和类比可能看起来并不完全正确，但是对于那些刚开始使用这种方法的人来说，它更容易理解。

总是欢迎提出评论和澄清。

关于谁是北欧人以及他们现在的状况如何
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 .

这里出现了一个主要问题，为什么要发布新的SDK，它与当前的SDK有何不同？如果是这样，那么使用当前解决方案就可以了。

当前的nRF5 SDK在一个简单的队列基础上工作，并且在大多数情况下，这足以执行几乎所有任务（尽管某些公司仍在使用自己的SDK，但这是规则的例外）。新的nRF Connect SDK使用基于Zephyr RTOS的根本不同的方法。更详细地考虑差异。
RTOS（RTOS）具有某些优点和已知的缺点。后者包括：

  • 维护操作系统的额外开销
  • 简单项目的开发非常复杂
  • 构建复杂性增加

其余的RTOS是：

  • 由于对单个流程的控制，提高了可靠性

在北欧框架内，自从引入具有LTE Cat-M / NB-IoT / GPS的新包装（SIP）的新系统（nRF91系列）以来，这已变得有趣而有意义。由于新的Cortex-M33内核以及网络组件的其他要求（由于从BLE到蜂窝网络的过渡），该SIP具有更高的性能。这里的另一项创新是SDR调制解调器，该调制解调器工作在单独的内核上，必须与之组织核间交互作用。第一次在此出现了基于RTOS的SDK，对于那些首先遇到新方法的人，从准备阶段开始就提出了许多问题。还发布了一个特殊的助手，用于正确组装开发环境- 入门助手。他告诉您需要安装哪些组件（其中有很多，请参见下文），并检查是否正确安装了所有组件。

图片

从这个角度来看，我们可以将向Zephyr的过渡与第一个大规模ARM Cortex-M的外观以及向32位的过渡进行比较。现在，大多数人使用32位MK作为主要对象，有关此文的文章则刊登在Habré上。它还说明了过渡，这种过渡最初看起来不必要地复杂。但是随着时间的流逝，几乎每个人都得出结论，这已成为标准。

值得注意的是，Zephyr OS不是唯一在北欧芯片上运行的RTOS。FreeRTOS的项目示例从2016年开始在SDK v.11中可用，甚至在SDK v.9中更早的版本中，对nRF51系列（2015）都有Keil RTX支持。但是，早期这些是更多的实验功能，RTOS制造商在更大程度上提供了支持。从原则上讲，现在是正确的。

对nRF5x系列的非官方Zephyr支持出现在2016年。

Zephyr Nordic决定仅在RTOS上制作一个全新的SDK。

有许多先决条件：

  • Linux继承了许多技术：

    • 实时处理流，队列（对于与时间相关的协议（例如BLE）尤其重要）
    • 网络和安全性库
    • 具有能源优化功能的灵活硬件描述模型
    • 用于外围设备（传感器等）的库

  • :




    • , Nordic,

  • ( )
  • ( ) . , , .

要了解变化是如何发生的，官方文档中的结构图非常适合。灰色表示Zephyr的组成部分。

图片

实际上，在实施这种方法时，会出现许多认知问题。习惯产品和解决方案的开发人员会因大量更改而感到不协调。

考虑一下Windows上的开发版本，因为它会引起与那些习惯于Linux上开发的人有关的更多问题。

需要以下软件包：

  • Chocolatey（包装经理）
  • Git（版本控制系统）
  • 忍者（面向速度的构建系统）
  • CMake（高级构建系统）
  • DTC-MSYS2 ( (device tree))
  • GPerf ( )
  • west ( )
  • pip ( Python)
  • Python3
  • GNU Arm Embedded Toolchain (GCC, GDB ARM)

对于第一次面对相似的实用程序集的人来说，似乎所有事情都不必要地复杂了，可以使用旧的范例，现有的开发方法相当有效。但是，如果您看得更深，那么一切都会变得更加有趣。

例如，Chocolatey和pip允许您分别通过OS和Python控制台安装所有必需的软件包。像大多数相关软件一样，Python本身也放在一个命令中：

hoco install python xxx

它也用一个命令更新：

choco upgrade all

对于Windows用户而言，对于熟悉Linux中的控制台软件包管理器（apt，zypper等）的用户而言，这种方法有点不寻常。我经常注意到这样的情况：仅当在PC上重新安装OS时，MK的软件开发人员才会更新软件。关于它为什么不好的问题，我们不再讨论，我只在这里指出此问题已自动解决。

项目配置和组装领域的创新更加有趣。

Ninja的设计和定位是替代make并专注于构建速度。当需要使用一堆没有更改的小文件重建项目时，在应用程序中尤其有用。效果可以是一个数量级，甚至两个数量级，请参见测试。

麦克马反过来，它允许以高级（脚本）语言为将在其上进行组装的平台生成Ninja的配置文件。关于Cmake的信息可以在Habré上阅读，例如，在此处，此处和此处，
GPerf会生成一个指针表，以节省内存，请参见下面程序集的第3步。

我们还应注意描述铁的新方法。Devicetree出现了，描述了设备的硬件结构。这是Linux基金会对Zephyr支持的直接结果。

优点在于，硬件描述现在位于单独的.dts文件中，该文件具有简单的结构，它很容易修改，因此可以在不同系列的芯片之间移植代码。
作为一个例子，据我所知，我将在nRF52840上给出基本的dtsi，然后在nRF52840-DK nrf52840dk_nrf52840.dts
板的描述中使用Zephyr支持的主板数量已经超过200个。

如前所述，Nordic首先在nRF91系列上发布Zephyr，然后在nRF53上发布，现在终于达到了最大的nRF52。

切换到RTOS可以依次解决为新硬件适配代码的问题。即使是在一个系列的芯片之间，如果要伴随着向另一软设备（预编译的BLE库）的过渡，则过渡也需要开发方面的某些资源。更不用说从51或91系列到52的过渡，此时硬件平台本身发生了巨大变化。现在，将轻松，快速地解决此任务。

北欧的Iron不断得到改进，但这必须单独编写。在本文的框架中，我们只能指出，重点是与RTOS集成，安全性，能源效率和无线电信道（BLE 5.2）的改进。谢谢你能说的双核Cortex-M33，ARM Cryptocell和ARM的TrustZone。

要构建的DeviceTree使用设备树编译器，它是MSYS2（基于Cygwin和MinGW-64的改进的构建系统）的一部分。

项目配置的第二部分在KConfig（内核配置）中，它也从Linux继承。它允许您通过图形界面选择必要的块并设置用于特定任务的装配参数，这在片上系统资源有限的情况下尤其重要。

您可以使用传统的实用程序（例如menuconfig），也可以在Segger Embedded Studio（官方推荐的IDE）的框架内，通过相应的菜单项启动内置的界面：项目>配置nRF Connect SDK项目



下面介绍了基于nRF9160的SSL / TLS的示例项目配置。如您所见，您可以配置项目的硬件功能（平台，线程数，插件内核模块）和软件（键，地址等）。





考虑项目组装的各个阶段：共有五个：

  • 配置 -所有配置（devicetree，KConfig）的初步处理，在输出处，我们获得描述Ninja硬件和配置的头文件
  • 预组装（I） -高层处理结构，编译系统文件和偏移量（偏移量），创建调用表
  • 初始汇编（II） -编译主要源代码并将其打包到档案中，链接
  • (III) — (GPerf),
  • - (IV) — hex, bin

您可以在官方文档中阅读有关带图片的Zephyr组装系统的更多信息。文本和图片很多，因此我们不会在本文的框架中考虑细节。
重要的是要了解，此处使用的工具不能替代C预处理程序（cpp）和C链接程序（ld）。两者都用于除后期处理之外的所有阶段。但是，他们的工作成果还有待进一步改进，这可以大大减少组装时间和内存需求。

您不能直接比较在两个SDK上创建的程序的结果。由于库和方法非常不同，因此尚无此类测试。可以肯定地说，该解决方案在生产线中的中高端芯片（nRF52832及更高版本）上感觉很好，并且仍然有大量的资源储备。但是，不能说新的SDK不适用于nRF52810等较年轻的芯片。有必要更详细地考虑该问题。

回到文章标题的问题，我们可以说这种范例肯定是一个新现实。乍看之下带来了重大改进。来自世界上最大的BLE制造商的至少2个新芯片系列可以精确地工作，并且仅使用此技术，并且不会带来任何回报。我认为，这是一场事先准备的革命。

更新：5月14日，Nordic举行了有关新SDK的网络研讨会，在该研讨会中，Nordic 宣布所有低于5.0的BLE版本仅在nRF Connect SDK中可用。因此，许多人都在等待的Directino Finding aka AoA / AoD（BLE 5.1）和LE Audio（BLE 5.2）今年将带来新工具，并且开发变更的速度将比预期的更快。

发现：

  • 所做的更改非常重大，与当前nRF5 SDK兼容的代码与新版（nRF Connect SDK）不兼容
  • 使用Devicetree和KConfig切换到RTOS可以使您获得更高的硬件抽象级别，从而大大加快了项目的开发和向新平台的转移
  • 切换到Zephyr即可提供对大量协议和库的支持；对于IoT设备，最有趣的是网络和安全功能，而Linux在传统上是强大的
  • Zephyr OS在组装过程中使用了许多工具，可以大大减少组装时间和内存需求，这对于嵌入式应用程序尤为重要
  • 新的SDK允许使用高级开发人员，这些开发人员在市场上比低级开发人员更多。这解决了人员问题并增加了市场份额。

More articles:


All Articles