Inside Mikrocontroller-Echtzeituhren (RTCs): Design, Genauigkeit und Sicherheit

Inside Mikrocontroller-Echtzeituhren (RTCs): Design, Genauigkeit und Sicherheit

Teil 3 der Mikrocontroller-Timer-Serie: Inside Real-Time Clocks (RTCs).

In diesem Teil tauchen wir in das Herz mikrocontrollerbasierter Echtzeituhren (RTCs) ein. Vorherige Beiträge deckten Timer-Grundlagen und Pulsbreitenmodulation ab. Dieser Artikel erklärt, wie RTCs präzise Ein-Sekunden-Intervalle erzeugen, Zeit und Datum verwalten, Drift kompensieren und gegen Manipulation schützen.

Was ein RTC tut

RTCs sind dedizierte Hardware, die einen stetigen Ein-Sekunden-Takt erzeugt und einen kontinuierlichen Zähler führt. Ein einfaches Timing-Diagramm zeigt den Taktgenerator, eine Software-Routine, die den Sekunden-Zähler liest, und einen Alarm, der drei Sekunden später feuert. Die Kernanforderungen sind Genauigkeit und kontinuierlicher Betrieb.

Abbildung 1. Grundlegendes RTC-Timing-Diagramm

Typische Hardware-Merkmale

Moderne Mikrocontroller-RTCs umfassen meist:

• einen internen 32.768 Hz Oszillator (oft mit Quarz- oder TCXO-Option)
• einen externen Takteingang für hochpräzise Referenz
• einen Multiplexer zur Quellenwahl, gefolgt von einem Vorteiler, der durch 32.768 (2¹⁵) teilt, um den 1-Hz-Takt zu erzeugen
• einen 32-Bit- (oder größeren) Sekunden-Zähler und optionale Zähler für Minuten, Stunden, Tage, Monate, Jahre
• einen 1-Hz-Rechteckwellen-Ausgangspin
• Interrupt-Pins für Alarme, Sekundenticks oder andere Events
• einen dedizierten Backup-Strom-Pin, meist eine Knopfzellenbatterie, damit die Uhr läuft, wenn der Rest des Chips stromlos ist

Abbildung 2. Gängige RTC-Hardware-Merkmale

Genauigkeit und Frequenzkompensation

Das Herz eines RTC ist sein 32.768 Hz Quarz. In einem gut designten Oszillator ist der Quarz selbst die Hauptfehlerquelle. Externe TCXOs können Sub-ppm-Stabilität liefern, während interne Oszillatoren kompensiert werden können, um vergleichbare Performance zu erreichen.

Typische Fehlerquellen:

• Anfangstoleranz des Quarzes und der umgebenden Schaltung
• Temperaturdrift, die einer vorhersagbaren quadratischen Kurve folgt
• Alterung, meist nur wenige ppm pro Jahr

Die folgende Grafik, mit freundlicher Genehmigung von Texas Instruments, zeigt, wie Temperatur und Anfangsfehler sich kombinieren und wie sorgfältige Kalibrierung den Gesamtfehler in den gelben Bereich bringt – ein erreichbares Ziel nach Board-Level-Messung.

Abbildung 3. Fehler vs. Temperatur (Texas Instruments)

Mit 1 ppm Genauigkeit über ein Jahr weicht die Uhr um ca. 30 Sekunden ab – weit besser als die meisten Hobbyprojekte, aber in missionskritischen Systemen trotzdem erwägenswert.

Timing-Fehler kompensieren

Zwei gängige Strategien existieren, um kleine Drift zu korrigieren, ohne die Hardwaresimplizität zu opfern:

Einstellbarer Vorteiler. Wenn der RTC einen programmierbaren Vorteiler exponiert, kann Software den Modulus alle paar Sekunden anpassen. Beispiel: Eine Uhr, die 0,00010 s zu schnell läuft, kann den Vorteiler von 32.768 auf 32.781 jede vierte Sekunde ändern, wodurch die fehlenden 0,00010 s jedes Mal hinzugefügt werden.

Abbildung 4. Vorteiler-Anpassung zur Drift-Kompensation

Vorteile: Feinkörnige Korrekturen und minimaler Code. Nachteil: Erfordert einstellbaren Vorteiler und zusätzliche Register.

Software-Korrektur. Wenn die Hardware keinen programmierbaren Vorteiler hat, kann die Firmware einen laufenden Zähler des Sekunden-Zählers führen. Wenn der akkumulierte Fehler eine Sekunde erreicht, fügt sie einen Tick hinzu oder subtrahiert einen. Die Anpassung ist nur einmal pro Zyklus sichtbar, was abrupt wirken kann.

Abbildung 5. Software-seitige Timing-Korrektur

Vorteil: Funktioniert mit jedem RTC. Nachteil: Auffällige Sprünge in der Taktrate.

Sicherheitsaspekte

In Anwendungen, wo Zeit an Abrechnung, Nutzungslimits oder kritische Sequenzierung gekoppelt ist, ist der Schutz des RTC vor Manipulation essenziell. Viele Mikrocontroller bieten:

• schreibgeschützte Register, die per Software dauerhaft gesperrt werden können
• Hardware-Reset-Anforderung zum Ändern der Zeit (ein vollständiger Reset löscht die Sperre)
• Gehäuse-Einbruchsdetektion, um physisches Manipulieren zu melden

Beispiel: Der in diesem Artikel verwendete MCU hat ein Lock-Bit, das einmal gesetzt nicht mehr gelöscht werden kann, bis der Chip resetet wird – verhindert, dass Schadcode die Uhr verändert.

Zeit und Datum verwalten

Manche RTCs integrieren volle Time-of-Day- und Kalenderzähler. Fehlen diese in der Hardware, kann die Firmware das Datum vom 32-Bit-Sekunden-Zähler mittels Standardalgorithmen ableiten. Die C-Standardbibliothek time.h erwartet eine Funktion, die Sekunden seit der Epoche (meist 1. Jan 1970) zurückgibt. Ein einfacher get_time()-Wrapper, der den RTC-Zähler liest, füttert die Bibliothek, die dann Schaltjahre, Sommerzeit und Formatierung handhabt.

Limitierungen 32-Bit-Sekunden-Zähler

Ein 32-Bit-Zähler läuft nach 2³² Sekunden über – knapp über 136 Jahre. Startet die Epoche 1970, rollt der Zähler 2038 über (das Y2038-Problem). Systeme, die auf der C-Bibliothek basieren, können undefiniertes Verhalten zeigen, wenn der Zähler 2³¹ – 1 erreicht.

NASAs Deep Impact Mission verlor 2013 die Kommunikation, nachdem ein 32-Bit-Timer, der Zeit in 0,1-Sekunden-Inkrementen verfolgte, überlief und potenziell Steuerbefehle korrumpierte.

„Obwohl die genaue Ursache des Verlusts nicht bekannt ist, hat die Analyse ein potenzielles Problem mit Computer-Zeitmarkierung aufgedeckt, das zu Kontrollverlust für Deep Impacts Orientierung geführt haben könnte.“

— NASA News Release, 2013

Designer sollten Zähler nutzen, die die erwartete Systemlebensdauer bequem übertreffen, oder Rollover-Handling in Firmware implementieren.

Nächste Schritte

Der finale Artikel dieser Serie wird Watchdog-Timer abdecken, das Sicherheitsnetz, das einen Mikrocontroller am Leben hält, selbst wenn Software hängen bleibt.