Was ich immer schon mal wissen wollte. Wenn man beispielweise mit der DS3231 eine Uhr baut, wie geht man da generell mit dem Abgleich um? Wie oft liest man die Uhr aus, wenn man bespielsweise einen Atmega mit dem internen RC Oszillator laufen hat...? Man programmiert sich ja eine Uhr auf dem Atmega und synchronisiert die dann mit der rtc, oder? Wäre ja blöd wenn man das beispielweise alle 24h macht, die Uhr dann aber mehrere Minuten springt ... Man soll die Dinger ja auch nicht zu häufig auslesen...
Thorsten S. schrieb: > Man soll die Dinger ja auch nicht zu häufig auslesen... Aha... Was sagt denn das Datenblatt zu der Behauptung?
> Wie oft liest man die Uhr aus, wenn man bespielsweise einen > Atmega mit dem internen RC Oszillator laufen hat...? Nun - rechnen! Im günstigen Fall hat man damit 3 % Abweichung, ist eine Genauigkeit von 1 Sekunde verlangt, muss folglich die RTC jede halbe Minute ausgelesen werden. PS: Der DS3231 hat ja einen 32 KiHz-Ausgang - diesen als Interrupt für den ATmega zu verwenden könnte sinnvoll sein ...
:
Bearbeitet durch User
Es gibt/gab mal RTCs die man nicht so oft auslesen sollte, weil es da zu Zählfehlern kommen konnte. Das ist m.W. aber vorbei, seit die I²C sprechen. Man muss aber dennoch auf die Reihenfolge und den Zeitpunkt des auslesens der Register achten, damit es nicht dazu kommt das man über einen Minuten-/Stunden-/Tagessprung ausliest. Zum anderen haben viele einen Ausgang, der einen Takt abgeben kann, teilweise z.B. feste 32768kHz, teilweise auch programmierbar, z.B. auf 1Hz. Den kann man an einen Pin des Controllers andocken und dann dort entsprechend benutzen, dann ist der Takt des Controllers reichlich egal. Ja, technisch gesehen sind die Takte asynchron und daher kommt es zu winzigen Sprüngen in der Dauer z.B. einer Sekunde, aber für menschliche Wahrnehmung ist das genau. Damit kann man dann selber Sekunden zählen und nur einmal pro Minute die Uhr abfragen, oder eben auch "immer nach dem Signal" die RTC komplett auslesen. Oder drittens man rechnet aus wie lange der Controller braucht um mit seinem Takt 1/2 LSB Abweichung zu bauen und liest immer in diesem Intervall. Die programmiertechnisch einfachste Lösung dürfte die zweite sein: - Warte auf 1PPS-Signal - Lies die RTC - Bring das auf's Display - wieder von vorne. Wenn die Schaltung noch anderen Kram machen muss, sollte man probieren das in den 4. Schritt zu packen.
Moin, vielleicht ist es einfacher dem Atmega einen Quarz oder Oszillator zu gönnen. Der würde die Urzeit im Atmega oder Attiny gleich genau erzeugen können und der Aufwand ist geringer. Nur eine freier Timer muss vorhanden sein Gruß Carsten
Carsten-Peter C. schrieb: > Der würde die Urzeit im Atmega oder Attiny Die gab es zu Urzeiten noch nicht ;-) Da stapften noch die Dinosaurier rum.
Rainer W. schrieb: > Carsten-Peter C. schrieb: >> Der würde die Urzeit im Atmega oder Attiny > > Die gab es zu Urzeiten noch nicht ;-) > Da stapften noch die Dinosaurier rum. Ach wo, das ist UTC+3. https://de.wikipedia.org/wiki/Ur_(Stadt)
Rainer W. schrieb: > Da stapften noch die Dinosaurier rum. Und mangels genauer Zeitangabe zum Date sind die Dinos ausgestorben. mfg
Thorsten S. schrieb: > Wäre ja blöd wenn man das beispielweise alle 24h macht, die Uhr dann > aber mehrere Minuten springt ... Dann hat man blöd programmiert. Nach den ersten 24h kann das vielleicht passieren, aber daraus sollte der ATmega lernen, den Fehler seines RC-Oszillators bestimmen und den Gang seiner Software-Uhr immer entsprechend korrigieren, so dass es nicht wieder zu so großen Abweichungen kommt.
:
Bearbeitet durch User
Thorsten S. schrieb: > mehrere Minuten springt ... lass sie doch springen.
1 | //------------------- smh timer ------------------
|
2 | if (timer_smh>99) |
3 | {
|
4 | sec=sec+timer_smh/100; |
5 | timer_smh=timer_smh%100; |
6 | if(sec>59){ |
7 | sec=sec-60; min=min+1; |
8 | lcd_goto(2,4);// |
9 | lcd_int2(min);// |
10 | lcd_write(":"); |
11 | if(min==60){ |
12 | min=0; hou++; |
13 | if(hou==24) |
14 | {
|
15 | hou=0; |
16 | if(sperre_rtc==0) |
17 | {
|
18 | kk_ds1307_getAll_to_global_struct_zt(); |
19 | sub_sommerzeit(); |
20 | sperre_rtc=1; |
21 | sub_day_start(); |
22 | }
|
23 | }
|
24 | if(hou==2)sperre_rtc=0; |
25 | lcd_goto(2,1);// |
26 | lcd_int2(hou);// |
27 | lcd_write(":"); |
28 | }
|
29 | }
|
30 | lcd_goto(2,7);// |
31 | lcd_int2(sec);// |
32 | // led1_tog;
|
Für die meisten Anwendungen ist das egal. Mehr Genauigkeit erfordert halt mehr Aufwand.
Christian S. schrieb: > Rainer W. schrieb: >> Da stapften noch die Dinosaurier rum. > > Und mangels genauer Zeitangabe zum Date sind die Dinos ausgestorben. Die sind doch bei einem Flugzeugunglück... https://de.wikipedia.org/wiki/De_Havilland_DH.106_Comet
Rainer W. schrieb: > Dann hat man blöd programmiert. Nach den ersten 24h kann das vielleicht > passieren, aber daraus sollte der ATmega lernen, den Fehler seines > RC-Oszillators bestimmen und den Gang seiner Software-Uhr immer > entsprechend korrigieren, Blöderweise arbeitet der RC Oszillator Temperatur- und Betriebsspannungsabhängig. Es sieht einfach doof aus, wenn die Anzeige nicht gleichmässig im Sekundentakt springt. Ob man dazu die RTC 20 x pro Sekunde ausliest, oder eine PLL nur 1 x am Tag synchronisiert, bleibt dem Programmierer überlassen.
Michael B. schrieb: > Blöderweise arbeitet der RC Oszillator Temperatur- und > Betriebsspannungsabhängig. Wenn man schon einen RC Oszillator als Zeitbasis für eine Uhr verwenden will, tut man das tunlichst nur bei halbwegs stabilen Bedingungen. Solange das Ding unter Wohnraumbedingungen betrieben wird, ist der Mittelwert über 24h recht stabil. Wenn das dem Anwender nicht reicht, muss er eben öfter bei der RTC nachfragen oder direkt die RTC für die Zeit in der Anwendung nutzen. Es ging um die Kalibrierung des RC-Oszillator gegen die RTC. Im Endeffekt ist das eine PLL mit einer Referenzfrequenz entsprechend dem RTC-Abfragetakt. > Es sieht einfach doof aus, wenn die Anzeige nicht gleichmässig im > Sekundentakt springt. Entweder überschätzt du maßlos dein absolutes Zeitgefühl oder die Instabilität eines RC-Oszillators. Wie oft hast du auf einer Uhr schon eine Schaltsekunde gesehen? Das dürfte so ziemlich die größtmögliche Ungleichmäßigkeit im Ablauf einer Minute auf einer Uhr sein. p.s. Adjektive schreibt man klein ...
:
Bearbeitet durch User
Es gibt ja ATMega mit Timer2, auch mit clock Pins. Dort kann man einen 32768Hz Quartz anhaengen. die gibt es fuer wenig Geld mit erhoehter Genauigkeit, zB mit 10 ppm anstelle von 100ppm. Wenn man in dessen Inerrupt eine Uhr zaehlen laesst muss man diese Uhr eigentlich nur beim Powerup einmal vom RTC laden.
Manchmal glaube ich es gibt hir einen versteckten Rube-Goldberg-Wettbewerb...
Dafür müsste die Anzeige aber mechanisch sein (hatten wir das nicht gerade?) und man braucht noch einen Thermostat für den 10ppm-Uhrenquarz am AVR. Am besten mit Kohle beheizt, Gas wäre ja zu einfach. Das kostet dann zwei Förderbänder und einen Ozongenerator oder was hilft gegen statische Aufladung?
Nein, dazu muss es nur nutzlos kompliziert gemacht werden. Gewinnen kann man damit nix, aber der TO auch nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.