Partager via


Gérer l’heure système et le RTC dans les applications de haut niveau

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).

L’horloge RTC sert à conserver l’heure sur un appareil Azure Sphere qui subit une coupure d’alimentation et qui ne peut pas se connecter au réseau après son redémarrage. L’appareil peut ainsi conserver l’heure durant une coupure d’alimentation, même s’il n’est pas connecté à un serveur NTP.

Si vous définissez l’heure système, elle n’est pas conservée en cas de coupure d’alimentation de l’appareil. Pour rendre l’heure persistante durant une coupure d’alimentation, vous devez appeler la fonction Applibs clock_systohc. L’appel de clock_systohc envoie (push) l’heure système à l’horloge RTC.

Conditions requises relatives à l’horloge RTC

Les applications qui utilisent l’horloge RTC doivent inclure les fichiers d’en-tête appropriés et ajouter les paramètres d’horloge RTC dans le manifeste de l’application.

Fichiers d’en-tête

Incluez l’en-tête rtc dans votre projet :

 #include <applibs\rtc.h>

Paramètres de manifeste de l’application

Pour utiliser les API RTC et d’horloge standard, vous devez ajouter la fonctionnalité d’application SystemTime au manifeste de l’application, puis définir sa valeur sur true. Le manifeste d’application Azure Sphere contient plus de détails sur le manifeste de l’application.

{
  "SchemaVersion": 1,
  "Name" : "Mt3620App3_RTC",
  "ComponentId" : "bb267cbd-4d2a-4937-8dd8-3603f48cb8f6",
  "EntryPoint": "/bin/app",
  "CmdArgs": [],
   "Capabilities": {
    "AllowedConnections": [],
    "AllowedTcpServerPorts": [],
    "AllowedUdpServerPorts": [],
    "HardwareAddressConfig": true,
    "Gpio": [],
    "Uart": [],
    "WifiConfig": false,
    "NetworkConfig": false,
    "SystemTime": true,
    "TimeSyncConfig": true
  }
}

Obtenir l’heure système

Pour obtenir l’heure système, appelez la fonction clock_gettime standard.

Définir l’heure système

Pour définir l’heure système, appelez la fonction clock_settime standard.

Synchroniser l’heure système avec l’horloge RTC

Quand l’heure système est activée, elle n’est pas conservée en cas de coupure d’alimentation de l’appareil. Pour conserver le temps pendant la perte d’alimentation, appelez la fonction Applib clock_systohc . L’appel de clock_systohc envoie (push) l’heure système à l’horloge RTC.

Configurer le service client NTP

Le service client NTP est activé par défaut. Si vous définissez l’heure système alors que le service client NTP est activé, l’heure système remplace l’heure UTC quand l’appareil est connecté à Internet. Vous pouvez désactiver le service client NTP ; ceci peut cependant provoquer l’échec des mises à jour cloud sur l’appareil quand il y a une trop grande différence entre l’heure système et l’heure sur le serveur NTP.

Définir le fuseau horaire

L’heure système et l’heure RTC sont stockées en GMT/UTC. Vous pouvez changer le fuseau horaire utilisé par votre application en appelant la fonction setenv pour mettre à jour la variable d’environnement TZ, puis en appelant la fonction tzset.

Le projet SetTimeFromLocation montre comment utiliser la recherche IP inversée pour obtenir des informations d’emplacement, puis obtenir l’heure de l’emplacement et définir l’heure de l’appareil. Ce projet fait partie de la galerie Azure Sphere, une collection de scripts, utilitaires et fonctions non maintenus.

Le système d’exploitation Azure Sphere ne prend en charge que certains formats possibles pour la variable d’environnement TZ :

  • Vous pouvez définir le fuseau horaire actuel avec ou sans l’heure d’été. Exemples : « EST+5 », « EST+5 (heure d’été) ». Cette valeur est positive si le fuseau horaire local est à l’Ouest du premier méridien, et négative s’il est à l’Est.
  • Vous ne pouvez pas spécifier la date et l’heure à laquelle la DST doit entrer en vigueur.
  • Vous ne pouvez pas spécifier de fichier/de base de données de fuseau horaire.

Pour conserver les paramètres de fuseau horaire pendant une perte d’alimentation, vous pouvez utiliser un stockage mutable pour stocker le fuseau horaire dans un stockage persistant, puis rappeler le paramètre lors du redémarrage de l’appareil.

Spécification d’un serveur NTP

Le service client NTP peut être configuré pour obtenir du temps à partir de plusieurs sources. La source de temps par défaut est prod.time.sphere.azure.net, comme indiqué dans les exigences de mise en réseau du système d’exploitation Azure Sphere.

Le client NTP tente de synchroniser le temps toutes les 15 secondes jusqu’à ce qu’une synchronisation réussie ait eu lieu. Après avoir correctement synchronisé le temps, il tente de resynchroniser le temps une fois toutes les 24 heures. Quand Azure Sphere effectue la synchronisation du temps, il utilise d’abord un port source de client UDP aléatoire entre 32678-61000. Si ce port échoue, Azure Sphere tente ensuite d’utiliser le port 124 comme port source du client UDP.

Vous pouvez spécifier que le système obtient du temps à partir d’un serveur DHCP, ou vous pouvez spécifier la source de temps dans l’application via Networking_TimeSync_EnableCustomNTP ou Networking_TimeSync_EnableDefaultNTP.

S’il est configuré pour utiliser DHCP pour les sources de serveur de temps, Azure Sphere traite l’option DHCP 042 et le client NTP traite uniquement les deux premières entrées envoyées dans l’option DHCP, qui doivent être répertoriées dans l’ordre de préférence. Ceux-ci seront considérés comme un serveur principal et un serveur secondaire.

Vous pouvez également configurer un serveur de temps via Networking_TimeSync_EnableCustomNTP si vous souhaitez spécifier le serveur de temps principal et secondaire via l’application. La durée maximale pour chaque nom de domaine complet du serveur est de 255 caractères.

Sujet de base

  • Si le client NTP est configuré pour obtenir les serveurs de temps via DHCP ou l’API, un paramètre supplémentaire est nécessaire pour spécifier le comportement de secours.

  • Le client tente d’abord de contacter le serveur principal. Si le client ne parvient pas à obtenir une réponse de serveur de temps valide, il essaiera le serveur de temps secondaire (s’il est spécifié).

  • Si un serveur de temps secondaire est spécifié et qu’il échoue ou si l’option de revenir aux valeurs par défaut Networking_NtpOption_FallbackServerEnabled du système d’exploitation par défaut échoue, le système contacte ensuite la source de temps du système d’exploitation par défaut prod.time.sphere.azure.net.

    • Dans l’intervalle de synchronisation de 24 heures suivant, le système d’exploitation revient et tente d’interroger le serveur de temps principal.
  • Si vous avez spécifié Networking_NtpOption_FallbackServerDisabled, le système d’exploitation continue d’interroger le serveur principal et secondaire toutes les 15 secondes jusqu’à ce qu’il soit correctement synchronisé avec l’un des serveurs de temps.

Appareils multihomed

Les paramètres du serveur de temps sont un paramètre global, et non un paramètre par interface. Si l’appareil Azure Sphere est multihomed et que les deux interfaces obtiennent des informations sur le serveur NTP via DHCP, le jeu d’options NTP dhcp le plus récemment traité gagne.

Exemple d’heure système

L’exemple System Time montre comment gérer l’heure système et utiliser le matériel RTC. L’exemple d’application définit l’heure système, puis utilise la clock_systohc fonction pour synchroniser l’heure système avec le RTC.

Le projet SetTimeFromLocation montre comment utiliser la recherche IP inversée pour obtenir des informations d’emplacement, puis obtenir l’heure de l’emplacement et définir l’heure de l’appareil. Ce projet fait partie de la galerie Azure Sphere, une collection de scripts, utilitaires et fonctions non maintenus.

Exemple NTP personnalisé

L’exemple NTP personnalisé montre comment configurer le service client NTP pour obtenir du temps à partir de plusieurs sources.