Gérer le temps système et le RTC dans les applications de haut niveau

L’horloge en temps réel (RTC) est utilisée pour conserver l’heure sur un appareil Azure Sphere lorsque l’appareil perd de l’alimentation et n’a pas accès à une connexion réseau après le redémarrage de l’appareil. Cela permet à l’appareil de conserver le temps pendant une perte de courant, même s’il n’a pas accès à un serveur NTP.

Si vous définissez l’heure système, elle n’est pas persistante lorsque l’appareil perd de l’alimentation. Pour conserver la durée de la perte de courant, vous devez appeler la fonction Applibs clock_systohc. Lorsque clock_systohc est appelé, l’heure système est envoyée au RTC.

Conditions requises pour RTC

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

Fichiers d’en-tête

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

 #include <applibs\rtc.h>

Paramètres du manifeste d’application

Pour utiliser les API RTC et d’horloge standard, vous devez ajouter la SystemTime fonctionnalité d’application au manifeste de l’application, puis définir la 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 standard clock_gettime .

Définir l’heure système

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

Synchroniser l’heure système avec le RTC

Lorsque l’heure système est définie, elle ne persiste pas lorsque l’appareil perd de l’alimentation. Pour conserver la durée de la perte de courant, appelez la fonction Clock_systohc des bibliothèques d’applications . Quand clock_systohc est appelé, l’heure système est envoyée au 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é, il remplace l’heure UTC lorsque l’appareil dispose d’une connectivité Internet. Vous pouvez désactiver le service client NTP ; Toutefois, cela peut entraîner l’échec des mises à jour cloud sur l’appareil si la différence entre l’heure système et l’heure du serveur NTP est trop importante.

Définir le fuseau horaire

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

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

Le système d’exploitation Azure Sphere prend en charge certains formats possibles, mais pas tous, pour la variable d’environnement TZ :

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

Pour conserver les paramètres de fuseau horaire pendant une perte de courant, 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 l’heure toutes les 15 secondes jusqu’à ce qu’une synchronisation réussie se soit produite. Après avoir correctement synchronisé l’heure, il tente de resynchroniser l’heure toutes les 24 heures. Quand Azure Sphere effectue la synchronisation de l’heure, il utilise d’abord un port source de client UDP aléatoire compris entre 32678 et 61000. Si ce port échoue, Azure Sphere tente alors d’utiliser le port 124 comme port source du client UDP.

Vous pouvez spécifier que le système obtient l’heure à 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 Function.

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 longueur maximale de chaque nom de domaine complet (FQDN) de serveur est de 255 caractères.

Secours

  • 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 de temps principal. Si le client ne parvient pas à obtenir une réponse de serveur de temps valide, il essaiera le serveur de temps secondaire (si 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 du système d’exploitation via Networking_NtpOption_FallbackServerEnabled échoue, le système contacte ensuite la source de temps du système d’exploitation par défaut prod.time.sphere.azure.net.

    • Au prochain intervalle de synchronisation de 24 heures, le système d’exploitation va revenir en arrière et tenter 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 multirésaisonné

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 multirésaisonné et que les deux interfaces obtiennent des informations sur le serveur NTP via DHCP, le dernier ensemble d’options DHCP NTP traité l’emporte.

Exemple de temps système

L’exemple d’heure système montre comment gérer l’heure système et utiliser le RTC matériel. 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 d’adresse IP inversée pour obtenir des informations d’emplacement, puis obtenir l’heure de localisation et définir l’heure de l’appareil. Ce projet fait partie de la galerie Azure Sphere, une collection de scripts, d’utilitaires et de fonctions non entretenus.

Exemple NTP personnalisé

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