Vous n'avez pas besoin d'un RTC pour construire une horloge: la puce ATmega possède tout le matériel nécessaire pour effectuer les tâches du RTC lui-même. Voici comment:
Obtenez un cristal de montre à 32768 Hz: achetez-le ou démontez une vieille horloge. Ces cristaux, spécialement conçus pour garder le temps, ont une dérive de température extrêmement faible. Vous en auriez également besoin si vous vouliez utiliser une puce RTC.
Configurez les fusibles de votre ATmega pour fonctionner avec l'oscillateur RC 8 MHz. Cela rendra votre millis()fonction horriblement inexacte et libérera également les broches XTAL1 et XTAL2.
Connectez le cristal de la montre aux broches TOSC1 et TOSC2. Ce sont les mêmes broches que XTAL1 et XTAL2 (9 et 10 sur le 328P). Les différents noms sont utilisés pour signifier différentes fonctions.
Configurez le temporisateur / compteur 2 pour un fonctionnement asynchrone, un mode de comptage normal, un pré-échelle réglé sur 128 et activez l'interruption de dépassement de temporisation.
Vous obtiendrez maintenant une interruption TIMER2_OVF à un rythme très régulier d'une fois par seconde. Il vous suffit de faire avancer l'affichage de l'horloge d'une seconde dans l'ISR. Entre les interruptions, vous pouvez mettre le MCU en veille très profonde (mode veille à économie d'énergie: rien ne fonctionne que Timer / Counter 2) et fonctionner pendant des années sur quelques cellules AA. À moins que l'écran ne soit énergivore, évidemment.
J'ai fait exactement cela pour construire mon horloge murale à une main de 24 heures . Ce lien pointe maintenant vers la traduction anglaise de la documentation originale en français.
Étalonnage du quartz
Si vous ne calibrez pas votre quartz, vous pouvez vous attendre à une dérive importante, généralement quelques secondes par semaine . Le taux de dérive dépend de la capacité parasite des traces qui connectent le cristal au MCU. En principe, il pourrait être supprimé en ajoutant une capacité supplémentaire finement réglée. Il convient de noter que vous auriez le même problème de dérive avec un RTC.
Si vous êtes satisfait de ce type de précision, alors vivez avec et soyez heureux. Cependant, si vous souhaitez mesurer la dérive, vous remarquerez qu'elle est très stable. Vous pouvez ensuite facilement le compenser dans le logiciel et atteindre une précision de quelques secondes par an .
L'algorithme de correction de la dérive est très simple. A partir de la dérive mesurée, vous déterminez le délai précis entre les interruptions, qui devrait être très proche de 10 9 nanosecondes, puis:
#define ONE_SECOND 1000000000 // in nanoseconds
#define ONE_INTERRUPT 999993482 // for example
ISR(TIMER2_OVF_vect)
{
static uint32_t unaccounted_time;
unaccounted_time += ONE_INTERRUPT;
while (unaccounted_time >= ONE_SECOND) {
advance_display_by_one_second();
unaccounted_time -= ONE_SECOND;
}
}
Dans l'exemple ci-dessus, le quartz est légèrement trop rapide et le logiciel compense en «manquant» une tique tous les quelques jours. Si le quartz était trop lent, le même code doublerait plutôt une fois tous les quelques jours.
Ce type d'étalonnage pourrait également être effectué pour un RTC, mais il serait beaucoup plus complexe car le RTC rapporte l'heure sous une forme décomposée qui ne se prête pas naturellement aux opérations arithmétiques.
