Warum verwenden Echtzeituhr-Chips BCD?

Ich habe Dutzende verschiedener Echtzeituhr-Chips auf dem Markt gesehen, sowie eine Reihe von Prozessoren mit einem eingebauten, separat mit Strom versorgten Echtzeituhr-Modul.

Fast alle speichern die Zeit nicht nur als Jahr-Monat-Tag-Stunden-Minuten-Sekunden, sondern sogar die einzelnen Felder werden im BCD- statt im Binärformat gespeichert.

Gibt es dafür einen Grund?

Gibt es Mikroprozessoranwendungen, die etwas Ausgefeilteres tun, als einfach eine Uhr anzuzeigen, bei der das BCD-Format nützlicher ist als das Binärformat, oder bei der das Format Jahr-Monat-Tag-Stunde-Minuten-Sekunden nützlicher wäre als eine reine 47-Bit-Zählung? von Zustandsänderungen des Oszillators?

Soweit ich das beurteilen kann, scheinen die RTCC-Hersteller eine Menge zusätzlicher Schaltkreise hinzuzufügen, um ihre Chips weniger nützlich zu machen. Der einzige Grund, warum ich mir vorstellen kann, dass sich RTCC-Module in Prozessoren so verhalten, ist, dass die Prozessorhersteller eine bereits vorhandene BCD-Implementierung verwenden, anstatt ihre eigene zu produzieren.

Ich kenne die Antwort nicht, aber ich frage mich, ob es eine Korrelation zwischen BCD und 7-Segment-Decodern gibt .
@Prof. Miau Miau: Schöner Name. Die praktischste Methode zum Speichern von Zahlen, die in Hardware angezeigt werden sollen, ist BCD. Es gibt Systeme, die Zahlen speichern, die in anderen Formaten angezeigt werden sollen, aber in vielen Fällen haben sie einfach ein ROM verwendet, um die Zahl direkt auf ihre visuelle Darstellung abzubilden (z Byte-ROM, um jeden Score-Wert in eine 8x8-Form umzuwandeln), aber dies war im Allgemeinen nur praktikabel, wenn der maximale numerische Wert ziemlich klein war.

Antworten (6)

Verwenden alle RTCs die BCD-Codierung?

RTCs von Philips/NXP (sowohl eigenständig als auch in ARM7- oder Cortex-M3-Chips integriert) verwenden keine BCD-Codierung.

Was ist falsch an einem BCD RTC?

Im Vergleich zum flachen Zähler sind die einzigen Operationen, die mit einer geteilten BCD-Uhr schwieriger sind, Zeitdifferenzberechnungen (Addieren von Sekunden oder Berechnen der verstrichenen Zeit). Zeitvergleiche wie: „Ist die aktuelle Zeit größer als die vom Benutzer eingestellte Weckzeit“ sind ebenso einfach.

Was ist das Schöne an BCD-RTCs (und allgemein Split-Field-RTCs)?

Das Aufteilen der Felder ist wirklich nett, wenn Sie sich um das Kalenderdatum kümmern. Menschliche Kalender haben komische Dinge wie unterschiedlich lange Monate und obendrein noch Schaltjahre. Versuchen Sie, dies in einem einzigen Zähler zu tun (Sie können einen Bonuspunkt erhalten, wenn Sie fast keinen Strom verbrauchen). Oh, und versuchen Sie, Wochentage (sehr nützlich in allen Arten von Geräten, die für Menschen bestimmt sind: von Weckern bis zu Heizungsreglern) damit zu unterstützen.

Der BCD-Ansatz hat eine zusätzliche Funktion: Sie erhalten "jede Sekunde" oder "alle zehn Sekunden" kostenlose Interrupts, ohne irgendwelche Berechnungen zu Zeiten oder Daten durchführen zu müssen.

Denn die Rekord-Schaltjahrberechnung ist in den NXP-RTCs etwas daneben, da sie sich nur um die durch 4 teilbare Regel kümmert und die Teilung durch 100 und 400 nicht überprüft. Wenn sie den Jahreszähler in BCD belassen würde, wäre dies trivial und höchstwahrscheinlich richtig gemacht.

Zusammenfassung

  1. Wenn Sie eine monotone Uhr wollen, dann verwenden Sie eine. Sie können einen PIC oder AVR mit dem "RTC-Zähler" kaufen (der nur ein asynchroner Zähler mit einem autonomen 32-kHz-Oszillator ist). Denken Sie nur daran, dass die einfache Anzeige des Datums schwierig sein wird. :)

  2. Wenn Sie die Uhrzeit und das Datum anzeigen und Alarme basierend auf der Benutzereingabe von Uhrzeiten und Daten einstellen müssen, verwenden Sie eine RTC. Und denken Sie daran, dass Ihre RTC-basierten Interrupts ungenau sein können, wenn der Benutzer die aktuelle Uhrzeit und das aktuelle Datum ändert.

Wenn ein Chip die Fähigkeit hat, bestimmte Bits in seiner Alarmfunktion zu ignorieren, nehme ich an, dass Interrupts alle zehn Sekunden, sechzig Sekunden, zehn Minuten oder jede Stunde schöner sind als Zweierpotenzen, aber "alarm = GET_RTC_SECONDS(); alarm -= (alarm % 360)-360; SET_ALARM_SECONDS(alarm); ist kaum schwierig.
Ich habe gerade angefangen, den Gekko zu verwenden, der eine 24-Bit-RTC hat, die fast das ist, was ich will, außer dass er die Zeit nicht halten kann, wenn der Prozessor tot ist. Ich habe mir auch einen ST Micro ARM angesehen, der ein dummes BCD-RTC-Modul hat, das nur Interrupts auf Sekundenbasis unterstützt. Wenn der ST-Chip nie länger als drei Jahre ohne Strom wäre, könnte ich die RTC-Vorstufen so verhexen, dass sie mit 32-facher Geschwindigkeit laufen, und dann Software-Tricks verwenden, um dies zu kompensieren, wodurch ich eine Zeitauflösung von 1/32 Sek. bei den Weckereignissen erhalte, aber die in der RTC gespeicherten Zeiten hätten keinen sinnvollen Bezug zur Kalenderzeit und ...
... also wäre die Notwendigkeit, vom dummen Format der RTC in 1/32-Sekunden-Schritte umzuwandeln, ärgerlich, zumal eine solche Umwandlung bei jedem Schlaf-/Aufwachzyklus erforderlich wäre. Ich schätze, ich bin neugierig, wie viele Leute RTCC-Anzeigen verwenden, ohne sie in einheitliche Sekunden umzuwandeln. Vielleicht gibt es genug, um das YMDHMS-Format lohnenswert zu machen, aber meiner Meinung nach ist es weitaus nützlicher, YMDHMS für menschliche E / A zu reservieren und für alles andere gerade Sekunden (oder einen beliebigen Bruchteil davon) zu verwenden.
@supercat Probiere das mal mit mehreren Alarmlängen (alle 10 Sekunden + jede Minute). Grundsätzlich sind RTCs Echtzeituhren und keine monotonen Uhren, auf denen Sie Ihren RTOS-Timer basieren sollten. Wie gehen Sie mit der Einstellung der richtigen Uhrzeit bei Ihren RTC-basierten Alarmen um? Es kann vorkommen, dass Ihr System einen Tag oder ein Jahr lang schläft, wenn der Benutzer das falsche Datum eingestellt hat, Sie einen Alarm eingestellt haben und der Benutzer später das Datum korrigiert.
@jpc: Ich mache es ziemlich gut mit mehreren Alarmlängen; Es wäre besser, wenn die Timer des PIC Vergleichsregister hätten, die im asynchronen Modus arbeiten könnten, aber glücklicherweise gibt es zwei 16-Bit-Timer, die mit demselben 16-Hz-Takt arbeiten. Timer 1 läuft frei, und ich verfolge den letzten Wert, den ich beobachte. Für Timer 3 berechne ich, wie viele 16tel einer Sekunde ich schlafen sollte, und wenn die Antwort 2-240 ist, lade ich einen Wert von 0xFF10 bis 0xFFFE und stelle sicher, dass Timer 1 sich nicht bewegt hat. Wenn nur noch 1/16 Sekunde übrig ist, warte ich beschäftigt, da PIC-Timer 65.537 Zählungen benötigen, um einen Überlauf zu signalisieren, wenn sie mit 0xFFFF geladen werden.
@jpc: Einige Timing-Ereignisse wie Lockout-Timer werden im Flash gespeichert und basieren auf der Wandzeit (um zu verhindern, dass jemand eine Reihe falscher Kombinationen ausprobiert, die Maschine aus- und wieder einschaltet oder ESD-Zappt, um einen Reset auszulösen, versucht a noch mehr usw.). Durch das Festlegen der Wandzeit werden alle derartigen Ereignisse ungültig (zum Festlegen der Wandzeit sind Supervisor-Anmeldeinformationen erforderlich).
@jpc: Meine Neigung wäre eigentlich gewesen, die RTC-Chip-Zeit nie einzustellen, sondern "Zeit seit dem Einsetzen der Uhrenbatterie" zu behalten und die Differenz zwischen dieser und der Wandzeit zu speichern. Ich habe diesen Ansatz in einer Generation des Produkts verwendet, das einen separaten PIC zum Speichern der batteriegepufferten Zeit verwendete (die Zeit auf diesem PIC war schreibgeschützt) und ihn auf einem Chip mit einem geraden Zähler verwenden würde. Es schien jedoch eine etwas alberne Idee zu sein, die RTC der Maschine einen bedeutungslosen Wert im Datumsformat speichern zu lassen, obwohl ich das vielleicht tun würde, wenn ich den ST Micro-Chip verwende.
Übrigens verwendet die STM32F100-Serie eine 32-Bit-Sekunden-RTC (nicht BCD), aber die STM32F400-Serie greift auf eine BCD-codierte RTC zurück. Seufzen.
Die Tatsache, dass Monate unterschiedlich lang sind, ist ein gutes Argument für Split-Field, aber BCD hat dafür keinen Vorteil gegenüber Binär.
@FedericoRusso: Ein geteiltes Feld wäre sinnvoll, obwohl es in den meisten Anwendungen eher ein Hindernis als eine Hilfe darstellt. Die Wahl von BCD scheint jedoch geradezu bizarr zu sein, wenn man es mit einer CPU bündeln möchte , die keine BCD-Unterstützung hat .

Wenn Sie am Ende Uhren verwenden, interessieren Sie sich eher für Minuten und Zehntelsekunden (um sie anzuzeigen) als nur für die Summe von Sekunden, Minuten und so weiter. Falls Sie nicht an separaten Ziffern interessiert sind, besteht die Möglichkeit, dass Sie sich auch nicht für separate Minuten- oder Sekundenwerte interessieren und dass Sie genauso gut einen langen Binärzähler verwenden können, wie Sie vorgeschlagen haben.
Es ist einfacher, in Software von BCD in Binär umzuwandeln als umgekehrt. Und da BCD-Zähler gegenüber Binärzählern nicht so viel zusätzlichen Platz benötigen, ist es sinnvoll, sich für BCD zu entscheiden.

Wie oft möchte eine Anwendung nichts anderes mit einem Datum und einer Uhrzeit tun, als sie anzuzeigen? Mir scheint, dass es viel üblicher ist, Dinge wie die Berechnung einer Zeit in einiger Entfernung in der Zukunft oder die Bestimmung der seit einem bestimmten Ereignis verstrichenen Zeit usw. zu tun. Was einfacher zu berechnen ist: das Datum und die Uhrzeit 45 Sekunden nach dem 28. Februar 2000 23:59:52 oder 5097582+45 (letzterer Wert unter der Annahme von Mitternacht, 01. Januar 2000 als Epoche)? Wie wäre es mit der Feststellung, ob zwischen dem 28. Februar 2000, 23:59 Uhr, und dem 01. März 2000, 00:03 Uhr, 5 Minuten vergangen sind (gegenüber 5097540.0 und 5184180.0)?
Eine RTC mit einem 48-Bit-Zähler für 65.536stel Sekunden und einem Alarmvergleichsmodul, das die unteren 24 Bit oder so abdeckt, wäre äußerst praktisch für Low-Power-Systeme, da es als Grundlage für eine OS-unabhängige Planung verwendet werden könnte Prozessor aufwachen und schlafen. Wenn in 4 Sekunden etwas passieren soll, könnte das System den RTC-Wert notieren, wenn das Ereignis eintreten sollte. Wenn der Prozessor in 2 Sekunden nichts zu tun hat, könnte er den RTC-Alarm einstellen und schlafen gehen. Wenn das Ereignis eintreten sollte, würde das System aufwachen.
@supercat - Lassen Sie bei Allzweckcomputern das Betriebssystem die Zeit verfolgen und mit diesen Zeitinformationen "nützliche Dinge" tun. Die RTC wird nur einmal konsultiert, um die Zeitinformationen des Betriebssystems zu initialisieren, und dann wird die Zeit durch Interrupts aktualisiert. Aber für viele einfache eingebettete Anwendungen ist dies viel wahrscheinlicher
... es ist viel wahrscheinlicher, dass die Zeit überhaupt nicht vom Programm gehalten wird - stattdessen lesen / aktualisieren Sie einfach die Werte auf dem RTC-Chip, wenn die Zeit verwendet wird.
@Toybuilder: Bei einem batteriebetriebenen Gerät ist es eine schlechte Idee, den CPU-Dienst hundert- oder tausendmal pro Sekunde unterbrechen zu lassen, wenn nichts Nützliches zu tun ist. Es ist viel besser, einen präzisen Alarm einzustellen, um die CPU bei Bedarf zu wecken. Wenn ein ARM-Chip eine RTC und einen nützlichen Wakeup-Timer hätte, die beide mit derselben 32-kHz-Quelle betrieben werden könnten, wäre das in Ordnung. Ich würde die RTC-Zeit einfach einmal beim Start abrufen, in Sekunden umwandeln und damit fertig sein. Keiner der Chips, die ich beobachtet habe, die die RTC mit einer separaten Batterie von der CPU betreiben können, hat jedoch eine gute Weckfunktion.
@supercat - richtig - der "Tick" -Interrupt, während das Betriebssystem läuft, unterscheidet sich von dem 32-kHz-Takt, der die RTC und das Wakeup-Match-Register der RTC speist. Es gibt eine Vielzahl von BCD-RTC-Chips - viele der von mir verwendeten hatten eine Alarmfunktion - stellen Sie einfach die gewünschte Zeit ein, um einen Interrupt auszulösen, der die CPU alarmiert. Für Designs, die den Alarm nicht benötigen, können Sie jedoch auch nur die RTC und die Rechteckwellenausgabe beibehalten, damit die CPU die laufende Zeit verfolgt.
@Toybuilder: Letzteres ist genau der Ansatz, den ich in den letzten Generationen von elektronischen Schlössern verwendet habe. Meine größten Ärgernisse waren das Fehlen jeglicher Impulsausgangsoptionen zwischen 32 kHz und 16 Hz (da ich nicht darauf vertraute, dass ein 1M-Pullup zuverlässig mit einem 32-kHz-Open-Collector-Ausgang funktioniert, war die einzig vernünftige Wahl 16 Hz) und die Schlamperei der PICs Timer-Schaltung.
@supercat: über das Hinzufügen von 45 Sekunden. Wie wäre es, 1 Stunde, 2 Minuten und 3 Sekunden hinzuzufügen? Sie müssen berechnen, dass das 3723 Sekunden sind, diese zum Binärzähler addieren und die Binärsumme wieder in Stunden, Minuten, Sekunden umwandeln. Ich sehe darin keinen Vorteil.
@FedericoRusso: Wenn man einen rein binären Zeitzähler hätte, müsste man nicht in Stunden, Minuten und Sekunden zurückrechnen, außer vielleicht für eine vom Menschen lesbare Anzeige. Man addiert einfach 3723 und das wars. Wenn man mit YMD-HMS-Datums-/Uhrzeitwerten arbeitet, braucht man separaten Code zum Inkrementieren und Dekrementieren, die Sommerzeit ist ein Albtraum, für den Chiphersteller gerne kaputte Unterstützung hinzufügen [wie ein Befehl, der eins von der Stundenzahl abzieht, außer wann es ist null, in diesem Fall tut es nichts]. Die Sommerzeit ist auch im Binärmodus ein Problem, aber nicht ganz so abscheulich.

Ich vermute mehrere Gründe:

Historisch - das machen sie schon seit einiger Zeit so. Wenn Sie möchten, dass Ihr neues Teil ein anderes Teil ersetzt, muss es mehr oder weniger gleich funktionieren. Du bleibst also beim BCD.

Anwendung - Wenn jemand eine RTC von einem kleinen Mikro (etwas im 8-Bit-Bereich, wie ein Low-End-PIC) verwendet, ist der Umgang mit einer großen Zahl (z. B. Ihrem 47-Bit-Zähler) ein großes Problem. Es ist VIEL einfacher, mit den BCD-Ziffern umzugehen, da Sie nicht daran arbeiten müssen, Dinge aufzubrechen.

Nicht so schwer - Die BCD-Zähler zu machen ist nicht so schwer, und tatsächlich denke ich, dass es nicht viel mehr Gatter sind, als sie binär zu machen.

Man kann sich ein System vorstellen, bei dem Sie separate Stunden-, Minuten- usw. Zähler in Binärform anstelle von BCD erhalten (wodurch das Problem des „Aufschlüsselns der 47-Bit-Zahl“ vermieden wird), aber es ist nicht viel einfacher, und Sie werden einige tun Konvertierungen beim Anzeigen des Dings sowieso.

Die 48-Bit-Zahl wäre eine 32-Bit-Sekundenzahl und ein 16-Bit-Bruchteil. Das Arbeiten mit 32-Bit-Zahlen auf einem 8-Bit-Mikro ist nicht so schlimm. Ich kann mir vorstellen, dass bei so etwas wie einem 6502, der gut mit gepacktem BCD umgehen kann, das BCD-Format in einigen Fällen ein paar Bytes einsparen könnte, obwohl die zusätzliche Komplexität der Handhabung zwischen Sekunden, Stunden und Minuten jeden Vorteil zunichte machen würde. Aber sicherlich haben die Leute, die einen RTCC in die ARM-Chips von ST Micro eingebaut haben, nicht erwartet, dass jemand einen 6502 verwendet, um die Daten zu verarbeiten – nicht mit einem 32-Bit-ARM, der genau dort sitzt!
@supercat - obwohl es nicht schwer ist, ist die 32-Bit-Arbeit auf dem 8-Bit-Mikro immer noch ein Schmerz im <piep>. Und bei so etwas wie einem PIC (mit SEHR begrenzten Anweisungen, Registern und RAM-Bereichen) ist es noch schmerzhafter. Was den ARM-Chip angeht – ich wette, das hat mehr mit historischen Präzedenzfällen zu tun als alles andere – ist jeder daran gewöhnt, es so zu machen, also machen sie es auch weiterhin so.
Ich frage mich, welcher Bruchteil der Leute, die RTCC-Peripheriegeräte verwenden, Daten/Zeiten nicht in Sekundenzähler im Unix-Stil umwandelt?
supercat: Alle von ihnen? Welchen Nutzen haben Zeitstempel im Unix-Stil in einer Uhr? OTOH Ihr einziger Anwendungsfall sind RTOS-Alarme, die besser mit einem normalen Timer oder mit einem einfachen "Sekundeninkrement" -Interrupt von der RTC bedient werden.
@jpc: Was ist, wenn Sie feststellen möchten, ob ein bestimmtes Datum in der Sommerzeit liegt, oder ob ein Programm, das an einem bestimmten Datum/einer bestimmten Uhrzeit beginnt und eine bestimmte Länge dauert, ein anderes überlappt? Solche Dinge sind einfach mit geraden Sekunden, aber schwieriger mit YMDHMS. Was die Verwendung eines normalen Timers betrifft, verwende ich derzeit einen 1/16-Sekunden-Tick von einem RTC-Chip, der TMR1 und TMR3 auf einem PIC ansteuert. Das gibt mir ein 1/16-Sekunden-genaues Aufwachen, das auch dann funktioniert, wenn die Haupt-CPU-Uhr gestoppt ist, und ich leite mein gesamtes Timing davon ab.
@supercat Für die Sommerzeit sind Sie zum Scheitern verurteilt, da Zeitzonendatenbanken riesig sind und sich zweimal im Jahr ändern. Vergessen Sie dies auf einem wirklich eingebetteten System. Die zweite Operation, die Sie erwähnen, ist mit einem zweiten Zähler einfach, aber dann ist die Anzeige des Datums ziemlich schwierig. Andernfalls würden Sie sich nicht über die umgekehrte Operation beschweren. Wenn Sie Zeiträume messen müssen, verwenden Sie einen Timer, und wenn Sie Daten wünschen, verwenden Sie eine RTC. Was Sie auf Ihrem PIC gemacht haben, ist das Beste aus beiden Welten (eine RTC und ein monotoner Zähler, die von derselben Referenz abgeleitet sind).
Anwendungen, die ich erstellt habe, verwendeten überhaupt keine Zeitstempel im Unix-Stil, bis wir anfingen, Unterstützung für NTP hinzuzufügen. Obwohl ich sagen muss, dass die Berechnung von Zeitunterschieden mit den Zeitstempeln im Unix-Stil einfacher ist.
@ mjh2007 Unix-Zeitstempel (durch Design und Implementierung) ignorieren Schaltsekunden vollständig, was sie als absoluten Bezugsrahmen etwas problematisch macht. Aber sie sind viel besser als ISO-Datumszeichenfolgen, die auf der Ortszeit ohne richtige Zeitzonenmarkierungen basieren.
@mjh2007: Vielleicht bin ich seltsam, aber das eingebettete System (elektronische Schlösser), an dem ich seit einem Jahrzehnt arbeite, hat von Anfang an Zeitstempel im Unix-Stil verwendet, noch bevor ich anfing, einen separaten RTC-Chip zu verwenden (ich ging zu a separaten RTC-Chip, damit Neustarts die Zeit nicht beeinträchtigen). Das Hinzufügen der Sommerzeit war gar nicht so schwer – die Regeln werden in Form von zwei Single-Byte-Parametern definiert: „first_spring“ und „last_fall“. Die nächste Generation fügte ein Display hinzu, das tatsächlich das Datum anzeigen konnte, und die darauffolgende fügte einen „I2C“-RTC-Chip hinzu, der kein Hardware-I2C verwenden konnte, weil es zuerst Daten LSB sendete.
@ mjh2007: Die Generation danach begann, ein 16-Hz-Signal vom RTC-Chip als Zeitbasis für die meisten Ereignisse zu verwenden, was es der CPU ermöglichte, in den Ruhezustand zu gehen, während Ereignisse anstanden (frühere verwendeten den primären Quarz für die gesamte Zeitmessung mit Ausnahme des Real- Zeituhr, was bedeutete, dass die CPU wach bleiben musste, wenn das Ding nicht vollständig im Leerlauf war). Jetzt überlege ich, einen ARM-basierten Kern für die nächste Generation zu wählen, und finde es frustrierend, dass mir noch keiner mit einem netten einheitlichen Timer aufgefallen ist, der sowohl für Event-Timing als auch für Wall-Time geeignet ist.
@jpc: Was ich gerne hätte, wäre ein langlebiger, batteriegepufferter Timer, der Wakeups mit einer anständigen Auflösung (1/16 Sek. im absoluten Schlimmsten Fall - vorzugsweise so etwas wie 1/256 oder 1/4096 Sek.) und vorzugsweise aufwecken könnte etwas, dessen Register geschrieben werden könnten, ohne sich Gedanken über die Taktsynchronisation und dergleichen zu machen. Gekko hat so ziemlich das, wonach ich suche, außer dass ich etwas haben möchte, das die Langzeitzeit bei ausgeschalteter CPU halten könnte, und ich mache mir ein wenig Sorgen, dass das Synchronisieren des Timer-Vergleichsregisters mit der 32-kHz-Uhr manchmal passieren könnte Ärger verursachen...
@jpc: ... in Fällen, in denen ich ein Timer-Wakeup plane, aber von etwas anderem innerhalb von 100us geweckt werde, das erfordert, dass ich ein anderes Timer-Wakeup plane. Ich würde vermuten, dass das geschäftige Warten in einem solchen Ereignis vor dem erneuten Aktualisieren des Timer-Vergleichsregisters des Gekko kein Problem verursachen sollte, aber ich bin mir nicht sicher.

Ich stimme Michael Kohne zu, dass es viel historisches Momentum gibt.

Frühe MCUs hatten auch viel weniger Platz für Code und Daten (denken Sie zum Beispiel an 128 BYTES RAM). Da Zeitinformationen oft für menschliche Schnittstellenzwecke verwendet werden, war es sinnvoller, die Daten möglichst nahe an dem Format zu halten, das verwendet wird, um Menschen anzuzeigen/einzugeben.

Einige neuere MCUs mit mehr Code- und Datenraum implementieren manchmal Hardware-Echtzeitzähler – diese Geräte führen oft binäre Zählungen von 32-kHz-Ticks.

Ich habe für den Atari 2600 (128 Bytes RAM) codiert und kenne die Vorzüge von BCD. Dinge wie Punktzahlen werden fast immer in BCD berechnet; Ebenennummern sind manchmal. Selbst auf einem 6502 würde ich jedoch erwarten, dass Code zum Konvertieren eines 32-Bit-Sekundenzählers in YMDHMS erforderlich wäre, wenn ich feststellen müsste, ob zwei Datums-/Zeitangaben innerhalb von fünf Minuten voneinander entfernt sind, und festzustellen, ob Sommerzeit gilt etwa so kompakt sein wie Code, um diese Berechnungen ohne solche Konvertierungen durchzuführen. Bei neueren CPUs habe ich einige mit geraden 32-kHz-Zählern gesehen, bei denen die Haupt-CPU am Leben sein muss ...
...aber die mir aufgefallenen Chips mit separat betriebenem RTCC verwenden BCD YMDHMS.
Die neueren CPUs tun dies, da sie billiger sind und etwas weniger Strom verbrauchen (besonders wichtig, da der verwendete Halbleiterprozess für die Herstellung von CPUs und nicht für RTCs optimiert ist).
@jpc: Warum ist es billiger und stromsparender, BCD YMDHMS zu verwenden? Ich würde denken, dass ein 47-Bit-Nur-Lese-Zähler mit einem Komparator auf den unteren 32 Bits einfacher wäre als all das Datums-Parsing-Zeug in einem RTC-Chip. Wenn es keinen Masterfilm einer BCD-Datumsschaltung gibt, der aufgrund einer arkanen, längst vergessenen Magie in ein Design eingesetzt werden kann, um niedrigere Ströme zu erzielen, als mit modernen Methoden verfügbar sind, ist mir nicht klar, warum BCD billiger oder zu verwenden wäre weniger Strom?
Ich habe über die Antwort von @Toybuilders nachgedacht, in der er erklärte, dass neuere CPUs nur Zähler und keine vollständigen RPCs haben.
@jpc: Diejenigen, die ich mit Zählern gesehen habe, erfordern nach dem, was ich gesehen habe, dass die Haupt-CPU mit Strom versorgt wird (was eine Batteriesicherung der CPU erfordert und das Risiko eingeht, die Batterie zu töten, wenn die CPU während der Hauptleistung in einen schlechten Zustand gerät Stromversorgung ist ausgeschaltet) und machen es im Allgemeinen schwierig, bei Dingen wie Neustarts oder Firmware-Updates eine kontinuierliche Zeit einzuhalten. Die einzigen, die ich mit separatem Batterie-Backup gesehen habe, sind YMDHMS-geparste BCD.
@supercat - es gibt Prozessoren mit 32-kHz-Zählern, die auch dann weiterlaufen, wenn die CPU angehalten wird, solange der entsprechende Power-Pin mit minimaler Leistung versorgt wurde.
@Toybuilder: Ein separater Stromanschluss von der Haupt-CPU-Stromversorgung oder der Haupt-CPU-Stromversorgungsanschluss? Und sind die Zähler groß genug, um die Zeit ohne die CPU über einen längeren Zeitraum (z. B. ein Jahr) zu halten? Ich habe Geräte im Einsatz, deren Backup-Batterien für die Uhr starben, als die CPU in einen wackeligen Zustand geriet; Eine separate Stromversorgung für den Zeitnehmer zu haben, scheint ein erhebliches Plus zu sein.
Richtig - diese Geräte haben mehrere Arten von Power-Pins - E / A-Spannung, Prozessorkern, RTC usw. Der RTC-Power-Pin wäre batteriegepuffert und würde sehr wenig Strom benötigen. An diesem Punkt stellt sich die Frage, ob Sie einen ausreichend großen Akku hatten. Wie @jpc anspielte, wird der Halbleiterprozess für diese hochintegrierten MCU-Geräte für die CPU-Leistung bevorzugt, sodass sie selbst in ihrem "Aus" -Zustand am Ende viel stromhungriger sein können als dedizierte externe RTC-Chips, die für geringen Stromverbrauch optimiert sind Verbrauch.
@Toybuilder: Ich bezweifle nicht, dass der Prozess zur Herstellung eines dedizierten RTC-Chips zu einem energieeffizienteren Gerät führen könnte als einer zur Herstellung einer Allzweck-CPU. Andererseits würde ich denken, dass ein gerader Zähler auf beiden Chiptypen nicht mehr Strom benötigen würde als ein BCD-YMDHMS-Zähler; Ich würde auch denken, dass ein gerader 48-Bit-Zähler (oder was auch immer) weniger Strom benötigen würde als die Kombination aus einem geraden 24-Bit-Zähler und einem BCD-YMDHMS-Zähler.
@supercat: Die Einzelheiten sind mir ein Rätsel, aber ich glaube, der entscheidende grundlegende Unterschied ist der Leckstrom des Prozesses. Dedizierte RTC-Chips benötigen in der Größenordnung von Hunderten von nA, während RTC-Blöcke auf einer angehaltenen MCU mehrere uA benötigen. Dieser Größenordnungsunterschied überwiegt den Unterschied in der Schaltungskomplexität. Für ein Gerät, bei dem die Zeit nur für ein paar Wochen gehalten werden muss (z. B. ein Mobiltelefon), reicht ein relativ großer, aber "undichter" Akku aus. Aber für ein Gerät, das möglicherweise mehr als 10 Jahre ohne Stromversorgung ist (z. B. Zugangskontrollgeräte), das mit einer langzeitstabilen Knopfbatterie betrieben wird? Es ist wichtig!
@Toybuilder: Ich kann schätzen, dass eigenständige RTC-Chips Vorteile haben. Wer weiß - vielleicht gibt es sogar einen, der billig ist und einen nützlichen Rechteckwellenausgang hat, der nicht viel Strom in einem Pullup-Widerstand verschwendet (z. B. würde ein 256-Hz-Ausgang mit einer niedrigen Zeit von 1/65536 Sekunden einen kleinen Bruchteil davon verschwenden Strom eines 16-Hz-Ausgangs mit einer niedrigen Zeit von 1/32 s, obwohl er eine 256-fache Verbesserung der Auflösung bietet).
@supercat Vielleicht sollten Sie eine Frage zum Bau eines Ultra-Low-Power-Oszillators + -Zählers aus diskreten Logikchips stellen. Sollte machbar sein.
@jpc: Es ist wahrscheinlich nicht besonders kostengünstig oder energieeffizient, dies mit einer gemeinsamen diskreten Logik zu tun, da Timer-Ausgangsdaten in physische Pins gesteckt werden müssen. Aus rein funktionaler Sicht würde eine minimalistische RTC wahrscheinlich aus drei Chips plus dem Oszillator bestehen. Ich würde einen CD4517 (zwei 64-Bit-Schieberegister), einen 74HC373 (Latch) und einen 74HC153 (2x4 Mux) vermuten. Ein solches System könnte alle 64 Zyklen einen 64-Bit-Zählwert verschieben (vorausgesetzt, ein Prozessor half bei der Initialisierung). Die Verlustleistung wäre jedoch mies.
@jpc: Eine interessantere Frage könnte sein, warum ich keine Designs sehe, die Graustufenzähler mit Quadratureingabe verwenden. Die Ressourcenkosten sind angemessen, und im Gegensatz zu einem herkömmlichen Ripple-Zähler hätte der Graustufenzähler mit Quadratureingang nichts gegen Eingänge, die durch "komische" Zustände übergehen, vorausgesetzt, dass immer dann, wenn ein Eingang unscharf war, der andere fest war.
[Korrektur: Graycode-Zähler]
@supercat Sie haben Recht, dass die Energieeffizienz in einer solchen Schaltung ein Problem sein kann. Ich habe mehrere billige Zähler durchsucht, aber alle verwenden etwa 80 μA bei 25 $^\circ C$. Ich glaube, ich stelle hier mal eine Frage. :)
@jpc: Übrigens, wie gefällt dir das Konzept der Verwendung eines Schieberegisters? Dies könnte die minimale Schaltungsmethode sein (insbesondere wenn man eine Vierphasenverschiebung verwendet, sodass vier transparente Latches drei Bits halten könnten), obwohl die verbesserte Nützlichkeit eines parallelen Zählers und Komparators meiner Meinung nach die zusätzliche Schaltung wert wäre. Ein Graycode-Zähler scheint der richtige Ansatz zu sein, da er Synchronisationsprobleme vermeiden würde, obwohl mir keine Low-Power-Zähler mit Graycode bekannt sind. Nicht sicher warum, da Graycode-Ripple-Zähler effizient sein sollten.
@supercat Ich habe dies als Frage gestellt . Die Synchronisierung sollte durch wiederholtes Lesen des Zählerwerts möglich sein, bis Sie zweimal denselben Wert erhalten.
@jpc: Die Synchronisierung kann ein Problem mit Wakeup-Ereignissen sein. Wenn ein Zähler von 7F auf 80 klickt, können die Bits abhängig von der Reihenfolge, in der sie umschalten, vorübergehend mit jedem anderen Wert verglichen werden. Wenn dagegen ein Graycode-Zähler von 40 auf C0 oder C0 auf C1 tickt, gibt es kein Problem. Es gibt andere Möglichkeiten, falsche Vergleiche zu vermeiden, aber bei vielen solchen Ansätzen treten Synchronisationsprobleme auf, wenn der Vergleichswert geändert wird. Wenn man Graycode-Zähler verwendet, muss man nur die Vergleichs-Match-Ausgabe synchronisieren ...
@jpc: ... indem es während eines Schreibvorgangs asynchron im Reset gehalten und durch einen Doppelsynchronisierer auf der Haupt-CPU-Uhr geleitet wird, der transparent wird, wenn die Hauptuhr gestoppt wird (der Doppelsynchronisierer sollte in diesem Fall Metastabilitätsprobleme vermeiden der Zähler rückt direkt nach dem Schreiben in das Vergleichsregister vor und erzeugt so einen Runt-Impuls am Vergleichsausgang).

Falls es jemanden interessiert, ich habe mir nur die 32F-Serie von ST angesehen und es scheint, dass die neuere 32L-Serie zwar eine BCD-RTC verwendet, die 32F jedoch einen direkten 32-Bit-Zähler mit konfigurierbarem Vorteiler verwendet und einen separaten Batterieeingang dafür bereitstellt (Hurra! ). Ich hätte lieber einen längeren geraden Zähler ohne einen konfigurierbaren Preskalar gehabt (damit ich eine Genauigkeit von 1/256 Sek. erreichen, aber die Zeit jahrelang halten könnte, ohne mich um das Wickeln kümmern zu müssen), aber wenn ich die Prescale auf 1/64 Sek. einstellen würde, könnte der Timer laufen zwei Jahre ohne Überlaufen. Nicht optimal, aber auch nicht schlecht. Ein wenig unästhetisch, dass, wenn jemand die Maschine einschaltet, nachdem sie zu lange ausgeschaltet war (2,1+ Jahre), die Uhrzeit/das Datum unbemerkt um 2,1 Jahre zurückrutschen würde, aber kaum ein großes Problem (der Zähler hat eine Überlaufflagge, aber in viele Fälle, die nicht besonders hilfreich wären. Wenn die Maschine zwei Jahre lang eingeschaltet war, bevor sie ausgeschaltet wurde, und drei Monate später eingeschaltet wurde, würde der Timer voraussichtlich überlaufen; die Frage wäre, ob es zweimal übergelaufen ist, und dafür kenne ich keine Flagge.

Maxim scheint mit DS1372U genau das zu tun, was Sie wollen . Es benötigt weniger als 1 μA, kostet 1,7 USD und ist bei DigiKey und Mouser erhältlich(!). Das einzige Problem ist, dass es keine Alarme mit einer Genauigkeit von mehr als 1 Sekunde zu bieten scheint und die niedrigste Ausgangstaktrate $ \ approx $ 4 kHz beträgt.

Es ist ein wenig teuer und erlaubt keine Möglichkeit, Inkremente kleiner als eine Sekunde auszulesen. Ein 4096-Hz-Ausgang wäre schön, obwohl es viel schöner wäre, wenn er für 1/65536 einer Sekunde niedrig und für 15/65536 hoch wäre. Open-Collector-Ausgänge sollten so wenig wie möglich niedrig sein.
Warum verwenden Echtzeituhr-Chips BCD?
AntwortenHierDatenschutz-Bestimmungen1y, 0v