Initialisation et arrêt

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

Au démarrage, chaque application Azure Sphere doit procéder à une initialisation :

• Inscrire un gestionnaire SIGTERM pour les demandes d’arrêt. Le système d’exploitation d’appareil Azure Sphere envoie le signal d’arrêt SIGTERM pour indiquer que l’application doit quitter, le plus fréquemment lorsqu’une mise à jour est en attente, mais également en réponse à une demande de mise hors tension de l’appareil. Dans le cadre de son code d’initialisation, l’application doit inscrire un gestionnaire pour ces demandes. Par exemple :

    #include <signal.h>
    ...
    // Register a SIGTERM handler for termination requests
    struct sigaction action;
    memset(&action, 0, sizeof(struct sigaction));
    action.sa_handler = TerminationHandler;
    sigaction(SIGTERM, &action, NULL);
  

  Dans le gestionnaire d’arrêts, l’application peut effectuer toutes les tâches d’arrêt nécessaires. Les gestionnaires d’arrêts doivent gérer correctement les signaux asynchrones POSIX. En particulier, ils ne doivent pas contenir d’appels à Log_Debug(). Les exemples de programmes se ferment en cas d’erreur, ainsi qu’à la réception du signal d’arrêt. Pour cela, ces programmes définissent simplement un booléen dans le gestionnaire d’arrêts, puis effectuent les tâches de nettoyage et d’arrêt après avoir quitté la boucle principale.

• Initialiser les descripteurs pour les périphériques GPIO.

• Si l’application utilise Azure IoT Hub, connectez-vous au client IoT et inscrivez des fonctions de rappel pour les fonctionnalités IoT comme les messages cloud-à-appareil, l’état du jumeau d’appareil et les appels de méthode directs.

Lors d’un arrêt, l’application doit fermer les périphériques, détruire les descripteurs et libérer la mémoire allouée. L’application ne dispose que de deux secondes pour quitter le signal SIGTERM ; si l’application n’a pas quitté le système d’exploitation Azure Sphere envoie un signal SIGKILL qui met immédiatement fin à l’application. Le signal SIGKILL doit toujours être évité. Si l’application effectue régulièrement des actions qui peuvent prendre plus de deux secondes, envisagez d’ajouter une boucle de mise à jour différée à l’application. Les applications qui utilisent la fonctionnalité Powerdown doivent effectuer tout nettoyage nécessaire avant d’appeler les API de mise hors tension.