J'ai vu des dizaines de puces d'horloge en temps réel différentes sur le marché, ainsi qu'un certain nombre de processeurs avec un module d'horloge en temps réel alimenté séparément.

Presque tous d'entre eux stockent non seulement le temps sous forme d'année-mois-jour-heures-minutes-secondes, mais même les champs individuels sont stockés en BCD plutôt qu'en format binaire.

Y a-t-il une raison sous-jacente à cela?

Existe-t-il des applications de microprocesseur qui font quelque chose de plus sophistiqué que d'afficher simplement une horloge où le format BCD est plus utile que binaire, ou où le format année-mois-jour-heure-minutes-secondes serait plus utile qu'un comptage direct de 47 bits des changements d'état de l'oscillateur?

D'après ce que je peux dire, il semble que les fabricants de RTCC ajoutent beaucoup de circuits supplémentaires pour rendre leurs puces moins utiles; la seule raison pour laquelle je peux comprendre que les modules RTCC dans les processeurs se comportent de cette façon est que les fournisseurs de processeurs utilisent une implémentation BCD préexistante plutôt que de produire la leur.

Tous les RTC utilisent-ils l'encodage BCD?

Les RTC de Philips / NXP (à la fois autonomes et intégrés dans les puces ARM7 ou Cortex-M3) n'utilisent pas le codage BCD.

Quel est le problème avec un BCD RTC?

Par rapport au compteur plat, les seules opérations qui sont plus difficiles avec une horloge BCD divisée sont les calculs de différence de temps (ajout de secondes ou calcul du temps écoulé). Les comparaisons de temps comme: "est l'heure actuelle supérieure à l'heure d'alarme définie par l'utilisateur" sont tout aussi faciles.

Qu'y a-t-il de bien avec les RTC BCD (et généralement à champ divisé)?

Le fractionnement des champs est vraiment agréable lorsque vous vous souciez de la date du calendrier. Les calendriers humains ont des choses amusantes comme des mois de différentes durées et en plus de ces années bissextiles. Essayez de le faire dans un seul compteur (vous pouvez obtenir un point bonus pour utiliser presque pas de puissance). Oh et essayez de prendre en charge les jours de la semaine (très utile dans toutes sortes d'appareils destinés aux humains: des réveils aux contrôleurs de chauffage) avec cela.

L'approche BCD a une caractéristique supplémentaire: vous obtenez des interruptions «toutes les secondes» ou «toutes les dix secondes» gratuitement, sans avoir à faire de calculs sur les heures ou les dates.

Pour le calcul de l'année bissextile record est un peu hors tension dans les RTC NXP car il ne s'occupe que de la règle divisible par 4 et ne vérifie pas la division par 100 et 400. S'il gardait le compteur d'année en BCD, ce serait trivial et très probablement bien fait.

Sommaire

1. Si vous voulez une horloge monotone, utilisez-en une. Vous pouvez acheter un PIC ou AVR avec le "compteur RTC" (qui est juste un compteur asynchrone avec un oscillateur autonome à 32 kHz). Gardez à l'esprit qu'il sera difficile d'afficher simplement la date. :)

2. Lorsque vous devez afficher l'heure et la date et définir des alarmes en fonction de la saisie par l'utilisateur des heures et des dates, utilisez un RTC. Et n'oubliez pas que lorsque l'utilisateur modifie l'heure et la date actuelles, vos interruptions basées sur RTC peuvent être inexactes.

Lorsque vous utilisez des horloges à la fin, vous êtes plus susceptible d'être intéressé par les minutes et les dizaines de secondes (pour les afficher) que par le total des secondes, des minutes, etc. Dans le cas où vous n'êtes pas intéressé par des chiffres séparés, il est probable que vous ne vous souciez pas non plus des valeurs de minutes ou de secondes distinctes, et que vous pourriez aussi bien utiliser un long compteur binaire comme vous l'avez suggéré.
Il est plus facile de convertir de BCD en binaire dans un logiciel que l'inverse. Et puisque les compteurs BCD ne nécessitent pas beaucoup plus de biens immobiliers supplémentaires que les compteurs binaires, il est logique de choisir BCD.

Je soupçonne plusieurs raisons:

Historique - ils le font de cette façon depuis un certain temps maintenant. Si vous voulez que votre nouvelle pièce remplace une autre pièce, alors elle doit plus ou moins fonctionner de la même manière. Donc, vous restez avec le BCD.

Application - si quelqu'un utilise un RTC à partir d'un petit micro (quelque chose dans la plage de 8 bits, comme un PIC bas de gamme), alors traiter avec un grand nombre (comme votre compteur 47 bits) est une grosse douleur dans le cou. Il est BEAUCOUP plus facile de gérer les chiffres BCD, car vous n'avez pas à travailler pour casser les choses.

Pas si difficile - Faire les compteurs BCD n'est pas si difficile, et en fait je pense que ce ne sont pas beaucoup plus de portes que de les faire binaires.

On peut imaginer un système où vous obtenez des compteurs séparés d'heure, de minute, etc. en binaire au lieu de BCD (évitant ainsi le problème de `` décomposer le nombre de 47 bits ''), mais ce n'est pas beaucoup plus facile, et vous allez en faire conversions lors de l'affichage de la chose de toute façon.

Je suis d'accord avec Michael Kohne qu'il y a beaucoup d'élan historique.

Les premiers MCU avaient également beaucoup moins d'espace pour le code et les données (pensez à 128 octets de RAM, par exemple). Étant donné que les informations temporelles sont souvent utilisées à des fins d'interface avec les humains, il était plus logique de garder les données les plus proches du format utilisé pour l'affichage / la saisie par les humains.

Certains nouveaux microcontrôleurs avec plus de code et d'espace de données implémentent parfois des compteurs matériels en temps réel - ces appareils conservent souvent des comptages binaires de ticks de 32 kHz.

Au cas où quelqu'un serait intéressé, je regarde simplement la série 32F de ST et il semble que tandis que la nouvelle série 32L utilise un BCD RTC, le 32F utilise un compteur 32 bits droit avec prescalar configurable et fournit une entrée de batterie séparée pour cela (hourra! ). J'aurais plutôt eu un compteur droit plus long sans prescalar configurable (donc je pourrais obtenir une précision de 1 / 256sec mais garder le temps pendant des années sans avoir à se soucier de l'emballage) mais si je devais régler la pré-échelle pour 1 / 64sec, le minuteur pourrait fonctionner deux ans sans débordement. Pas idéal, mais pas trop mal. Un peu inesthétique que si quelqu'un allume la machine après une période d'arrêt trop longue (2,1+ ans), l'heure / la date reculerait de 2,1 ans, mais ce n'est pas un problème majeur (le compteur a un indicateur de débordement, mais dans de nombreux cas qui ne seraient pas terriblement utiles. Si la machine était allumée pendant deux ans avant d'être mise hors tension et qu'elle était allumée trois mois plus tard, la minuterie devrait déborder; la question serait de savoir s'il a débordé deux fois, et je ne connais aucun drapeau pour cela.

Maxim semble faire exactement ce que vous voulez avec le DS1372U . Il nécessite moins de 1 μA, coûte 1,7 USD et est disponible (!) Sur DigiKey et Mouser. Le seul problème est qu'il ne semble pas offrir d'alarmes avec plus de 1 seconde de précision et que la fréquence d'horloge de sortie la plus basse est de $ \ environ 4 kHz.