Horloges en temps réel (RTC) dans les minuteries de microcontrôleur

Cet article est le troisième d'une série sur les minuteries de microcontrôleur qui décrit les RTC à l'intérieur d'un microcontrôleur.

Cet article est le troisième d'une série sur les minuteries de microcontrôleur. Le premier article décrit les principales caractéristiques de la plupart des types de temporisateurs et couvre les temporisateurs périodiques, et le second couvre les temporisateurs MCU à modulation de largeur d'impulsion.

Les horloges temps réel (RTC) sont des minuteries dédiées au maintien d'une base de temps d'une seconde. De plus, un RTC est souvent utilisé pour garder une trace de l'heure de l'horloge et de la date du calendrier, que ce soit dans le logiciel ou le matériel. De nombreuses fonctionnalités d'un RTC sont très spécialisées et nécessaires pour maintenir une haute précision et un fonctionnement très fiable. Il existe des dispositifs RTC externes à un microcontrôleur qui s'interfacent avec un I ² Bus C ou SPI.

Cet article décrit les RTC à l'intérieur d'un microcontrôleur.

Présentation des horloges en temps réel

La fonction de base de l'horloge en temps réel est de produire des intervalles d'une seconde et de maintenir un compte continu.

Vous pouvez en voir une représentation dans le schéma ci-dessous.

Figure 1. Ce chronogramme décrit la fonction de base d'un RTC

Est également montrée une fonction de programme, A, lisant un compteur de secondes et programmant un événement, B, pour qu'il se produise trois secondes dans le futur. Cette action s'appelle une alarme. Notez que le compteur de secondes fonctionne en continu et ne s'arrête pas et ne démarre pas. Deux exigences principales d'un RTC sont la précision et le fonctionnement continu.

Le schéma suivant montre les caractéristiques matérielles courantes d'un RTC.

Figure 2. Fonctionnalités matérielles de l'horloge en temps réel

Un RTC a souvent son propre oscillateur interne avec un cristal externe et une option pour utiliser une référence de fréquence externe. Toutes les sources d'horloge fonctionnent à 32 768 Hz. Une source d'horloge externe permet l'utilisation d'un appareil très précis et stable tel qu'un TCXO (oscillateur à cristal compensé en température).

Une source d'horloge est sélectionnée avec un multiplexeur et entrée dans un pré-échelonneur qui divise l'horloge par un facteur de 32 768 (215) pour produire une horloge d'une seconde.

Un RTC de base a un compteur de secondes qui est généralement de 32 bits ou plus. Certains RTC ont des compteurs spécialisés pour garder une trace de l'heure et de la date du calendrier.

Un RTC de base sans compteurs d'heure et de date utilise un logiciel à cet effet. Une option courante est une onde carrée de 1 Hz à partir d'une broche de sortie. Un RTC aura plusieurs événements possibles pour générer une interruption du processeur.

Un RTC a souvent une broche d'alimentation dédiée pour permettre le fonctionnement lorsque le reste du microcontrôleur est hors tension. Cette broche d'alimentation est généralement connectée à une batterie ou à une alimentation séparée.

Précision RTC et compensation de fréquence

La précision d'un RTC dépend de la source d'horloge 32 768 Hz. Dans un oscillateur à cristal bien conçu, la principale source d'erreur est le cristal. Un TCXO externe peut être utilisé pour une synchronisation très précise, ou des techniques spéciales de compensation de fréquence sont utilisées avec des cristaux moins chers et l'oscillateur interne. Il y a trois sources principales d'erreur d'un cristal.

• Tolérance du circuit initial et des cristaux
• Dérive du cristal avec la température
• Vieillissement du cristal

Le graphique ci-dessous montre plusieurs concepts liés à la précision RTC.

Figure 3. Graphique montrant la mesure d'erreur à l'aide de la température utilisée avec l'aimable autorisation de Texas Instruments

La trace bleu foncé sur ce graphique montre une tolérance initiale typique et le changement avec la température. La trace rose montre juste l'erreur de température. La clé pour compenser la température est le fait que le comportement d'un cristal est bien connu et prédit avec une équation quadratique. Si l'erreur initiale est mesurée après la fabrication du circuit imprimé et que la température est connue, il est possible de compenser les sources d'erreur les plus importantes.

La bande jaune est une cible raisonnable pour la précision après une compensation minutieuse. Gardez à l'esprit que 1 ppm sur un an équivaut à environ 30 secondes. Le vieillissement du cristal est difficile à compenser. Heureusement, le vieillissement n'est généralement que de quelques ppm par an.

Comment modifier la synchronisation RTC

Voici deux façons de modifier la synchronisation d'un RTC dans le cadre d'un système pour compenser les erreurs.

Le premier diagramme (Figure 4) représente le nombre de cycles d'oscillateur comptés par le pré-échelonneur pour chaque période du compteur de secondes.

Les deux premières secondes sont les 32 768 cycles habituels. Le logiciel utilise des lectures de température et l'erreur initiale pour déterminer que l'oscillateur fonctionne un peu vite et que 32 768 cycles correspondent en fait à une période de 0,99990 seconde. Pour compenser cette petite erreur, le logiciel demande à la RTC de changer le module du prédiviseur à 32 781 toutes les quatre secondes pour ajouter du temps.

Figure 4. Une représentation des cycles d'oscillateur comptés par un prescaler

Cette technique a l'avantage d'un petit changement dans la période de seconde en seconde. Cependant, la technique nécessite un pré-échelonneur réglable et des registres supplémentaires pour conserver le compte de pré-échelonnage spécial et le nombre de secondes entre l'application du comptage spécial. Je trouve que c'est plutôt cool. Un peu compliqué mais plutôt cool.

Que se passe-t-il si le RTC n'a pas de détartreur spécial pour ajuster la synchronisation ? Ce diagramme montre une autre méthode.

Figure 5. La même situation que celle illustrée à la figure 4, mais sans pré-dimensionneur

Dans ce cas, le nombre dans les cases est le compteur des secondes. Le nombre affiché est 100251 suivi de 100252. Le logiciel calcule en permanence l'ajustement et garde une trace du nombre de secondes RTC. Lorsque l'erreur s'accumule à exactement une seconde, le logiciel ajoute ou soustrait une seconde pour ajuster l'erreur accumulée.

Un inconvénient de cette technique est que le changement de seconde en seconde est important lorsqu'un ajustement est effectué. Cette technique a l'avantage d'être compatible avec n'importe quel RTC.

Sécurité dans les RTC

La sécurité est une exigence intéressante. Il existe des applications où le temps est utilisé pour facturer les clients pour l'utilisation d'un service ou la consommation d'une ressource. Il existe un vaste corpus de pratiques autour de la prévention ou de la détection des piratages des RTC. Les techniques vont de la détection d'intrusion pour les boîtiers aux fonctionnalités spéciales du microcontrôleur.

Le RTC sur un microcontrôleur que j'utilise actuellement a des registres spéciaux pour permettre au logiciel de verrouiller en permanence les registres critiques. Une fois verrouillés, ils ne peuvent pas être modifiés et sont protégés contre le piratage ou le code incontrôlable. La modification de l'heure nécessite une réinitialisation complète du microcontrôleur.

Heure et date

Certains RTC ont des compteurs matériels pour maintenir l'heure et la date du calendrier. Cela nécessite des compteurs pour les minutes, les heures, les jours, les mois, les années et la prise en compte des années bissextiles. L'heure du jour et les dates du calendrier peuvent également être conservées par le logiciel.

Un exemple frappant serait les fonctions de la bibliothèque standard C vues dans le fichier time.h. Pour un microcontrôleur, ce système peut être basé sur le compteur de secondes d'un RTC. Quatre petites fonctions personnalisées doivent être écrites pour prendre pleinement en charge la bibliothèque time.h.

La fonction d'intérêt ici est appelée par la fonction time( ) dans la bibliothèque, qui renvoie le temps en nombre de secondes depuis un point de départ appelé « époque », généralement le 1er janvier 1970. En règle générale, la fonction personnalisée à lire le temporisateur matériel est nommé get_time() ou une variante similaire. Tout ce que fait get_time() est de lire le compteur de secondes et de renvoyer la valeur. La bibliothèque fait le reste pour transformer cette heure en secondes en l'heure et la date actuelles.

Problèmes avec les compteurs de secondes 32 bits

Un compteur de secondes de 32 bits s'exécute pendant longtemps mais pas pour toujours. Il peut y avoir de graves problèmes en raison de la plage de comptage limitée. Par exemple, une heure système basée sur un compteur 32 bits utilisant la bibliothèque standard C et une époque du 1er janvier 1970, pourrait échouer en janvier 2038 lorsque le compteur se remettra en marche après le nombre maximal. Ce problème est connu sous le nom de problème Y2038.

Un échec s'est produit lors de la mission spatiale Deep Impact de la NASA pour étudier une comète. L'objectif principal de la mission a été atteint et le vaisseau spatial a continué à étudier d'autres objets. Cependant, la communication a été soudainement perdue en 2013. Voici un commentaire officiel de la NASA.

« Bien que la cause exacte de la perte ne soit pas connue, l'analyse a révélé un problème potentiel avec l'horodatage informatique qui aurait pu entraîner une perte de contrôle de l'orientation de Deep Impact. »

- Communiqué de presse de la NASA en 2013

Une cause probable d'échec est qu'un temporisateur 32 bits maintenait le temps par incréments de 0,1 seconde et s'est renversé, provoquant la « terminaison » de la mission.

Ma suggestion, lorsque l'heure et la date sont impliquées, est d'utiliser une durée de vie plus longue que prévu dans votre conception.

Qu'est-ce qui suit ?

Le prochain article conclut la série avec les minuteries Watchdog.