Prototyper rapidement des applications IoT Bluetooth avec un kit de développement et des cartes d'extension prêtes à l'emploi

Par Stephen Evanczuk

Avec la contribution de Rédacteurs nord-américains de Digi-Key

La demande en matière de produits connectés intelligents offre de vastes possibilités aux développeurs capables de transformer rapidement des concepts en applications Internet des objets (IoT) opérationnelles. La disponibilité de processeurs à haut rendement énergétique, d'options de connectivité sans fil et d'un large éventail de périphériques matériels offre une base solide pour la mise en œuvre de conceptions basse consommation, prêtes pour la production.

Cependant, au stade initial de la définition du produit, les développeurs ont besoin d'une plateforme de développement flexible pour créer des prototypes rapides basés sur la même catégorie de processeurs, de sous-systèmes de connectivité et de périphériques. La capacité à construire rapidement des prototypes fonctionnels et à ajouter facilement des fonctionnalités est essentielle pour fournir les premières démonstrations de faisabilité et pour soutenir le développement de logiciels personnalisés.

Cet article montre comment les développeurs peuvent utiliser le matériel et les logiciels de Silicon Labs pour développer rapidement des prototypes de dispositifs IoT connectés et écoénergétiques spécialisés en utilisant une vaste sélection de cartes d'extension prêtes à l'emploi.

Permettre le prototypage rapide

Lorsqu'ils explorent de nouvelles possibilités pour les dispositifs IoT sans fil alimentés par batterie, les développeurs peuvent se retrouver submergés par les nombreux détails liés à la création d'une plateforme de développement fonctionnelle. Grâce à leurs sous-systèmes intégrés, les systèmes sur puce (SoC) avancés peuvent constituer le cœur d'une telle plateforme, mais les développeurs doivent encore construire un système complet autour d'eux.

Pour construire une plateforme de développement adaptée à ces dispositifs, les développeurs doivent non seulement répondre aux exigences fondamentales en matière de performances robustes et d'autonomie batterie étendue, mais également intégrer la flexibilité nécessaire pour répondre aux besoins spécifiques de chaque application. Le kit d'exploration BGM220-EK4314A de Silicon Labs répond à cette combinaison d'exigences, permettant aux développeurs de se concentrer sur le prototypage rapide de nouveaux concepts plutôt que de s'occuper des détails impliqués dans la construction de leur propre plateforme de développement.

Plateforme de développement rapide et flexible

Offrant une plateforme à faible coût pour le développement d'applications basées sur Bluetooth, le kit d'exploration BGM220-EK4314A combine le module Gecko sans fil BGM220P (BGM220PC22HNA) de SiLabs, un débogueur SEGGER J-Link embarqué, un bouton-poussoir, une diode électroluminescente (LED) et de multiples options d'extension (Figure 1).

Image du kit d'exploration BGM220-EK4314A de SiLabsFigure 1 : Le kit d'exploration BGM220-EK4314A de SiLabs offre la combinaison requise de performances de traitement, de gestion de l'énergie et de flexibilité de configuration pour construire rapidement des prototypes et évaluer différentes configurations matérielles de périphériques. (Source de l'image : Silicon Labs)

Le module BGM220P sert de solution complète pour les petits dispositifs IoT alimentés par batterie. Son SoC Blue Gecko EFR32BG22 intégré présente une consommation d'énergie ultrafaible, des capacités Bluetooth pour l'angle d'arrivée (AoA) et l'angle de départ (AoD), et une précision de localisation inférieure à un mètre — autant de caractéristiques nécessaires à un nombre croissant d'applications Bluetooth populaires, notamment les étiquettes de suivi des actifs, les serrures intelligentes, les dispositifs de fitness, et plus.

Capable de fonctionner en tant que système autonome, le module BGM220P combine le SoC EFR32BG22 avec 512 kilo-octets (Ko) de mémoire Flash, 32 Ko de RAM et des quartz (XTAL) haute fréquence (HF) et basse fréquence (LF), et un réseau d'adaptation de 2,4 gigahertz (GHz) et une antenne céramique pour la connectivité sans fil (Figure 2).

Schéma du module BGM220P de SiLabsFigure 2 : Capable de fonctionner en tant que système autonome, le module BGM220P de SiLabs combine le SoC Blue Gecko EFR32BG22 avec des composants supplémentaires requis pour l'implémentation d'un dispositif Bluetooth. (Source de l'image : Silicon Labs)

Outre sa capacité à servir d'hôte autonome pour les conceptions IoT compactes, le module peut également servir de coprocesseur réseau (NCP) pour un processeur hôte connecté via l'interface UART du module. Sa pile Bluetooth intégrée exécute les services sans fil pour les applications fonctionnant sur le module dans les conceptions autonomes, ou traite les commandes reçues de l'hôte dans les conceptions NCP.

SoC sans fil écoénergétique

Le SoC sans fil Bluetooth EFR32BG22 du module BGM220P intègre un cœur Arm Cortex-M33 32 bits, une radio 2,4 GHz, des sous-systèmes de sécurité et de gestion de l'énergie, ainsi que plusieurs temporisateurs et options d'interface. Conçu spécifiquement pour les conceptions ultrabasse consommation alimentées par batterie, le SoC EFR32BG22 utilise de multiples fonctions de gestion de l'énergie qui permettent à une pile bouton de fonctionner pendant 10 ans.

Fonctionnant à partir d'une seule source de tension externe, le SoC utilise son unité de gestion de l'énergie interne pour générer des tensions d'alimentation internes. Pendant le fonctionnement, l'unité de gestion de l'énergie contrôle les transitions entre les cinq modes d'énergie (EM) du SoC. Chaque mode réduit davantage la consommation d'énergie en maintenant progressivement moins de blocs fonctionnels actifs à mesure que le SoC passe du mode actif (EM0) au mode veille (EM1), au mode de veille profonde (EM2), au mode d'arrêt (EM3) ou au mode de mise hors tension (EM4) (Figure 3).

Schéma du SoC EFR32BG22 de Silicon Labs (cliquez pour agrandir)Figure 3 : L'unité de gestion de l'énergie du SoC EFR32BG22 contrôle les transitions entre les modes EM0, EM1, EM2, EM3 et EM4 (code couleur en bas de l'image). (Source de l'image : Silicon Labs)

En mode actif (EM0) à 76,8 MHz et 3 volts (V), en utilisant son convertisseur CC/CC interne, le SoC consomme 27 microampères par mégahertz (μA/MHz). EM0 est le mode de fonctionnement normal et le seul où le cœur du processeur Cortex-M33 et tous les blocs périphériques sont disponibles.

Tous les périphériques sont disponibles en mode veille (EM1), le nombre de périphériques restant actifs diminuant lorsque le système passe en modes à plus basse consommation. Dans les modes à plus basse consommation, la réduction des horloges et des blocs fonctionnels actifs permet de réduire considérablement les niveaux de consommation d'énergie :

  • 17 μA/MHz en mode veille (EM1)
  • 1,40 μA en mode de veille profonde (EM2) avec rétention RAM de 32 Ko et horloge temps réel (RTC) s'exécutant à partir du LFXO
  • 1,05 μA en mode d'arrêt (EM3) avec rétention RAM de 8 Ko et RTC s'exécutant à partir de l'oscillateur résistance-capacité (RC) ultrabasse fréquence (ULFRCO) de 1 kilohertz (kHz) intégré du SoC
  • 0,17 μA en mode de mise hors tension (EM4)

Certains dispositifs alimentés par batterie requièrent plus que la capacité à utiliser le processeur en modes de fonctionnement basse consommation. De nombreuses applications Bluetooth présentent généralement des périodes prolongées d'activité faible ou nulle, mais nécessitent une réactivité à faible latence lorsque l'activité reprend. En fait, même si une application a des exigences de latence plus tolérantes, un temps d'activation lent gaspille de l'énergie car le processeur n'effectue aucun travail utile pendant qu'il termine le processus d'activation et passe en mode actif (ou termine le processus de passage d'un mode à plus haute consommation à un mode basse consommation).

À mesure que la durée entre les périodes actives se réduit, l'utilisation d'un mode veille basse consommation peut même devenir contre-productive lorsqu'un temps d'activation ou d'entrée lent en mode d'alimentation consomme plus d'énergie que si le processeur restait dans un mode à plus haute consommation durant la période d'inactivité. Par conséquent, les développeurs qui s'efforcent d'optimiser la durée de vie de la batterie maintiennent parfois un processeur dans un mode à plus haute consommation que ce que les besoins de traitement de l'application exigent.

En utilisant un processeur avec des temps d'activation et d'entrée plus rapides, les développeurs peuvent tirer un meilleur parti des modes basse consommation du processeur. En mode EM1, l'EFG32BG22 a un temps d'activation en trois horloges/1,24 microsecondes (µs) et a un temps d'entrée de 1,29 µs, s'élevant à 8,81 millisecondes (ms) et 9,96 µs, respectivement, en mode EM4 (Tableau 1).

Mode d'énergie Activation (exécution depuis RAM/Flash) Entrée (exécution depuis Flash)
EM1 3 horloges / 1,24 μs 1,29 μs
EM2 5,15 / 13,22 μs 5,23 μs
EM3 5,15 / 13,21 μs 5,23 μs
EM4 8,81 ms (Flash uniquement) 9,96 μs

Tableau 1 : Temps d'activation et temps d'entrée en mode d'alimentation pour le SoC EFG32BG22. (Source du tableau : Silicon Labs)

La méthode utilisée pour activer le processeur lorsque l'activité reprend peut également avoir un impact significatif sur l'autonomie de la batterie. Bien que certaines applications, comme les applications industrielles, exigent que les systèmes utilisent un traitement par interrogation pour garantir une synchronisation périodique stricte, de nombreuses applications grand public utilisent un traitement basé sur les événements pour répondre à une activité spécifique. L'utilisation de méthodes d'interrogation pour les applications basées sur des événements, par exemple, peut réduire considérablement l'autonomie de la batterie lorsque le processeur s'active inutilement de manière répétée.

De la même manière que de nombreuses conceptions basées sur des capteurs utilisent la fonctionnalité d'activation sur interruption pour éviter d'activer le processeur de manière répétée uniquement pour vérifier l'activité, une fonctionnalité d'activation sur RF intégrée au sous-système radio du SoC EFG32BG22 permet une approche similaire basée sur les interruptions. Cela permet aux développeurs de maintenir le processeur dans un mode basse consommation jusqu'à ce qu'une activité radiofréquence (RF) se produise.

Dans la pratique, les développeurs placent le SoC sans fil EFG32BG22 dans un mode EM2, EM3 ou EM4 ultrabasse consommation et comptent sur la fonction d'activation sur RF pour activer le SoC lorsqu'une énergie RF est détectée. Lorsqu'elle détecte simplement une énergie supérieure au seuil, la capacité RFSENSE consomme 131 nanoampères (nA). Un mode RFSENSE plus sélectif consomme un peu plus de courant à 138 nA, mais dans ce mode, RFSENSE filtre les signaux RF entrants pour éviter l'activation sur du bruit RF plutôt que sur un signal RF valide.

Dans certains cas, le SoC EFG32BG22 peut ne pas avoir besoin d'activer le cœur du processeur pour répondre à des événements externes : le système PRS (Peripheral Reflex System) de SiLabs permet aux périphériques de répondre aux événements et de fonctionner sans activer le cœur du processeur. Les périphériques peuvent communiquer directement entre eux, et leurs fonctions peuvent être combinées pour fournir des fonctionnalités complexes. En utilisant les capacités PRS avec les modes basse consommation, les développeurs peuvent réduire considérablement la consommation d'énergie sans compromettre les fonctionnalités stratégiques telles que l'acquisition de données de capteurs.

Débogage intégré et expansion aisée

Intégré à la carte du kit d'exploration BGM220, le module BGM220P apporte l'ensemble des capacités de traitement et de gestion de l'énergie du SoC EFR32BG22 aux conceptions Bluetooth alimentées par batterie. Lorsqu'il est nécessaire de construire rapidement des prototypes pour explorer de nouveaux concepts, d'autres caractéristiques de la carte permettent d'accélérer le développement.

Accessible via le connecteur USB Micro-B de la carte, un débogueur J-Link de SEGGER intégré permet le téléchargement et le débogage du code, et offre un port COM virtuel pour l'accès à la console hôte Le débogueur prend également en charge la fonction PTI (Packet Trace Interface) de SiLabs pour l'analyse des paquets transmis ou reçus sur un réseau sans fil.

Pour le prototypage rapide, la prise en charge par la carte de multiples options d'extension offre la flexibilité requise pour explorer de nouvelles idées de conception nécessitant différentes combinaisons de capteurs, d'actionneurs, d'options de connectivité et d'autres périphériques. En s'appuyant sur la grande variété de cartes d'extension mikroBUS et de matériel de connexion Qwiic disponibles auprès de divers fournisseurs, les développeurs peuvent rapidement configurer une plateforme de développement pour chaque application.

Branchée à la prise mikroBUS de la carte, une carte mikroBUS se connecte au module BGM220P via une interface I2C, SPI ou UART. Le connecteur Qwiic fournit l'interface I2C du système Qwiic pour connecter une ou plusieurs cartes Qwiic sur des distances s'étendant jusqu'à environ 1,2 mètre (m). Pour les connexions sur de plus longues distances, les développeurs peuvent se tourner vers la carte QwiicBus EndPoint de SparkFun (COM-16988), qui utilise la signalisation différentielle pour maintenir l'intégrité des signaux I2C sur des distances allant jusqu'à environ 30 mètres.

Développement rapide d'applications

SiLabs applique le concept d'expansion rapide au développement de logiciels d'application. Outre les packs de support de carte, les pilotes, les bibliothèques et les en-têtes pour le développement personnalisé, la société propose plusieurs applications d'exemple regroupées dans l'environnement de développement Simplicity Studio, ainsi que des projets supplémentaires disponibles dans les référentiels GitHub de SiLabs. En fait, les développeurs peuvent commencer à explorer le développement d'applications de capteurs avec un exemple d'application de température fourni qui utilise le capteur de température interne du SoC EFR32BG22 comme source de données.

Reposant sur le service Bluetooth Health Temperature standard, l'application de température offre une démonstration prête à l'emploi du flux de traitement via une application IoT Bluetooth générique architecturée sur l'architecture logicielle de SiLabs. L'application appelle une série de routines d'initialisation pour les services système et les services d'application configurant des gestionnaires d'interruptions et des rappels. Une fois l'initialisation terminée, l'application entre dans une boucle infinie pour attendre les événements (Liste 1).

Copier
int main(void)
{
  // Initialize Silicon Labs device, system, service(s) and protocol stack(s).
  // Note that if the kernel is present, processing task(s) will be created by
  // this call.
  sl_system_init();



  // Initialize the application. For example, create periodic timer(s) or
  // task(s) if the kernel is present.
  app_init();



#if defined(SL_CATALOG_KERNEL_PRESENT)
  // Start the kernel. Task(s) created in app_init() will start running.
  sl_system_kernel_start();
#else // SL_CATALOG_KERNEL_PRESENT
  while (1) {
    // Do not remove this call: Silicon Labs components process action routine
    // must be called from the super loop.
    sl_system_process_action();



    // Application process.
    app_process_action();



#if defined(SL_CATALOG_POWER_MANAGER_PRESENT)
    // Let the CPU go to sleep if the system allows it.
    sl_power_manager_sleep();
#endif
  }
#endif // SL_CATALOG_KERNEL_PRESENT
}
Liste 1 : Les applications d'exemple Bluetooth de SiLabs utilisent une structure d'exécution générique dans laquelle une boucle infinie permet aux gestionnaires d'événements et aux rappels de traiter les actions du système et de l'application après l'initialisation. (Source du code : Silicon Labs)

Dans cette application, lorsqu'un temporisateur défini durant l'initialisation effectue un décompte, une routine de rappel associée effectue une mesure de température. Après avoir créé l'application et flashé la carte, les développeurs peuvent utiliser l'application EFR Connect de SiLabs — une application mobile Bluetooth générique qui fonctionne avec tous les kits et dispositifs Bluetooth de Silicon Labs. En plus de fournir une structure pour les applications personnalisées, l'application facilite le développement en fournissant une vue des caractéristiques prises en charge associées à un service Bluetooth tel que le service Bluetooth Health Thermometer utilisé dans cette application d'exemple (Figure 4).

Image de l'application EFR Connect de SiLabsFigure 4 : L'application EFR Connect de SiLabs affiche les caractéristiques des services Bluetooth utilisés dans une application, ce qui permet non seulement d'accélérer le développement de prototypes mais également de fournir une structure pour le développement d'applications personnalisées. (Source de l'image : Silicon Labs)

Dans Simplicity Studio, les développeurs peuvent importer un certain nombre d'exemples d'applications Bluetooth qui démontrent divers scénarios d'utilisation, y compris des conceptions créées avec des cartes Qwiic ou mikroBUS, séparément ou conjointement, comme une application d'exemple qui démontre l'utilisation des services standard Bluetooth Heart Rate (HR) et Bluetooth Pulse Oximeter (SpO2) en combinaison avec la carte mikroBUS Heart Rate 2 Click MIKROE-4037 de MikroElektronika, contenant le biocapteur MAX86161 de Maxim Integrated. Le MAX86161 offre un sous-système basse consommation complet capable de fournir des mesures de fréquence cardiaque et SpO2 précises à un processeur hôte connecté via son interface I2C. (Pour en savoir plus sur l'utilisation du MAX86161, consultez l'article Concevoir un véritable dispositif auditif de fitness – 1re partie : mesure de la fréquence cardiaque et SpO2).

Avec son besoin d'un pilote supplémentaire et d'un algorithme de traitement plus exigeant que dans l'application de température, cette application fournit une démonstration plus complexe d'une architecture d'application logicielle de dispositif IoT (Figure 5).

Schéma de l'application HR/SpO2Figure 5 : Des projets d'exemple tels que l'application HR/SpO2 permettent d'accélérer le développement de prototypes tout en démontrant un flux de processus typique pour les applications de capteurs Bluetooth basse consommation. (Source de l'image : Silicon Labs)

Comme pour l'application de température mentionnée ci-dessus, cette application s'appuie sur une série de routines d'initialisation pour configurer le système et les services d'application. Alors que la routine app_process_action est vide dans l'application de température, cette application ajoute un appel à une routine, hrm_loop, dans app_process_action. Cela se traduit par un appel à hrm_loop à chaque passage dans la boucle infinie de niveau supérieur présentée plus haut dans la Liste 1. En outre, un temporisateur logiciel est utilisé pour mettre à jour périodiquement les données HR et SpO2.

La routine hrm_loop appelle à son tour maxm86161_hrm_process, qui extrait des échantillons d'une file d'attente maintenue par des fonctions auxiliaires et les transmet à une routine de processus d'échantillonnage. Cela, à son tour, appelle une paire de routines, maxm86161_hrm_frame_process et maxm86161_hrm_spo2_frame_process, qui exécutent des algorithmes pour valider et générer les résultats HR et SpO2, respectivement. Les développeurs peuvent consulter les résultats ainsi que d'autres caractéristiques des services à l'aide de l'application EFR Connect mentionnée précédemment.

Une autre application logicielle d'exemple montre comment les développeurs peuvent se baser sur une application complexe telle que cette application HR/SpO2 lorsqu'ils étendent leur plateforme matérielle. En utilisant la carte du kit d'exploration BGM220-EK4314A et l'écosystème logiciel de SiLabs, le développement à partir de matériel et de logiciels existants est relativement simple. SiLabs démontre cette approche avec une application d'exemple qui ajoute un écran OLED à la plateforme matérielle/logicielle utilisée pour l'application HR/SpO2 ci-dessus. Dans cet exemple, une carte d'extension Qwiic d'écran OLED de SparkFun (LCD-14532) est reliée au connecteur Qwiic de la carte, tandis que la carte d'extension Heart Rate 2 Click de MikroElektronika reste inchangée par rapport à l'application d'exemple HR/SpO2 précédente (Figure 6).

Image de la carte du kit d'exploration BGM220-EK4314A de Silicon Labs avec un écran OLEDFigure 6 : Les développeurs peuvent rapidement ajouter des fonctionnalités à une conception existante développée sur la carte du kit d'exploration BGM220-EK4314A — en ajoutant ici un écran OLED à un prototype HR/SpO2 existant. (Source de l'image : Silicon Labs)

Hormis l'ajout d'un pilote et de services de support pour la carte OLED, l'application logicielle reste largement inchangée pour cette version étendue de l'application HR/SpO2. Le temporisateur logiciel mentionné précédemment pour l'application HR/SpO2 ajoute un appel à la fonction hrm_update_display, qui affiche les données HR et SpO2 (Liste 2).

Copier
    /* Software Timer event */
    case sl_bt_evt_system_soft_timer_id:
      /* Check which software timer handle is in question */
      if (evt->data.evt_system_soft_timer.handle == HEART_RATE_TIMER) {
        heart_rate_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == PULSE_OXIMETER_TIMER) {
        pulse_oximeter_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == DISPLAY_TIMER) {
        hrm_update_display();
        break;
      }
      break;
Liste 2 : Grâce au kit et à l'écosystème logiciel, les développeurs peuvent ajouter une fonctionnalité d'affichage à une application HR/SpO2 existante en connectant une carte d'écran et en apportant des modifications logicielles minimales, et en ajoutant un appel de fonction, hrm_update_display, au gestionnaire de temporisateur logiciel de l'application existante. (Source du code : Silicon Labs)

Cette approche matérielle et logicielle extensible permet aux développeurs de créer rapidement des applications IoT fonctionnelles. Comme le matériel et les logiciels peuvent être facilement ajoutés ou retirés, les développeurs peuvent plus facilement explorer de nouvelles solutions de conception et évaluer des configurations alternatives.

Conclusion

Les dispositifs IoT Bluetooth alimentés par batterie sont au cœur des applications populaires et sont essentiels pour répondre à la demande constante en matière de fonctionnalités accrues et de durée de vie plus longue. Pour les développeurs, répondre efficacement à ces exigences contradictoires exige la capacité d'explorer rapidement de nouvelles conceptions et d'évaluer des concepts alternatifs. Grâce à un kit de développement et aux logiciels associés de Silicon Labs, les développeurs peuvent rapidement construire des prototypes, en ajoutant et en retirant du matériel selon les besoins pour répondre aux exigences d'une application spécifique.

Avertissement : les opinions, convictions et points de vue exprimés par les divers auteurs et/ou participants au forum sur ce site Web ne reflètent pas nécessairement ceux de Digi-Key Electronics ni les politiques officielles de la société.

À propos de l'auteur

Stephen Evanczuk

Stephen Evanczuk affiche plus de 20 ans d'expérience dans la rédaction de contenu pour et sur l'industrie électronique, couvrant un large éventail de sujets, notamment le matériel, les logiciels, les systèmes et les applications, y compris l'IoT. Il a obtenu son doctorat (Ph.D.) en neurosciences sur les réseaux neuronaux et a travaillé dans l'industrie aérospatiale sur les systèmes sécurisés massivement distribués et les méthodes d'accélération par algorithmes. Actuellement, lorsqu'il n'écrit pas d'articles techniques, il travaille sur l'application de l'apprentissage approfondi pour les systèmes de reconnaissance et de recommandation.

À propos de l'éditeur

Rédacteurs nord-américains de Digi-Key