Ich nutze in solchen Fällen in zwei Zeiteinheiten. Der Prozesstakt wird für die interne Ablaufsteuerung usw. benutzt, die Uhrzeit für Logging usw. Damit hat man nie das Problem, dass der Prozesstakt spring - Uhrzeit stellen, Sommer/Winterzeit usw. - und die Uhrzeit kann nach belieben an bestimmte Zeitzonen usw. angepasst werden, ohne dass es die interne Verarbeitung stört.
-- Stefan Graf
Thorsten Wahn schrieb:
Was Du hier vor Dir hast, ist ein typisches PLL-Problem: Du möchtest den
1s-Takt deines Microcontrollers auf den 1s-Takt deiner RTC phasenlocken.Dafür baust Du am einfachsten eine Regelschleife auf, die den Takt deiner µC-Uhr an den der RTC anpasst. Da die beiden Uhren fast gleich gehen, sind die Anforderungen an die Regelbandbreite gering: Es reicht, wenn Du nur alle paar Minuten oder Stunden nachregelst.
Der Trick ist, daß Du beim Microcontroller nicht die Zeit nachstellst (was der Phase entsprechen würde) sondern die Frequenz: Du kuckst nach, ob der Microcontroller vorgeht, und wenn das so ist, drehst Du ihn langsamer (änderst z.B. Deine Timerinterruptfrequenz ein wenig) und umgekehrt. Dadurch, daß Du nur die Frequenz änderst, hast Du nie Zeitsprünge (Phasensprünge) in Deiner µC-Uhr.
Wie weit Du deinen Zeittakt änderst, ist ein normales Regelproblem: Wenn die Änderung zu groß ist, pendelt die µC-Zeit um die RTC zeit herum und die Schleifenverstärkung deines Reglers ist zu groß: Die Regelung schwingt. Wenn Du zu wenig änderst, dauert es lange, bis RTC und µC synchron sind. Da die Abweichungen aber sowieso klein sind, benötigst Du aber wohl nicht den perfekten PLL-Schleifenfilter.
Den Alarmausgang & Interrupt der RTC, den Du erwähnt hast, kannst Du perfekt dafür benutzen: Immer wenn er auslöst, machst Du den Uhrenvergleich und setzt den nächsten Alarm.
Gruß, Jürgen
-- GPG key: http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get
Ein smoothe Synchronsiation möglichst weit unten/hoch aufgelöst am Timer interrupt/hochfrequenten Zähler machst Du am einfachsten in dem Du einen Korrekturzähler aufsummierst und entsprechend +-1 korrigierst. es reicht, den Gangunterschied speedcorr/timeoffset sehr langsam (z.B. nur stündlich/täglich) .
z.B. Prinzip (recht unoptimiert):
long ms_time; long sec_time;
// 1h Updated: float timeoffset=5.0; // 5 Sek. Nachgehend float speedcorr=1.00001-1.0; // und Uhr läuft 0.001% zu langsam // Calced: long speedcorr_int=(speedcorr+timeoffset/3600.0)*1000000.0; // =>holt Gangunterschied binnen 1h auf und perm. Korrektur:
long sum_corr=0; void interrupt approx_1ms_interrupt(void) { if ( (sum_corr+=speedcorr_int) > 1000000 ) { ms_time+=2; sum_corr-=1000000; else if ( (sum_corr+=speedcorr_int) < 1000000 ) //ms_time+=0; sum_corr+=1000000; else ms_time++; ... }
Grüsse Robert
else if ( (sum_corr+=speedcorr_int) < -1000000 ) // :-) können noch weitere Fehler da sein...
Wozu denn das?
Du mußt nur in regelmäßigen Abständen eine Abgleich zwischen RTC- und uC-Uhr ausführen, und dann den Teilerfaktor im uC leicht anpassen - das kannst Du problemlos mit einem uC-Timer anstoßen, und je nachdem, wie stark die 2 Uhren auseinanderdriften, reicht es, wenn das alle paar Minuten bis Stunden passiert.
cu Michael
-- Some people have no respect of age unless it is bottled.
J=FCrgen Appel schrieb:
er
Ich muss aus verschiedenen Gr=FCnden die I2C-Kommunikation mit dem RTC- Baustein minimieren. Da der Alarm-Interrupt aber stets eine Best=E4tigung (via I2C) erfordert, habe ich diesen nicht weiter in Erw=E4gung gezogen. Ich werde wie in
Gru=DF Thorsten
Heiko Nocon schrieb:
So ist es. Die RTC wird =FCber einen Korrekturwert kalibriert, liegt damit innerhalb der Spezifikation und ist deutlich genauer als der Controller. Daher liegt es f=FCr mich nahe, die RTC als "Zeitquelle" zu benutzen.
Das ist ein Missverst=E4ndnis. Die Uhrzeit wird selbstverst=E4ndlich vom RTC-Kalibrierwert korrigiert. Die RTC verf=FCgt dar=FCberhinaus =FCber einen freilaufenden Rechteckgenerator mit einstellbarem Vorteiler, der jedoch nicht vom RTC-Kalibrierwert korrigiert wird.
In der L=F6sung, die ich jetzt versuche zu implementieren, synchronisiere ich einen Software-Timer im Controller genau darauf. Der eigentliche 1s-Timer im Controller wird dann aber - wie dies auch in der RTC geschieht - mit einem sich aufsummierenden Zeitversatz, der vom RTC-Kalibrierwert vorgegeben wird, daran angebunden.
Gru=DF Thorsten
Vielen Dank f=FCr die zahlreichen Antworten. Ich werde eine L=F6sung wie in
Gr=FC=DFe Thorsten
Thorsten Wahn schrieb:
Naja, wenn einmal alle >20 Minuten schon zuviel ist, kommt der Alarm wohl nicht in Frage...
Gruß, Jürgen
-- GPG key: http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get
J=FCrgen Appel schrieb:
Naja, die Frage, die sich mir stellte, war: Wie kann ich eine hinreichende Uhrensynchronisation erzielen bei u.a. minimalem Zugriff auf den I2C-Bus der RTC. Meine bevorzugte L=F6sung ist f=FCr diesen Fall optimiert, was aber keine Abwertung anderer L=F6sungskonzepte darstellt.
Gru=DF Thorsten
Es gibt auch kaum einen Grund so häufig zu synchronisieren. Selbst die 1 Sekunde Abweichung pro Tag ist wiederum ziemlich konstant - v.a. wenn CPU- und RTC-Quartz etwa derselben Temperatur ausgesetzt sind. Wenn also die Sync-Regelung im Normalbetrieb einfach die unterschiedliche Laufgeschwindigkeit erfasst (und etwa im EEP dauerhafter speichert) sowie den aktuellen Gangunterschied langsam aufholt, reicht es erfahrungsgemäß sogar aus (nach initialem Sync
1&2) 1x pro Woche erneut zu sync'en sofern denn das Gerät solange am Stück ON ist. Ist auch kein Problem das bruchlos in den hochaufgelösten Tick-Count reinzurechnen - sogar einfacher und eleganter als eckige Lösungen mit mehreren Zeitbasen, Duplizierung der RTC-internen Korrektur, um Mitternacht Geistersekunden einlegen etc. Dann hat man eine einheitlich Zeitbasis. Vgl. auch Windows' SetSystemTimeAdjustment:Grüsse Robert
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.