Pourquoi les puces d'horloge en temps réel utilisent BCD

14

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.

rtc supercat
la source
2
Je ne connais pas la réponse mais je me demande s'il y a une corrélation entre le BCD et le décodeur 7 segments ?
Prof. Meow Meow
@Prof. Meow Meow: Joli nom. La méthode la plus pratique pour stocker les numéros qui vont être affichés dans le matériel est BCD. Il existe des systèmes qui stockaient des nombres à afficher dans d'autres formats, mais dans de nombreux cas, ils utilisaient simplement une ROM pour mapper directement du nombre à sa représentation visuelle (par exemple, la machine d'arcade "Tank" utilisait des compteurs de score 6 bits et un 512 octet ROM pour convertir chaque valeur de score en une forme 8x8) mais cela n'était généralement réalisable que si la valeur numérique maximale était assez petite.
supercat

Réponses:

12

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.

jpc
la source
1
Je viens de commencer à utiliser le Gekko, qui a un RTC 24 bits, c'est presque ce que je veux, sauf qu'il ne peut pas garder l'heure quand le processeur est mort. Je regardais également un ST Micro ARM, qui a un module RTC BCD idiot qui ne prend en charge les interruptions que sur une base d'une seconde. Si la puce ST ne restait jamais sans alimentation pendant plus de trois ans, je pourrais utiliser les prescalars RTC pour fonctionner à une vitesse de 32x, puis utiliser des astuces logicielles pour compenser, obtenant ainsi une résolution temporelle de 1/32 s sur les événements de réveil, mais les heures stockées dans le RTC n'auraient aucune relation significative avec l'heure du calendrier et ...
supercat
1
... donc la nécessité de convertir du format stupide du RTC en incréments de 1/32 de seconde serait gênante, d'autant plus qu'une telle conversion serait requise à chaque cycle de veille / réveil. Je suppose que je suis curieux de savoir combien de personnes utilisent les lectures RTCC sans se convertir en secondes unifiées. Peut-être qu'il y en a assez pour que le format YMDHMS en vaille la peine, mais à mon avis, il est beaucoup plus utile de réserver YMDHMS pour l' homme E / S et d'utiliser des secondes droites (ou toute fraction de celles-ci) pour tout le reste.
supercat
1
@jpc: Mon inclination aurait en fait été de ne jamais régler l'heure de la puce RTC, mais plutôt de garder "le temps depuis l'installation de la pile d'horloge", et de stocker la différence entre cela et l'heure du mur. J'ai utilisé cette approche dans une génération du produit qui utilisait un PIC séparé pour conserver le temps de batterie (l'heure sur ce PIC était en lecture seule) et l'utiliserait sur une puce avec un compteur droit. Cela semblait être une idée un peu loufoque, cependant, que le RTC de la machine stocke une valeur formatée sans date, bien que si j'utilise la puce ST Micro, je pourrais simplement le faire.
supercat
1
BTW, la série STM32F100 utilise un RTC de 32 bits secondes (pas BCD), mais la série STM32F400 régresse à nouveau vers un RTC codé BCD. Soupir.
Mark Lakata
1
@FedericoRusso: Le champ divisé aurait un certain sens, bien qu'il soit plus susceptible d'être un obstacle qu'une aide dans la plupart des applications. Le choix de BCD, cependant, semble carrément bizarre comme un choix de bundle avec un processeur qui ne prend pas en charge BCD .
supercat
3

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.

stevenvh
la source
2
À quelle fréquence une application souhaite-t-elle ne rien faire avec une date et une heure autres que l’afficher? Il me semble qu'il est beaucoup plus courant de vouloir faire des choses comme calculer un temps à une certaine distance dans le futur, ou déterminer combien de temps s'est écoulé depuis un événement particulier, etc. Ce qui est plus facile à calculer: la date et l'heure 45 secondes après le 28 février 2000 23:59:52, ou 5097582 + 45 (cette dernière valeur supposant minuit le 1er janvier 2000 comme époque)? Que diriez-vous de déterminer si 5 minutes se sont écoulées entre le 28-fév-2000 23:59 et le 01-mars-2000 00:03 (vs 5097540.0 et 5184180.0)
supercat
1
Un RTC avec un compteur 48 bits pour 65 536e de seconde et un module de comparaison d'alarmes couvrant les 24 derniers bits environ seraient extrêmement pratiques pour les systèmes de faible puissance, car il pourrait être utilisé comme base pour la planification du système d'exploitation indépendamment de processeur réveil et sommeil. Si quelque chose est censé se produire dans 4 secondes, le système peut noter la valeur RTC lorsque l'événement doit se produire. Si dans 2 secondes, le processeur se retrouve sans rien faire, il pourrait régler l'alarme RTC et se mettre en veille. Lorsque l'événement devait se produire, le système se réveillait.
supercat
@supercat - pour les ordinateurs à usage général, laissez le système d'exploitation suivre le temps et faire des "choses utiles" avec ces informations de temps. Le RTC n'est consulté qu'une seule fois pour initialiser les informations de temps du système d'exploitation, puis l'heure est mise à jour par des interruptions. Mais pour de nombreuses utilisations embarquées simples, il est beaucoup plus probable que
Toybuilder
1
@Toybuilder: Ce dernier est exactement l'approche que j'ai utilisée au cours des dernières générations de serrure électronique. Mes plus gros ennuis étaient le manque de choix de sortie d'impulsion entre 32 kHz et 16 Hz (puisque je ne faisais pas confiance à un pullup de 1 M pour fonctionner de manière fiable avec une sortie à collecteur ouvert de 32 kHz, le seul choix raisonnable était 16 Hz), et le manque de précision des PIC. circuits de minuterie.
supercat
1
@FedericoRusso: Si l'on avait un compteur de temps directement binaire, on n'aurait pas à reconvertir en heures, minutes et secondes, sauf peut-être pour un affichage lisible par l'homme. On ajoute simplement 3723 et c'est tout. Lorsque vous travaillez avec des valeurs de date / heure YMD-HMS, il faut un code distinct pour incrémenter et décrémenter, l'heure d'été est un cauchemar pour lequel les fabricants de puces semblent aimer ajouter un support cassé [comme une commande qui soustrait un du nombre d'heures sauf lorsque c'est zéro, auquel cas il ne fait rien]. L'heure d'été est également une douleur en binaire, mais pas aussi hideuse.
supercat
3

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.

Michael Kohne
la source
1
Le nombre de 48 bits serait un nombre de secondes de 32 bits et une fraction de 16 bits. Travailler avec des nombres 32 bits sur un micro 8 bits n'est pas si mal. Je peux imaginer que sur quelque chose comme un 6502 qui pourrait bien gérer le BCD compressé, le format BCD pourrait économiser quelques octets dans certains cas, bien que la complexité supplémentaire de la gestion du transport entre secondes-heures-minutes compenserait tout avantage. Mais les gens qui ont construit un RTCC dans les puces ARM de ST micro ne s'attendaient certainement pas à ce que quelqu'un utilise un 6502 pour traiter les données - pas avec un ARM 32 bits assis juste là!
supercat
1
@supercat - bien que ce ne soit pas difficile, faire le travail 32 bits sur le micro 8 bits est toujours une douleur dans le <bleep>. Et sur quelque chose comme un PIC (avec des instructions TRÈS limitées et des espaces de registre et de RAM), c'est encore plus pénible. En ce qui concerne la puce ARM - je parie que cela a plus à voir avec un précédent historique qu'autre chose - tout le monde a l'habitude de le faire de cette façon, alors ils continuent de le faire de cette façon.
Michael Kohne
1
Je me demande quelle fraction des personnes qui utilisent des périphériques RTCC ne convertissent pas les dates / heures en compteurs de secondes de style Unix?
supercat
1
supercat: Tous? À quoi servent les horodatages de style Unix dans une horloge? OTOH votre seul cas d'utilisation est les alarmes RTOS qui sont mieux servies avec une minuterie normale ou avec une simple interruption de "deuxième incrément" du RTC.
jpc
1
@jpc: que se passe-t-il si vous voulez déterminer si une date donnée est en heure d'été ou si un programme qui démarre à une certaine date / heure et dure une certaine durée en chevauchera une autre? De telles choses sont faciles avec des secondes d'affilée, mais plus difficiles avec YMDHMS. Quant à l'utilisation d'une minuterie normale, ce que j'utilise actuellement est un tick 1/16 sec d'une puce RTC pilotant TMR1 et TMR3 sur un PIC; cela me donne un réveil précis de 1/16 de seconde qui fonctionne même lorsque l'horloge du processeur principal est arrêtée, et je tire tout mon timing de cela.
supercat
1

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.

Constructeur de jouets
la source
J'ai codé pour l'Atari 2600 (128 octets de RAM), et je connais les vertus du BCD. Des choses comme les scores sont presque toujours calculées en BCD; les numéros de niveau le sont parfois. Même sur un 6502, cependant, je m'attendrais à ce que si je devais déterminer si deux dates / heures étaient à moins de cinq minutes l'une de l'autre et déterminer si l'heure d'été était en vigueur, un code pour convertir un compteur de secondes 32 bits en YMDHMS serait être à peu près aussi compact que le code pour faire ces calculs sans faire de telles conversions. En ce qui concerne les nouveaux processeurs, j'en ai vu certains avec des compteurs 32Khz droits qui nécessitent que le processeur principal soit vivant ...
supercat
... mais les puces que j'ai remarquées qui ont un RTCC alimenté séparément utilisent BCD YMDHMS.
supercat
Les CPU plus récents le font car ils sont moins chers et utilisent un peu moins de courant (particulièrement important car le processus semi-conducteur utilisé est optimisé pour fabriquer des CPU et non des RTC).
jpc
@jpc: Pourquoi est-il moins cher et moins courant d'utiliser BCD YMDHMS? Je pense qu'un compteur en lecture seule de 47 bits avec un comparateur sur les 32 bits inférieurs serait plus simple que tous les éléments d'analyse de date dans une puce RTC. À moins qu'il y ait un film principal d'un circuit de date BCD qui, en raison d'une magie obscure oubliée depuis longtemps, peut être inséré dans une conception pour atteindre des courants inférieurs à ceux disponibles avec les méthodes modernes, je ne sais pas pourquoi le BCD serait moins cher ou utiliser moins courant?
supercat
Je pensais à la réponse de @Toybuilders dans laquelle il a déclaré que les nouveaux processeurs n'ont que des compteurs et non des RPC à part entière.
jpc
1

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.

supercat
la source
0

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.

jpc
la source
1
C'est un peu cher et cela ne permet pas de lire des incréments inférieurs à une seconde. Une sortie à 4096 Hz serait bien, mais elle serait bien plus agréable si elle était faible pour 1/65536 de seconde et élevée pour 15/65536. Les sorties à collecteur ouvert doivent être aussi faibles que possible.
supercat