Partage via

Obtention de la sortie de débogage d’appareil Azure Sphere

  • Article

Lorsque vous développez une solution IoT, vous devez souvent avoir accès à la sortie de débogage à partir d’appareils. Bien que cela puisse être réalisé via une connexion de débogage à Visual Studio/Code (mais également à partir de la ligne de commande), vous devrez peut-être également afficher la sortie de débogage pour les appareils qui ne sont pas connectés à Visual Studio/Code. Ces appareils peuvent exécuter des tests à long terme, voire être déployés en production. Il existe plusieurs options pour obtenir l’accès aux données de débogage :

  • Obtention de la sortie de débogage à partir d’un appareil connecté à un PC de développement
  • Obtention d’une sortie de débogage pour un appareil non connecté à un PC de développement
  • Journalisation dans le stockage externe
  • Journalisation dans Azure

Obtention de la sortie de débogage à partir d’un appareil connecté à un PC de développement

Problème: Comment obtenir une sortie de débogage lors du débogage à l’aide de Visual Studio/Visual Code ?

Options:

  • Application de haut niveau

    Une application de haut niveau Azure Sphere peut utiliser l’API Log_Debug pour envoyer une sortie de débogage avec une mise en forme de style printf à un PC attaché pendant le débogage. Cette sortie peut être affichée à l’aide de la fenêtre de débogage de Visual Studio ou Visual Studio Code , ou à partir de la ligne de commande.

    Vous pouvez envisager de configurer des indicateurs de détail de débogage dans votre application et d’utiliser des définitions de compilation CMake pour contrôler la quantité de sortie de débogage affichée lors de l’exécution de votre application. Dans votre fichier CMakeLists.txt, vous pouvez créer une définition de l’heure de compilation :

    add_compile_definitions(DEBUG_FLAG)

    Dans votre code d’application de haut niveau, vous pouvez ensuite augmenter ou diminuer la quantité de sortie de débogage affichée par votre application à l’aide #ifdefde , par exemple :

    #ifdef DEBUG_FLAG
        Log_Debug("My Message\n");
    #endif

  • Application prenant en compte le temps réel

    Une application Azure Sphere prenant en charge le temps réel (s’exécutant sur l’un des cœurs M4) peut écrire des informations de débogage/journal dans un UART M4 dédié à transmission uniquement. Cela nécessite un adaptateur USB/série tel qu’un ami FTDI et un émulateur de terminal.

    L’exemple de Hello World Azure Sphere montre comment imprimer sur l’UART de débogage M4.

    Il existe également des exemples d’applications disponibles à partir de CodeThink et MediaTek :

    Les définitions de temps de compilation de l’indicateur de débogage peuvent également être utilisées dans des applications M4 en temps réel.

  • Utilisation des communications intercœurs pour envoyer l’état d’une application prenant en charge le temps réel à une application de haut niveau

    Si vous créez un système qui combine une application de haut niveau et compatible en temps réel, vous pouvez utiliser l’application de haut niveau pour journaliser l’état du système pour les deux applications. Les communications intercœurs peuvent être utilisées pour cela : l’exemple de communication intercœur Azure Sphere implémente une interface simple pour transmettre un message entre une application de haut niveau et compatible en temps réel.

    Ce module d’apprentissage Azure Sphere montre comment utiliser Azure Sphere et Azure RTOS, combinés à un modèle de messagerie intercœur pour passer des messages personnalisés entre les cœurs.

Obtention d’une sortie de débogage pour un appareil non connecté à un PC de développement

Problème: Comment journaliser la sortie de débogage lorsque votre appareil n’est pas connecté à un PC de développement ?

Options:

  • Envoyer la sortie de débogage sur le réseau ou un UART

    L’obtention des informations de journal de débogage lorsqu’un appareil est connecté à un PC de développement est assez simple. Toutefois, vous pouvez également collecter des informations de débogage/journal lorsqu’un appareil n’est pas connecté à un PC. Par exemple, vous pouvez avoir un ensemble d’appareils exécutant des tests à long terme.

    Si vos appareils sont connectés à un réseau, vous souhaiterez peut-être envoyer la sortie de débogage sur le réseau à une application qui peut collecter et analyser les informations. Cette application de la galerie Azure Sphere montre comment remplacer le comportement de Log_Debug par défaut pour envoyer et recevoir cette sortie sur un socket UDP.

    Notez que le mécanisme utilisé pour remplacer le comportement d’Log_Debug d’application à haut niveau par défaut peut également être utilisé pour envoyer les informations du journal de débogage à d’autres emplacements, par exemple, pour générer les données sur l’un des UART Azure Sphere. Vous pouvez utiliser cet exemple UART comme référence à combiner avec l’application UDPDebugLog Gallery pour enregistrer vos messages dans un UART.

  • Envoyer la sortie de débogage à Azure IoT Hub/Azure IoT Central

    Bien que le débogage de la sortie puisse être utile pour diagnostiquer les problèmes au fur et à mesure qu’ils se produisent, il peut également être utile de stocker des informations de télémétrie/journal à partir d’un appareil pour le post-traitement.

    La configuration d’un instance de Azure IoT Hub ou d’Azure IoT Central vous donne un point de terminaison pour envoyer des données de télémétrie d’appareil qui peuvent être utilisées dans le cadre de votre logique métier. Vous pouvez également envoyer des informations d’état/journal de l’appareil qui peuvent être traitées séparément des données de télémétrie/métier.

    • Azure IoT Hub

      Votre Azure IoT Hub instance peut être configuré pour envoyer des données à une base de données Azure à des fins de stockage/analyse. Vous pouvez également filtrer les messages, ce qui peut être obtenu via EventHub et une fonction Azure.

      Par Azure IoT Hub vous pouvez envoyer des données à une fonction Azure qui peut ensuite traiter les messages. Le déclencheur Azure IoT Hub pour Azure Functions article explique comment lier une fonction Azure à un Azure IoT Hub instance.

    • Azure IoT Central

      Azure IoT Central offre la possibilité d’exporter continuellement vos données vers différents points de terminaison, notamment :

      • Azure Event Hubs
      • File d’attente Azure Service Bus
      • Azure Service Bus rubrique
      • Stockage Blob Azure
      • Webhook

      Le WebHook est un point de terminaison d’API REST que vous créez. Il peut s’agir d’une fonction Azure.

    Notez que vous souhaiterez peut-être filtrer les messages dans votre fonction Azure en fonction de l’ID d’appareil qui envoie les données. Vous pouvez obtenir l’ID d’appareil à l’aide du code suivant dans la fonction Azure :

    public static async Task Run(EventData message, ILogger log)
    {
        var deviceId=message.SystemProperties["iothub-connection-device-id"];

        // Code to filter the messages goes here...
    }

Azure IoT Hub et Azure IoT Central prennent en charge Les jumeaux d’appareil, qui incluent l’état souhaité (défini dans l’application IoT Hub/Central) et l’état signalé (état de l’appareil). Vous pouvez utiliser Azure IoT Hub/jumeau d’appareil central pour définir l’état souhaité pour le détail des données de journalisation (augmenter/diminuer la fréquence de journalisation ou la richesse des données de journalisation). L’exemple Azure IoT montre comment gérer les modifications de jumeau Desired State d’appareil.

Journalisation des données dans le stockage

Azure Sphere prend en charge jusqu’à 64 Ko de stockage mutable pour une application de haut niveau. Cela peut être utilisé pour conserver les paramètres, l’état de l’application ou d’autres données. Les développeurs d’applications sont responsables de la sérialisation/désérialisation des données vers un stockage mutable . La galerie Azure Sphere inclut un projet qui montre comment utiliser une paire clé/valeur (dictionnaire) pour écrire/lire l’état dans le stockage mutable (jusqu’à 64 Ko selon la configuration du manifeste de l’application).

Vous pouvez écrire plus de 64 Ko de données de journal/d’état dans une forme de stockage externe. Cela peut être utile pour les appareils qui ont une connectivité intermittente ou qui doivent stocker/récupérer plus de 64 Ko de données.

L’une des options consiste à ajouter un stockage externe, peut-être en utilisant spi flash pour stocker les données. Ce projet utilise spi flash pour stocker une mise à jour ota pour un appareil en aval, et peut être modifié pour prendre en charge la journalisation des données de télémétrie/d’état à partir d’une application Azure Sphere.