LoRa STM32WB55
1.0.0
Vider
État du projet:
L'idée principale est de pouvoir utiliser le bouclier Semtech Lora SX1272MB2DAS sur une carte nucléo STM32WB55. Malheureusement, le code disponible par ST (i-cube-lrwan) pour ce bouclier n'est disponible que pour quelques cartes nucléo (L053RG, L073RZ, L152RE et L476RG).
Les idées dérivées sont d'épouser Lora et BLE, de nos jours, de nombreux objets IoT sont accessibles pour diverses raisons (paramètres, Provisoning, Fuota, ...) mais surtout parce qu'il est compatible avec les smartphones. La STM32WL Serie n'a pas de BLE et la Serie STM32WB n'a pas de capacités LORA.
Eh bien, j'ai eu l'occasion de créer une paire avec SX1272 et WB55 et permettre une combinaison de deux puces pour le projet IoT flexible. Gardez à l'esprit que la Serie WB55 ne se limite pas à BLE. Le firmware de coprocesseur peut gérer les protocoles latéraux de 2,4 GHz comme Zigbee et OpenThread. Ainsi, la combinaison de communications RF à longue portée et à courte portée est intéressante.
Ce projet n'est qu'un port de codes et de bibliothèques existants, mais peut économiser du temps d'installation pour certains développeurs car il y a des problèmes techniques à résoudre.
Avec la prochaine LORA 2,4 GHz, cela doit être considéré comme un travail de transition. Le SX1280 combinera la communication courte et à longue portée dans une seule puce. Vous voudrez peut-être regarder de plus près.
C'est facile à trouver. Le bouclier SEMTECH SX1272MB2XAS LORA MBED est le bouclier compatible Arduino et les cartes de nucléo ont le connecteur correspondant. Mémoire technique:
Comme mentionné, la Serie STM32WB55 est la cible ici et le P-Nucleo-WB55RG est une belle planche avec laquelle jouer. Mémoire technique:
Une fois connecté (c'est une évidence), voici l'objet résultant. 
N'oubliez jamais de brancher l'antenne avant d'alimenter les planches. Vous pouvez endommager la sortie de l'amplificateur RF (bien que ce soit une puissance assez faible). Bien sûr, l'achat de deux de chacun est un peu nécessaire pour Ping Pong.
| Emballer | Version |
|---|---|
| STM32Cubeide | 1.7 |
| Stm32cubemx | 6.3.0 |
| Fw_wb | 1.12.1 |
| I-cube-lrwan | 2.0 |
La majeure partie du code est couverte par ST et SEMTECH SUblicensing. Consultez les accords respectifs pour une utilisation appropriée:
| Composant | Droit d'auteur | Licence |
|---|---|---|
| Source d'application d'origine | Stmicroelectronic | Contrat de licence ST SLA0044 |
| Piles Lorawan® | Semtech | BSD révisé sous licence pour les pièces Semtech |
| CMSIS Cortex®-M | ARM LTD | Licence BSD-3-Clause ou Apache 2 |
Mon environnement de développement préféré est Linux, mais les outils ST sont également disponibles pour Mac et Windows. Les deux premiers sont plus faciles à configurer, généralement aucun problème ni problème de conducteur. Eh bien, la vraie technologie de la technologie le savait déjà.
Bien que je ne sois pas un grand fan d'ides, STM32Cudeide fonctionne OK et les plugins ST aidés (MX, téléchargement d'extensions logicielles, ...). STMICRO fournit un package d'extension logiciel pour certains boucliers LORA. Comme lié ci-dessus, c'est le i-cube-lrwan et contient des exemples de projets et de bibliothèques comme les pilotes SX1272 de bas niveau (via le SPI) et la pile Lorawan (1.0.3 compatible).
Le projet peut facilement être ouvert dans STM32Cudeide sans dépendances. Tout le code n'a pas besoin d'installer WB ou Lorawan Firmare à partir de st. Ouvrez le projet et construisez-le (testé sur Linux et MacOS). Cependant, vous avez besoin du firmware BLE Stack installé pour CPU2. Ici, STM32WB5X_BLE_STACK_FULL_FW.BIN a été flashé. Tous les firmwares de piles sont fournis dans Projects / STM32WB_COPRO_WIRESS_BINARES / STM32WB5X du package de firmware STM32Cubewb ainsi que sur la façon de programmer les planches pour cela. Cela doit être fait une fois .
L'ensemble de l'expérience avait besoin d'outils supplémentaires. J'ai utilisé le puissant dongle USB NRF52840 avec NRF Connect pour le bureau 3.7.0 (disponible sur Linux, Mac et Windows) à partir de semi-conducteur nordique pour tester la connexion. Je sais que les smartphones peuvent le faire, j'utilise LightBlue sur iOS ou Android, mais lorsque vous gâchez des uuids ou des noms d'appareils, les plates-formes ont tendance à se perdre avec leurs données mises en cache, donc j'aime comprendre ce qui se passe avec des outils de développement comme Nordic Ones.
Pour la partie Lorawan, TTN est tout simplement génial et j'ai choisi d'acheter une passerelle Lorawan bon marché, un TTIG (moins cher que les chapeaux RAK pour Raspberry Pi) pour les tests locaux. La passerelle est codée en dur aux services TTN, mais il doit y avoir un moyen de se connecter à votre propre LNS.
Ce fut la toute première étape. Faire fonctionner les choses et j'ai choisi l'exemple de transmission RF de faible niveau pour cela. Le portage du code ST / SEMTECH était une question de gérer la reconfiguration du WB55 à:
Mappage des broches entre la carte Nucleo WB55 et le bouclier SX1272MB2DAS:
| SX1272MB2DAS | P-nucléo-stm32wb55 | Nom de la broche du connecteur Arduino |
|---|---|---|
| Dio0 | PC6 | D2 |
| Dio1 | PA10 | D3 |
| Dio2 | PC10 | D4 |
| Dio3 | PA15 | D5 |
| NSS | PA4 | D10 |
| SCLK | PA5 | D13 |
| Miso | PA6 | D12 |
| Mosi | PA7 | D11 |
| RÉINITIALISER | PC0 | A0 |
Donc, rien incompatible à première vue. Les matchs de punage SPI1, les broches NSS et RESET sont également OK. Mais voici le premier Hickup avec les lignes IRQ. PC6 utilise la ligne EXTI6 IRQ (EXTI9_5_IRQN), c'est bien, mais PA10, PC10 et PA15 partagent la même ligne EXTI IRQ, c'est-à-dire EXTI15_10_IRQN.
La définition de l'interface radio a donc été modifiée pour correspondre à la carte Nucleo-WB55 (SX1272MB2DAS_CONF.H). Et les gestionnaires IRQ ont été modifiés pour vérifier les états GPIO (DIOX) avant d'appeler les gestionnaires SX1272 IRQ correspondants (consultez STM32WBXX_IT.C Fichier source)
RTC a une source d'horloge définie sur LSE.
La disposition du fichier du projet d'origine a également été légèrement modifiée. L'intégration des fichiers d'origine a été réalisée sur un projet généré par MX (SX1272.IOC) pour préserver la possibilité de modifier le projet. Cependant, certains prudents doivent être considérés comme un code contradictoire peut-être généré.
La programmation de deux cartes avec ce code fonctionne, et comme prévu, la première carte qui reçoit une réponse pong à un message de ping devient maître, l'autre devient esclave . J'ai fait en sorte que le statut LED reflète cela (comme autrefois prévu dans le code d'origine). L'un est en rouge clignotant où l'autre a la LED verte clignotant après un court laps de temps: vidéo.
Le code BLE est entièrement généré par MX. En avoir un qui fonctionne tout de suite n'était pas simple car beaucoup de choses doivent être correctement définies dans le projet MX (qui pourrait un article séparé). J'ai configuré un projet de test BLE séparément à cet effet, une fois qu'il a fonctionné, j'ai fusionné le code dans le projet LORA pour faire fonctionner les deux côte à côte.
Ainsi, le logiciel de test BLE n'est qu'un code périphérique HRS (capteur de fréquence cardiaque). Il est basé sur un cadre de minuterie complètement différent qui est appelé serveur de minuterie matériel (HW_TS). La bibliothèque Semtech Lora n'est pas basée sur celle-ci mais sur un utilitaire STM32_TIMER, elle-même basée sur le pilote HAL RTC. J'ai supprimé la bibliothèque utilitaire et l'adaptateur RTC afin que l'ensemble du projet repose uniquement sur HW_TS. La bibliothèque LORA s'appuie en fait sur une API intermédiaire (Timer.H) qui était facile à réécrire, donc HW_TS est utilisé à la place. L'application Ping-Pong, en revanche, repose sur l'ancienne bibliothèque des services publics. Quelques modifications apportées à cette partie ont fait que l'ensemble du code reposait uniquement sur HW_TS.
J'ai besoin de fusionner les taskidés définis par l'application Ping Pong et le code BLE. Heureusement, les deux utilisent l'utilitaire STM32_Séquencer . Une fois bien terminé, j'ai réussi à faire l'application Lora Ping Pong et à une application HRS BLE fonctionnant simultanément et parfaitement sur la carte STM32WB55.
J'ai modifié le code app_ble.c afin que le nom annoncé (visible) soit basé sur STM32 UDN afin que nous puissions distinguer les planches exécutées en même temps.
Pour une démo utile, j'ai écrit un service GATT dédié afin que les deux conseils puissent être interrogés via BLE afin que vous puissiez savoir quel rôle le nœud LORA a (maître ou esclave) et le nombre de ping / pong envoyé / reçue. Pour cela, j'ai légèrement adapté le code BLE, donc Blue LED reflète l'état de connexion BLE. Le service personnalisé (non généré par MX, il est trop désordonné), a deux caractéristiques, une pour connaître le rôle du nœud (maître ou esclave après la synchronisation de Pingpong) et un autre qui est un compteur des cadres de ping reçus (nœud esclave) ou des cadres pong (nœud maître). Voici la capture d'écran de NRF Connect connecté aux deux cartes synchronisées: 
Cela fait, j'ai préféré passer un peu plus de temps sur une application LORA légèrement différente contrôlée par BLE, qui est la prochaine étape.
La pile Lorawan est celle de Semtech fournie dans le package d'extension I-Cube-Lrwan. Il est conforme de 1.0.3 et comprend un progiciel de certification si la certification LORA Alliance est nécessaire pour l'appareil final.
Encore une fois, le code repose sur un emballage RTC différent de celui de la pile BLE, il a donc été modifié pour cela. Le nombre de minuteries a été augmenté car le paramètre initial HW Timerserver est trop limité pour exécuter les deux piles simultanément (le fichier HW_IF.H a modifié après IOC modifié).
L'exemple d'origine, Lorawan End Node, envoie un ensemble de données très complet, j'ai radicalement réduit le cadre de test à un texte simple.
L'appareil est défini pour rejoindre le réseau à l'aide d'OTAA, donc 3 éléments sont nécessaires: Deveui, Joineui et Appkey. Deveui est un identifiant unique pour un périphérique matériel et est construit à partir de "numéro de série" STM32. L'identifiant joineui (ou ancien APPEUI) est utilisé pour la séparation des applications côté serveur. L'Appkey est très important (une clé AES128) que les MUT soient gardés très secrètement. Le code source arbitraire le définit sur une valeur qui doit être modifiée pour une utilisation finale. Le secret est réalisé par Code Semtech à l'aide d'une API d'élément sécurisé, dans notre cas, c'est un SE virtuel, mais cela est très pratique si vous en utilisez un réel.
Joineui et AppKey sont codés en dur dans le fichier se-identity.h ( Lorawan_App_key et Lorawan_NWK_KEY doivent être les mêmes valeurs pour OTAA, ce dernier est utilisé pour calculer le micro et est nécessaire pour que le joinquest soit valide sur LNS).
Les tests avec TTN et TTIG Gateway les donnent:
Pour la partie déclarative.
Une fois que les deux conseils ont eu une réponse positive de leur JoinRequest respective.
Un service de GATT spécial a été écrit pour exposer:
| Attribut | Accéder | Commentaire |
|---|---|---|
| Statut | Lire | Que la jointure a terminée ou non |
| Deveui | Lire | Lecture de Deveui calculé |
| Joineui | Lire | Lecture de joineui / Appeui codé en dur |
| Données | Écrire | Données qui seront envoyées (16 octets max.). Par défaut "STM32WB55 ici!" |
| Période | Écrire | Période en secondes auxquelles les données sont envoyées (par défaut à 10 secondes) |
| RSSI | Lire | Mise à jour lorsque le message de liaison descendants est reçu |
| Snr | Lire | Mise à jour lorsque le message de liaison descendants est reçu |
Remarque: Ne jouez pas avec la période, il y a une limitation du cycle de service de 1%. Avec les paramètres par défaut, le module envoie 15 octets toutes les 10 secondes. À SF7BW125, cela peut être fait à la période la plus basse de ~ 7 secondes.
Ici, une illustration des caractéristiques exposées lorsqu'elle lui est connectée:
à suivre
