Partager via


Initialisation et arrêt

Au démarrage, chaque application Azure Sphere doit effectuer une initialisation :

  • Inscrire un gestionnaire SIGTERM pour les demandes d’arrêt. Le système d’exploitation de l’appareil Azure Sphere envoie le signal d’arrêt SIGTERM pour indiquer que cette application doit se fermer, le plus souvent 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êt, l’application peut effectuer les tâches d’arrêt dont elle a besoin. Les gestionnaires d’arrêt doivent être POSIX async-signal-safe. En particulier, ils ne doivent pas contenir d’appels à Log_Debug(). Les exemples de programmes se terminent en cas d’erreur ainsi qu’à la réception du signal d’arrêt. Par conséquent, ces programmes définissent simplement une valeur booléenne dans le gestionnaire d’arrêt, puis effectuent des tâches de nettoyage et d’arrêt après avoir quitté la boucle main.

  • Initialisez les handles 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 telles que les messages cloud-à-appareil, les status de jumeaux d’appareil et les appels de méthode directe.

À l’arrêt, l’application doit fermer les périphériques, détruire les handles et libérer la mémoire allouée. L’application ne dispose que de deux secondes pour se fermer à la réception du signal SIGTERM; si l’application ne s’est pas arrêtée, 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.