Wie oft sollte ich eine RTC abfragen?

11

Ich habe noch keine RTC verwendet, daher bin ich mir nicht ganz sicher, wie "normal" eine Echtzeituhr gelesen werden kann. Es gibt ein paar verschiedene Ansätze, an die ich gedacht habe, aber ich habe auf Ratschläge gehofft.

Hier sind die Möglichkeiten, wie ich bisher daran gedacht habe, die Zeit zu lesen und zu nutzen:

Holen Sie sich das Datum und die Uhrzeit beim Einschalten und speichern Sie sie im RAM. Inkrementieren Sie dann mithilfe des Timer-Interrupts die RAM-Werte jede Sekunde usw. Der Code verwendet dann die Werte im RAM, wann immer Datum und Uhrzeit bekannt sein müssen.
Fragen Sie mithilfe eines Timer-Interrupts jede Sekunde die RTC ab und kopieren Sie das empfangene Datum und die empfangene Uhrzeit in den RAM. Wiederum würde der Code dann die Werte im RAM verwenden, wann immer er das Datum / die Uhrzeit kennen musste.
Jedes Mal, wenn ich die Zeit herausfinden muss, frage ich die RTC ab und verwende ihre Antwort direkt.

Welches wäre der beste Ansatz?

microcontroller rtc

— user9993
quelle

15

Der beste Ansatz ist der, der Ihren Spezifikationen bei minimalem Ressourceneinsatz entspricht. Da wir Ihre Bedürfnisse nicht wirklich kennen, hat "best" für uns nur eine sehr geringe Bedeutung.

— Scott Seidman

Alle sehr guten Antworten Ich kann keine Antwort auswählen!

— user9993

23

Ich würde eine vierte Option verwenden.

Die meisten RTC-Chips haben die Möglichkeit, einen 1-Sekunden-Impuls auszugeben. Sie sollten diesen Impuls an einen Interrupt-fähigen Eingang Ihrer MCU anschließen.

Sie erhalten die Zeit vom Chip einmal zu Beginn Ihres Programms und vielleicht gelegentlich von da an - vielleicht einmal pro Stunde.
Das Interrupt-Signal löst dann eine Interrupt-Routine in Ihrer MCU aus, in der Sie die Zeit um eine Sekunde erhöhen.

Diese Anordnung gibt Ihnen die Genauigkeit auf die Sekunde der RTC, ohne den Aufwand, die RTC aktiv zu lesen.

— Majenko
quelle

5

Bei Verwendung dieses Ansatzes ist es wichtig zu wissen, welche Taktflanke ein Inkrement darstellt, und sicherzustellen, dass alle während dieser Taktflanke laufenden Lesevorgänge abgebrochen werden.

— Supercat

Oder stellen Sie sicher, dass der Messwert nur vom ISR ausgelöst wird. Sie erhalten eine Sekunde Zeit, um den Messwert auszuführen, bevor der nächste ISR ausgelöst wird.

— Majenko

Wann immer möglich, ziehe ich es vor, Echtzeituhren so einzustellen, dass sie schneller als ein Tick pro Sekunde laufen, und sie für das allgemeine Ereignis-Timing zu verwenden, wenn die RTC-Auflösung fein genug eingestellt werden kann, um den Anforderungen des Ereignis-Timings zu entsprechen. Es kann daher sein, dass nicht immer bei jedem RTC-Tick ein Interrupt auftritt. Außerdem ist es beim Einstellen von Alarmen oft wichtig, genau zu wissen, wie hoch die RTC-Zeit zum Zeitpunkt der Alarmeinstellung ist, und die RTC abzufragen, um festzustellen, ob sie sich bewegt hat, während der Alarm eingestellt wurde. Ich weiß nicht, warum 32-Bit-Chip-Anbieter nicht einfach einen 47-Bit-Zähler mit der Fähigkeit zum Lesen

— anbieten

... die oberen 32 Bits oder die unteren 31 Bits plus der Takteingangszustand einen Alarm haben, der jederzeit ohne Synchronisationsverzögerung ein- und ausgeschaltet werden kann, und ein Alarmregister, das jederzeit geschrieben werden kann, wenn der Alarm vorliegt Aus, mit der Semantik, dass der Alarm auftritt, wenn ein Inkrement auftritt, während der Alarm aktiviert ist . Wenn ein Chip asynchrone Aufweckvorgänge akzeptieren kann und die Software gegebenenfalls die Abfrage überprüft, ist keine andere Hardwaresynchronisierung erforderlich, und die Software müsste keine Probleme umgehen, die durch andere Formen der Hardwaresynchronisierung verursacht werden.

— Supercat

9

3. und 2. sind rentabler.

Der dritte Ansatz ist der, den ich in den meisten Fällen verwende. Der Vorteil ist, dass ich mir keine Gedanken über das Spiegeln der RTC im RAM machen muss. Ein möglicher Nachteil besteht darin, dass das Abfragen der RTC über den seriellen Bus zu einer Verzögerung führt. Wenn Sie einmal pro Sekunde Daten schreiben, spielt diese Verzögerung wahrscheinlich keine Rolle.

2. Ansatz ist auch gut. Die Wartung einer Spiegeluhr kann zu einem Zeitnehmungsfehler führen, wenn das Gerät längere Zeit läuft. Die Spiegeluhr kann von der RTC abweichen. Wenn Sie die RTC regelmäßig lesen, wird sich die Drift nicht ansammeln.
Ich würde jedoch davon abraten, serielle Kommunikation in der Interrupt Service Routine (ISR) selbst durchzuführen. Setzen Sie ein Flag im ISR und führen Sie die serielle Kommunikation im main () durch.

ps In allen Fällen habe ich DS1307 verwendet.

— Nick Alexeev
quelle

6

Einige RTCs (z. B. MC68HC68T1 [die zugegebenermaßen fast niemand mehr verwenden sollte]) unterbrechen ihre interne Zählung beim Lesen, um eine konsistente Antwort zu erhalten. Sie müssen so selten wie möglich gelesen werden, um Störungen zu minimieren. Lesen Sie einmal von ihnen und aktualisieren Sie dann den im RAM der MCU gespeicherten Zeitwert mithilfe von Timer-Interrupts.

— Ignacio Vazquez-Abrams
quelle

Solche Designs verwirren den Geist. Lesevorgänge, die während eines Inkrements auftreten, ergeben zufällige Daten, die leicht zu umgehen sind. Das Lesen führt dazu, dass Zählungen übersehen werden. Dies ist ein Problem, das nur umgangen werden kann, indem verlorene Zählungen akzeptiert werden.

— Supercat

2

Anscheinend denken manche Leute nicht an doppelte Pufferung, wenn sie ihre Chips entwerfen.

— Ignacio Vazquez-Abrams

Wenn der Code beim Abrufen überprüft, ob sich ein Wert nicht geändert hat, ist keine doppelte Pufferung erforderlich. Bei einer On-Chip-Echtzeituhr funktioniert eine solche Abfrage, bei der keine Änderungen vorgenommen werden, auch dann, wenn ein Interrupt versucht, die RTC gleichzeitig mit dem Hauptleitungscode zu lesen. Einige doppelt gepufferte Designs machen es schwierig, Hauptzeilen- und Interrupt-Code zu schreiben, der sicher nebeneinander existieren kann, und ich habe noch nie einen gesehen, den ich wirklich als "hilfreich" betrachten würde.

— Supercat

5

Ich gehe davon aus, dass die RTC entweder ein separater Chip mit einem eigenen Kristall oder ein in Ihren Mikrocontroller integriertes Modul ist, das wiederum eine separate Zeitquelle (z. B. einen 32-kHz-Kristall) als die Hauptuhr hat. Und die Zeitquelle für die RTC ist genauer als die für den Mikrocontroller.

Um festzustellen, wie oft Sie die RTC lesen müssen, müssen Sie herausfinden, welchen maximalen Fehler Ihre Hauptuhr haben kann. Wenn zum Beispiel der Hauptkristall mit 20 ppm spezifiziert ist, entspricht dies 0,002%. Eine Uhr, die nur auf der Hauptuhrquelle basiert, kann also 0,00002 * 3600 * 24 = 1,728 Sekunden pro Tag driften.

Wenn Sie also die RTC nur zweimal am Tag lesen und dazwischen die Zeit einmal pro Sekunde mithilfe eines Timer-Interrupts erhöhen, sind Sie nie länger als eine Sekunde ausgeschaltet - im Vergleich zur RTC also nie länger als eine Sekunde.

Wenn Ihre RTC, wie ich zuvor angenommen habe, entweder ein separater Chip mit eigenem Kristall oder ein in Ihren Mikrocontroller integriertes Modul ist, bedeutet dies nicht, dass sie korrekt ist. Eine RTC kann auch einen Fehler haben. Wenn beispielsweise ein 32-kHz-Kristall mit einer Toleranz von 5 ppm verwendet wird (die nur geringfügig teurer sind als 10 ppm), kann er um 0,43 Sekunden pro Tag oder 13 Sekunden pro Monat ausgeschaltet sein.

Um dies zu umgehen, müssen Sie die RTC einstellen, wobei Sie einen Korrekturfaktor in ein Register zurückschreiben. Auf diese Weise können Sie den Fehler praktisch auf Null bringen. Aber natürlich müssen Sie eine dritte externe Taktquelle haben, die Sie als Referenz für die Abstimmung verwenden können. Eine äußerst genaue Referenz in den USA ist die 60 - Hz - Wechselstromleitung, welches garantiert werden genau 60 * 60 * 60 * 24 (5.184.000) Zyklen in einem 24 - Stunden - Zeitraum zwischen aufeinanderfolgenden midnights. Damit dies nützlich ist, müssen Sie die gesamten 24 Stunden Zeit haben, da die 60 Hz zwischen den Mitternächten etwas abweichen können.

Eine weitere hervorragende Zeitreferenz wäre die Verwendung von GPS (10 ns Genauigkeit), wenn bereits GPS-Hardware in ihrem Projekt vorhanden wäre.

Wenn Ihre RTC-Zeiten stattdessen von einer externen Quelle stammen, z. B. der Mobilfunknetzzeit (AT + CCLK? Call), oder von einem Netzwerkzeitserver, der NTP verwendet, können Sie den RTC-Wert unverändert verwenden, da nichts zu "optimieren" ist. .

— tcrosley
quelle