🔄 🧑 👩🏽‍🔧 Qu'est-ce que le nouveau SDK nRF Connect pour les pays nordiques? Évolution, révolution ou alternative? 🔣 🐸 🏭

La semaine dernière, Nordic Semiconductor a ajouté la prise en charge de la série nRF52 au SDK nRF Connect.

La principale question que se posent la plupart des gens est de savoir de quoi il s'agit et pourquoi est-ce important? Cette question est particulièrement pertinente pour ceux qui ont une expérience avec le SDK nRF5, et ils sont nombreux.

Je note tout de suite que l'article est principalement écrit pour ceux qui utilisent des approches traditionnelles dans le développement d'appareils de niveau Cortex-M ou proches. Par conséquent, certaines définitions et analogies peuvent ne pas sembler complètement correctes du point de vue de ceux qui travaillent à un niveau élevé (regarde ce qui se passe du côté de Linux), mais ce sera plus facile à comprendre pour ceux qui commencent juste de cette façon.

Les commentaires et clarifications sont toujours les bienvenus.

Un peu sur qui est le nordique et comment il se porte bien maintenant

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 .

Ici, la question principale se pose, pourquoi le nouveau SDK a-t-il été publié et en quoi diffère-t-il de l'actuel? Si c'est le cas, tout va bien avec la solution actuelle.

Le SDK nRF5 actuel fonctionne sur la base d'une simple file d'attente, et dans la plupart des cas, cela suffit pour implémenter presque toutes les tâches (bien que certaines entreprises utilisent toujours leurs propres SDK, mais ce sont des exceptions aux règles). Le nouveau SDK nRF Connect utilise une approche radicalement différente basée sur Zephyr RTOS. Considérez les différences plus en détail.
Les RTOS (RTOS) comportent à la fois certains avantages et inconvénients connus. Ces derniers comprennent:

frais généraux supplémentaires pour la maintenance du système d'exploitation
grande complexité de développement sur des projets simples
complexité de construction accrue

Les autres RTOS sont:

fiabilité accrue grâce au contrôle des flux individuels

Au sein des pays nordiques, cela est devenu intéressant et pertinent depuis l'introduction du nouveau système en boîtier (SIP) avec LTE Cat-M / NB-IoT / GPS - la série nRF91. Ce SIP a des performances plus élevées en raison du nouveau cœur Cortex-M33 et d'autres exigences pour le composant réseau, qui sont apparues en raison de la transition du BLE aux réseaux cellulaires. Une autre innovation ici était le modem SDR, qui fonctionne sur un noyau séparé et avec lequel il était nécessaire d'organiser une interaction internucléaire. Pour la première fois, le SDK basé sur RTOS est apparu ici, et pour ceux qui ont rencontré pour la première fois une nouvelle approche, il a soulevé un certain nombre de questions, à partir de la phase de préparation. Un assistant spécial a également été libéré pour l'assemblage correct de l'environnement de développement - Assistant de démarrage. Il vous indique les composants que vous devez installer (il y en a beaucoup, voir ci-dessous) et vérifie que tout est correctement installé.

De ce point de vue, on peut comparer la transition vers Zephyr avec l'apparition de la première masse ARM Cortex-M et la transition vers 32 bits. Maintenant, la majorité utilise des MK 32 bits comme principaux, sur lesquels il y a un article sur Habré. Il raconte également la transition, qui semblait initialement inutilement compliquée. Mais au fil du temps, presque tout le monde est venu à la conclusion que cela est devenu la norme.

Il convient de noter que Zephyr OS n'est pas le seul RTOS fonctionnant sur des puces nordiques. Exemples de projets avec FreeRTOSDisponible dans le SDK v.11 à partir de 2016, et même plus tôt dans le SDK v.9, la famille nRF51 était prise en charge par Keil RTX (2015). Cependant, auparavant, ces fonctions étaient plus expérimentales et le support a été fourni dans une plus large mesure par les fabricants de RTOS. Ce qui, en principe, est vrai maintenant.

Le soutien non officiel de Zephyr aux familles nRF5x est apparu en 2016 .

Zephyr Nordic a décidé de créer un SDK complètement nouveau sur RTOS seulement maintenant.

Il y a un certain nombre de conditions préalables à cela:

Un certain nombre de technologies sont héritées de Linux:
- travailler avec des flux, des files d'attente en temps réel (particulièrement important pour les protocoles dépendants du temps tels que BLE)
- bibliothèques pour la mise en réseau et la sécurité
- modèle de description de matériel flexible avec optimisation énergétique
- bibliothèques pour travailler avec des périphériques (capteurs, etc.)
:
- , Nordic,
( )
( ) . , , .

Pour comprendre comment des changements spectaculaires se sont produits, le diagramme structurel de la documentation officielle est bien adapté. Le gris indique les composants qui font partie de Zephyr.

En pratique, lors de la mise en œuvre de cette approche, un certain nombre de problèmes cognitifs se posent. Les développeurs habitués au produit et aux solutions connaissent une dissonance avec un grand nombre de changements.

Considérez la version de développement sous Windows, car cela posera plus de questions concernant ceux qui ont l'habitude de développer sous Linux.

Les packages suivants sont requis:

Chocolatey (gestionnaire de paquets)
Git (système de contrôle de version)
Ninja (système de construction orienté vitesse)
CMake (système de construction de haut niveau)
DTC-MSYS2 ( (device tree))
GPerf ( )
west ( )
pip ( Python)
Python3
GNU Arm Embedded Toolchain (GCC, GDB ARM)

Pour quelqu'un qui est confronté pour la première fois à un ensemble similaire d'utilitaires, il peut sembler que tout est inutilement compliqué et que l'ancien paradigme pourrait être utilisé, que les approches de développement existantes sont assez efficaces. Cependant, si vous regardez plus profondément, alors tout devient beaucoup plus intéressant.

Par exemple, Chocolatey et pip vous permettent d'installer tous les packages nécessaires via la console pour OS et Python, respectivement. Et Python lui-même, comme la plupart des logiciels en question, est placé dans une seule commande:

hoco install python xxx

Il est également mis à jour avec une seule commande:

choco upgrade all

L'approche est un peu inhabituelle pour les utilisateurs de Windows, pour ceux qui connaissent les gestionnaires de packages de console sous Linux (apt, zypper, etc.), rien de nouveau. J'ai souvent remarqué que les développeurs de logiciels pour MK ne mettent à jour le logiciel que lors de la réinstallation du système d'exploitation sur un PC. A propos de pourquoi c'est mauvais, nous ne parlerons pas, je note seulement qu'ici ce problème est résolu automatiquement.

Les innovations dans le domaine de la configuration et du montage de projets sont beaucoup plus intéressantes.

Ninja a été conçu et positionné en remplacement de la marque et axé sur la vitesse de construction. C'est particulièrement bon dans les applications où il est nécessaire de reconstruire des projets avec un tas de petits fichiers, où il n'y a pas eu de changements. L'effet peut être un ordre de grandeur, voire deux, voir tests .

Cmakeà son tour, il permet de générer des fichiers de configuration pour Ninja dans un langage de haut niveau (script) pour la plate-forme sur laquelle l'assemblage aura lieu. A propos de Cmake peut être lu sur Habré, par exemple, ici , ici et ici ,
GPerf génère une table de pointeurs, ce qui économise de la mémoire, voir l'étape 3 de l'assemblage ci-dessous.

Nous devons également prêter attention à une nouvelle approche de la description du fer. Devicetree est apparu , décrivant la structure matérielle de l'appareil. Ceci est le résultat direct du soutien de Zephyr par la Linux Foundation.

Les avantages sont que la description du matériel est maintenant dans un fichier .dts distinct, qui a une structure simple, il est facile à modifier et, par conséquent, à porter le code entre différentes familles de puces.
Par exemple, je peux illustrer clairement le dtsi de base sur nRF52840 , qui à son tour est utilisé dans la description de la carte nRF52840-DK nrf52840dk_nrf52840.dts
. Le nombre de cartes mères prises en charge par Zephyr est déjà supérieur à 200 .

Comme indiqué précédemment, Nordic a d'abord publié Zephyr sur la série nRF91, puis sur le nRF53, et maintenant il a finalement atteint le nRF52 le plus massif.

Le passage à RTOS permet à son tour de résoudre le problème de l'adaptation du code au nouveau matériel. Même parmi les puces d'une même famille, la transition nécessitait certaines ressources du côté du développement, si elle s'accompagnait d'une transition vers un autre logiciel (la bibliothèque BLE précompilée). Sans parler de la transition, par exemple, de la série 51 ou 91 à 52, lorsque la plate-forme matérielle elle-même change considérablement. Maintenant, cette tâche sera résolue beaucoup plus facilement et plus rapidement.

Le fer chez Nordic est constamment amélioré, mais cela doit être écrit séparément. Dans le cadre de cet article, nous pouvons seulement noter que l'accent est mis sur l'intégration avec RTOS, la sécurité, l'efficacité énergétique et l'amélioration du canal radio (BLE 5.2). Merci de dire le dual-core Cortex-M33, ARM Cryptocell et ARM TrustZone.

Pour construire devicetree utiliséDevice Tree Compiler , qui fait partie de MSYS2 (système de construction amélioré basé sur Cygwin et MinGW-64).

La deuxième partie de la configuration du projet se trouve dans KConfig (configuration du noyau), également hérité de Linux. Il vous permet de sélectionner les blocs nécessaires via une interface graphique et de définir des paramètres d'assemblage pour une tâche spécifique, ce qui est particulièrement important dans les conditions de ressources limitées des systèmes sur une puce.

Vous pouvez utiliser des utilitaires traditionnels comme menuconfig, ou dans le cadre de Segger Embedded Studio (l'IDE officiel recommandé) il y a une interface intégrée qui peut être lancée via l'élément de menu correspondant: Projet> Configurer nRF Connect SDK Project

Un exemple de configuration de projet avec SSL / TLS basé sur nRF9160 est présenté ci-dessous. Comme vous pouvez le voir, vous pouvez configurer à la fois les fonctionnalités matérielles du projet (plate-forme, nombre de threads, modules de noyau de plug-in) et les logiciels (clés, adresses, etc.).

Considérez les étapes de l'assemblage du projet: Il y en a cinq au total:

Configuration - traitement préliminaire de toutes les configurations (devicetree, KConfig), à la sortie, nous obtenons des fichiers d'en-tête décrivant le matériel et la configuration pour Ninja
Pré-assemblage (I) - traitement des structures à un niveau élevé, compilation des fichiers système et des décalages (décalage), création de tables d'appel
Assemblage initial (II) - compilation des principaux codes source et leur conditionnement dans des archives, liaison
(III) — (GPerf),
- (IV) — hex, bin

Vous pouvez en savoir plus sur le système d'assemblage Zephyr avec des photos dans la documentation officielle . Il y a beaucoup de texte et d'images, nous ne considérerons donc pas les détails dans le cadre de cet article.
Il est important de comprendre que les outils utilisés ici ne remplacent pas le préprocesseur C (cpp) et l'éditeur de liens C (ld). Les deux sont utilisés à toutes les étapes, sauf le post-traitement. Cependant, le résultat de leur travail est soumis à des améliorations supplémentaires, qui permettent à la fois de réduire considérablement le temps d'assemblage et les besoins en mémoire.

Vous ne pouvez pas comparer directement les résultats des programmes créés sur deux SDK. Étant donné que les bibliothèques et les approches sont très différentes et qu'il n'y a pas encore de tels tests. On peut certainement dire que la solution se sent bien sur les puces moyennes et haut de gamme de la gamme (nRF52832 et plus), et qu'il reste une grande réserve de ressources. Cependant, on ne peut pas dire que le nouveau SDK ne s'applique pas aux puces plus jeunes comme le nRF52810. Il est nécessaire d'examiner le problème plus en détail.

Revenant à la question posée dans le titre de l'article, on peut dire que ce paradigme est définitivement une nouvelle réalité. Ce qui à première vue apporte des améliorations significatives. Au moins 2 nouvelles familles de puces du plus grand fabricant de BLE au monde fonctionnent précisément et uniquement sur cette technologie et aucun retour n'est attendu. À mon avis, c'est une révolution qui a été préparée à l'avance.

Mise à jour : Le 14 mai, Nordic a organisé un webinaire sur le nouveau SDK dans lequel il a annoncé que toutes les versions de BLE antérieures à 5.0 ne seront disponibles que dans le SDK nRF Connect. En conséquence, Directino Finding aka AoA / AoD (BLE 5.1) et LE Audio (BLE 5.2), que beaucoup attendent, apporteront avec eux de nouveaux outils cette année et les changements de développement arriveront plus tôt que prévu.

Résultats:

Les changements sont radicaux, le code fonctionnant avec le SDK nRF5 actuel n'est pas compatible avec le nouveau (SDK nRF Connect)
Le passage à RTOS avec Devicetree et KConfig vous permet d'obtenir un niveau d'abstraction supplémentaire pour le matériel, ce qui accélère considérablement le développement et le transfert du projet vers une nouvelle plate-forme
Le passage à Zephyr permet de prendre en charge un grand nombre de protocoles et de bibliothèques prêts à l'emploi; pour les appareils IoT, les plus intéressants sont les fonctions réseau et de sécurité, où Linux est traditionnellement fort
Zephyr OS utilise un certain nombre d'outils lors de l'assemblage, ce qui peut réduire considérablement le temps d'assemblage et les besoins en mémoire, ce qui est particulièrement important pour les applications intégrées
Le nouveau SDK permet d'utiliser des développeurs de niveau supérieur, qui sont beaucoup plus sur le marché que ceux de bas niveau. Cela résout le problème du personnel et de l'augmentation des parts de marché.

Qu'est-ce que le nouveau SDK nRF Connect pour les pays nordiques? Évolution, révolution ou alternative?

More articles: