Controller auf RTC synchronisieren

Thorsten Wahn schrieb:

Hallo,

wenn zwei verschiedene Quarzuhren vorhanden sind, dann laufen die natürlich auch auseinander. Beide laufen aber auch von der gesetzlichen Uhrzeit weg. Wenn die Zeit nicht springen soll musst Du eben alles von einem einzigen Quarz ableiten. Wenn Du eine RTC verwendest die auch einen externen Takteingang benutzen kann, dann könntest Du ja alles von einem Quarz durch Teiler ableiten, den Takt für die RTC, den Takt für den Timerinterrupt des Prozessors und evtl. sogar den Prozessortakt. Das wird aber schwierig wenn die RTC z.B.

32768 kHz benötigt und der Prozessor 20 MHz, dann wird sogar eine PLL nötig sein. Der Controller kann hoffentlich auch einen externen Takt.

Wenn diese Zeit dann auch einigermassen genau sein soll müsstes es ein gut abgeglichener Quarz sein mit Temperaturkompensation oder sogar mit Ofen.

Bye

Uwe Hercksen schrieb:

Das Problem ist, dass die RTC bei Netzausfall weiterlaufen soll. Und das m=F6glichst mit den nur wenigen Mikroampere Stromaufnahme, welche die RTC laut Datenblatt bietet.

Gru=DF Thorsten

"Thorsten Wahn" schrieb im Newsbeitrag news: snipped-for-privacy@b79g2000hse.googlegroups.com...

Du hast kein Hardware-Problem, du hast ein Software-Problem.

Selbst wenn die Uhr beim Einlesen gerade springt, ist das kein Problem, wenn die Einleseroutine richtig geschrieben ist. Entweder sie haelt die Uhr an, oder sie liest so lang zwei mal, bis beide Zeiten gleich sind.

Auch kontinuierliche Synchronisation im Sekundentakt ist kein Problem, entweder die RTC liefert sekuendlich einen Interrupt, oder du berechnest jede Minute, wieviele Counts deine Sekundenzeitschleife zaehlen soll, damit die Differenz zwischen

60 Sekunden und einer Minute in der naechsten Minute ausgeglichen wird.

Also: Weil das per Software problemlos loesbar ist, macht das niemand in Hardware.

Alternative: Ein uC, der sowieso schon auf Uhrenquartz laeuft, wie MSP430.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Thorsten Wahn schrieb:

Ich kenne mich mit PLLs zwar nicht aus aber eigentlich wäre es doch das Mittel der Wahl, den µC per PLL aus den 32kHz oder den 100Hz mit seinem Takt zu versorgen. Das sollte bei ordentlicher Auslegung bei Netzausfall auch keinen zusätzlichen Strom brauchen. Nach jedem Reset die Uhr auslesen und den µC danach stellen. Es gibt auch µCs mit integrierter PLL. Ob die aber mit so niedrigen Frequenzen funktionieren, kann ich nicht sagen.

Was meinst Du eigentlich mit Uhrkorrekturwert?

Und welche RTC mit welchem Controller benutzt Du eigentlich?

Michael

Über diese Synchronisierung haben sich schon einige Leute erfolgreich Gedanken gemacht. Das Ergebnis ist im ntp (Network Time Protocol) bzw. der zugehörigen Software ntpd (ntp daemon) zu finden. Diese Verfahren kann man auch auf die Timer von Microcontrollern anwenden.

Wenn ich so etwas selbst stricken müsste, würde ich den RTC so konfigurieren, dass er dem µC regelmäßig Interrupt-Pulse liefert, z.B. jede Sekunde einen. In der Interrupt-Service-Routine würde dann der jeweils aktuelle Timer-Stand in einem Zwischenspeicher abgelegt. Der kann dann (im Hauptprogramm) gemütlich ausgewertet werden. Zum Beispiel kann aus der Differenz des aktuellen Wertes und dessen aus der vorherigen Sekunde (oder von vor zehn Sekunden, je nach Abweichung der Zeitbasen) die Gangabweichung ermittelt werden. Die wiederum kann man verwenden, um zu errechnen, alle wieviel Sekunden der Timer einen um eins höheren oder niedrigeren Startwert bekommen muss, um über einen gewissen Zeitraum gemittelt die Abweichung auszugleichen.

Grüße,

Günther

MaWin schrieb:

Wenn sich mein Problem mit Software l=F6sen l=E4sst, w=E4re mir das nat=FCrlich am liebsten. :-)

Dazu m=FCsste ich die RTC sek=FCndlich einlesen, und das wohl im Timerinterrupt, da ich sonst nicht jitterfrei auf eine "Zeitflanke" synchronisieren kann. Den Timerinterrupt will ich aber m=F6glichst freihalten von l=E4ngeren Routinen: die RTC wird via I2C angesprochen, das Auslesen des Sekundentimers w=FCrde etwa eine halbe Millisekunde dauern, was bei einem 1ms-Timerinterrupt nicht so dolle ist...

Die RTC ist tats=E4chlich so programmierbar, dass sie einen Alarm- interrupt nach einer Sekunde ausgibt. Der Haken: Ich muss diesen nach Ausl=F6sung erneut programmieren. Also doch wieder sek=FCndlich auf das Teil zugreifen - was ich aus den o.g. Gr=FCnden nicht will.

Ich hatte schon mal nach einer RTC gesucht, welche in der Lage ist, nach einmaliger Initialisierung einen sek=FCndlichen Alarm auszugeben - bisher allerdings ohne Erfolg.

Gru=DF Thorsten

Er meint sicher eine RTC mit einem Korrekturregister die es erlaubt Frequenzfehler des Oszillators wegzukalibrieren. Normal haben die dazu einen Pin wo der geteilte Oszillatortakt rauskommt. Den misst man mit einem Frequenzzaehler, berechnet nach Datasheet den Korrekturwert und schreibt ihn dann in dieses Register. So kriegt man eine korrekte Uhrzeit ohne den Oszillator tunen zu muessen. Der Vorteil ist, dass diese Aktion per Software durchgefuehrt werden kann.

Micha

G=FCnther Dietrich schrieb:

Das geht prinzipiell, =FCber einen Alarmtimer im RTC, nur dass dieser nach jedem Interrupt erneut aktiviert werden muss, was einen Zugriff auf den RTC erfordert (...im Timerinterrupt via I2C, was ich f=FCr problematisch halte). Die RTC kann zwar auch einen laufenden Rechteck mit programmierbarer Frequenz ausgeben, der h=E4ngt jedoch nicht vom Uhrkorrekturwert der RTC ab - und die RTC wird nat=FCrlich f=FCr beste Gangenauigkeit mit einem Korrekturwert kalibriert.

Es kristallisiert sich f=FCr mich nun immer mehr heraus, dass ich eine RTC brauche, welche einen Sekundentakt ausgeben kann, der aber vom Uhrkorrekturwert abh=E4ngt.

Gru=DF Thorsten

MaWin schrieb: [Auseinanderlaufen von zwei Quarzzeitbasen]

Sicher? Er könnte doch den Quarz um die 11ppm ziehen. Drehkondensator dran und anpassen. Klar kann er mehrfach auslesen. Er könnte auch einen Korrekturfaktor messen und die Zählschleife seiner Softwareuhr anpassen.

Nun könnte es aber doch noch ein Hardwareproblem sein. Wir hatten hier auch mal einen RTC auf einem PC-Mainboard der beim Auslesen einen Zählimpuls verlieren konnte. :-(

Gruß Gunther

Thorsten Wahn schrieb:

Der RTC58321 von Epson kann das:

1024Hz, 1Hz, 1 pro Minute, 1 pro Stunde. Gleichzeitid an 4 versch. Pins. Ist aber längst veraltet. Evtl. können das noch weitere Chips von Seiko / Epson?

Gruß, Martin

"Thorsten Wahn" schrieb im Newsbeitrag news: snipped-for-privacy@57g2000hsv.googlegroups.com...

Brauchst du auch nicht. Die Zeit, wenn der uC laueft, ist die Zeit, die der uC intern mitzaehlt. Die externe Zeit aus der RTC wird nie verwendet, nur zur Synchronisation.

Wann auch immer du synchronisieren willst (sekuendlich, minuetlich, tageweise) guckst du mal auf deine RTC. Es ergibt sich, wie viele uC-Timercounts du inzwisxchen daneben liegt. Dann musst du fuer die naechste Zeit (Minute, oder Tag) eben so viel weniger uC-Timercounts ansetzen, also die Konstanten, mit denen deine interne Uhr laeuft, aendern. Du aenderst aber nie die Zeit, es wird immer die genommen, die der uC selber mitzaehlt.

z.B. DS12(8)87 (mit Batterie) PCF8573 (ohne Batterie)

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Martin Siegwarth schrieb:

Dieser Ausgang wird aber direkt aus dem Oszillator durch Teilung abgeleitet. Der RTC, den ich verwende (M41T81) hat ein Register "Calibation", der eine Uhrzeitkorrektur durchf=FChrt. Was ich ben=F6tigen w=FCrde, w=E4re also eine RTC, welche einen 1s-Alarm ausgeben kann, der von diesem Kalibrierwert abh=E4ngig ist und nicht (wie beim M41T81) eine st=E4ndig erneute Programmierung des Alarms erfordert.

Gru=DF Thorsten

Thorsten Wahn schrieb:

Hallo,

oder Du liest die RTC nur einmal beim Starten des Controllers ein und machst dann wenn der Controller läuft alles im Controller selbst per Timer Interrupr, ohne die RTC zu behelligen.

Bye

Klar, dann kommt aber nächste Woche die Frage: "ich stehe vor dem Problem, dass bei einem Microcontrollersystem die Uhrzeit der (externen) RTC und die Uhrzeit des Controllers (per Software erzeugt) ständig auseinanderlaufen. Das macht in der Woche zwar nicht mehr als vielleicht 1 Sekunde aus, ist aber dennoch ärgerlich."

Nicht messen, sondern messen lassen. Und zwar durch seine eigene Software. Hint: Der Korrekturfaktor ändert sich vermutlich auch mit dem Alter, der Jahreszeit, etc.

Bernd

MaWin schrieb:

(=2E..)

Die RTC hat eine genauere Zeit als der uC, schon wegen der Kalibrierung (Uhrkorrekturwert). Daher m=F6chte ich nicht den uC als Zeitbasis laufen lassen.

Ja, stimmt eigentlich.

Genau betrachtet k=F6nnte ich es dann ja auch gleich richtig machen, ich muss die Abweichung garnicht gro=DF errechnen, um diese zu korrigieren:

Ich synchronisiere einen 1s-Softwaretimer im Controller zun=E4chst auf den (unkalibrierten) 1Hz-Takt der RTC. Diesen Timer darf ich jedoch nicht f=FCr die Zeiterzeugung des Controllers verwenden sondern muss einen zweiten 1Hz-Timer im Controller generieren, dessen Phase um den gleichen zeitlichen Betrag geschoben wird, der auch in der RTC mittels Uhrkalibrierwert zur Anwendung kommt, um dort die korrigierte Zeit zu erzeugen.

Voila, k=F6nnte doch funktionieren!

Danke an alle f=FCr die Antworten und Anregungen. Und Dank an MaWin im speziellen f=FCr seinen Gedankenansto=DF, der mich zu dieser L=F6sung f=FChrte.

Gru=DF Thorsten

Moin!

Machs wie die Bahnhofsuhr: Jede Minute bei der 59. Sekunde wird die Uhr angehalten und auf den volle-Minuten-Puls gewartet. Solange die interne Uhr in diesem Zeitraum nicht mehr als +-1s falsch geht (Dir reicht also vermutlich auch stündliche Synchronisation), kann zwar bei Synchronisation mal eine Sekunde etwas kürzer oder länger "dauern", aber es wird nie eine über- oder zurückgesprungen.

Gruß, Michael.

"Thorsten Wahn":

Inwiefern muss denn das "Bestellen" des Alarms in einer hochfrequenten IRQ-service-Routine ablaufen?

Hast Du nicht im Hauptprogramm eh' irgendsowas wie 'ne "Wartungsfunktion", die hin und wieder mal drankommt?

Gruss

Jan Bruns

Mach es doch genau umgekehrt: Synchronisiere die RTC auf den MC

Nach einem Reset/Wiedereinschalten liest der Microcontroller die Zeit aus der RTC aus. Während das Programm läuft, wird die Zeit über den Quarztakt des Microcontrollers errechnet. Das geht mit derselben Genauigkeit, wie die des 32Khz Taktes.

Wenn RTC und Microcontroller auseinandergelaufen sind, z.B. um 1 Sekunde, dann wird der RTC korrigiert und nicht der Microcontroller.

Damit vermeidest du jegliche Sprünge in der Uhrzeit deines MC und hast im Falle eines Stromausfalls eine Korrektur über die RTC.

Gruß

Stefan DF9BI

Sie haben halt verschiedene Zeitbasen und _beide_ gehen falsch. Die eine mehr, die andere weniger.

Keine sehr sinnvolle Idee.

Die Grundfrage jeder Synchronisation ist: Wer ist master und wer slave. Sinn macht sie nur, wenn die genauere Zeitbasis als Master dient.

Wenn ich lese, daß die RTC einen "Zeitkorrekturwert" hat und dessen Einstellung keinen Einfluß auf den (heruntergeteilten) Takt hat, bedeutet das ja wohl, daß der Korrekturwert keinen direkten Einfluß auf die Zeitbasis nimmt, diese also immer "nach dem Mond läuft" und nur die heruntergeteilte "Nutzzeit" (mit dem für das Verfahren typischen Jitter) zyklisch nachkorrigiert wird. Billichdreck vom Feinsten also.

Es wäre kompletter Wahnsinn, sich damit synchronisieren zu wollen. Ergo: Dein µC-System muß der master werden. Sprich: nutze freie Rechenzeit deines µC, um die RTC entsprechend deiner Systemzeit nachzujustieren. Falls sehr viel freie Rechenzeit da ist, würde man natürlich die Synchronisationsfrequenz auf sinnvolle Werte begrenzen. Wenn die RTC z.B. maximal Sekundenauflösung liefert und die typische Zeitdifferenz zu deiner Systemzeit bei 1s/d liegt, reicht es völlig aus, das Teil drei oder viermal am Tag zu synchronisieren. Es schadet aber natürlich auch nicht, dies öfter zu tuen.