Moin,
RTCs haben in den allermeisten (allen?) Fällen Kalenderfunktionen
eingebaut. Es werden also Sekunden, Minuten, Stunden, Tage, Wochen,
Monate und Jahre gezählt. Inklusive ist meist auch Unterstützung für
Schaltjahre. Das braucht alles mit Sicherheit einen guten Batzen Logik.
Warum ist das eigentlich so? Es wäre doch deutlich einfacher und
flexibler, einen einfachen Zähler zu implementieren, der bspw.
Millisekunden hochzählt.
Ich musste gerade wegen Rockchip daran denken:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f076ef44a44d02ed91543f820c14c2c7dff53716
Die haben sich doch tatsächlich, äh, verzählt?
Nun ja,
ich habe mir eine Uhr mit RV 8564-C2 gebaut. Der arbeitet
batteriegestützt und gibt mir beim Einschalten der Uhr alle nötigen
Daten incl. Schaltjahresberechnung. Was gibt es Einfacheres für unter
3EUR?
Gruß
Johannes
greg schrieb:> Es werden also Sekunden, Minuten, Stunden, Tage, Wochen,> Monate und Jahre gezählt. Inklusive ist meist auch Unterstützung für> Schaltjahre. Das braucht alles mit Sicherheit einen guten Batzen Logik.
Eben. Warum soll man sich diesen Batzen Logik antun, wenn einem der
Hersteller der RTC die Arbeit abnimmt? Kommt mir vor wie:
"Warum gibt es eigentlich Schrauben? Mann könnte doch Nägel nehmen und
sich bei Bedarf ein Gewinde rein schneiden"
Merke: Das Rad muss nicht jedes mal neu erfunden werden.
greg schrieb:> Warum ist das eigentlich so? Es wäre doch deutlich einfacher und> flexibler, einen einfachen Zähler zu implementieren, der bspw.> Millisekunden hochzählt.
Die RTC hat man im Normalfall dafür, wenn man ohne ausreichende
Stromversorgung (Batteriebetrieb) oder puffernd die Uhrzeit fortführen /
erhalten möchte. Kriterium ist also geringe möglichst langlebige
Stromversorgung. Das geht am besten wenn der Mikrocontroller so tief wie
möglich schläft und in stromsparender Hardware die Zeit fortgezählt
wird. Mit einem benutzergeschriebenen Programm kann man nie so tief
schalfen (aka. Strom sparen) wie ein RTC Timer der auch im tiefsten
Schalf noch in Hardware läuft. Außerdem hat man damit Wakeup Features in
der Hardware realsisert und der Controller muss nicht jede Sekunde
aufwachen, prüfen ob ein Alarmkriterium erfüllt ist und wieder schlafen
gehen. Wer wird aus der RTC Hardware Logik aufgeweckt wenn ein
Alarmkriterium erfüllt ist und auch nur dann. Außerdem ist eine RTC sehr
nett, und spart einem Programmieraufwand. (z.B. Aufwachen am 1.7.2017 um
09:14:31, schreib die Zahlen in ein Register und zu dem Datum wacht er
auf). So musst du jetzt anfangen deine Millisekunden umzurechnen, dann
vergisst du Schaltjahre und Schaltsekunden und und und. Lazyness eben.
Wahrscheinlich wo man gerade bei ist, ist das nächste auch nicht weit
entfernt..
So in die richtung:
Hey wir sind bei millisekunden, wenn wir jetzt noch bei 3600000 nen
Stundenregister mit hochzählen ist das nur ne Zeile mehr und kost
nichtmal Ressourcen, vielleicht brauchen wir dann nicht mal mehr
millisekunden im 20 stelligem Bereich hochzählen.
greg schrieb:
> RTCs haben in den allermeisten (allen?) Fällen Kalenderfunktionen> eingebaut. (...) Es wäre doch deutlich einfacher und flexibler,> einen einfachen Zähler zu implementieren, der bspw. Millisekunden> hochzählt.
Wäre es, zweifellos. Solche Chips gibt es auch, Maxim z.B. hat ein
knappes Dutzend zur Auswahl. Richtige Rechner™ wie die VAX verwenden die
auch. Normale Betriebssysteme zählen ja intern auch nur Sekunden oder
Nanosekunden hoch. Mit den Kalender-RTCs müssen die beim Booten immer
erst umrechnen.
Es geht aber auch noch schlimmer: beim Klassiker MC146818 war sogar die
Sommerzeitumstellung in Hardware fest verdrahtet.
> Ich musste gerade wegen Rockchip daran denken:> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f076ef44a44d02ed91543f820c14c2c7dff53716>> Die haben sich doch tatsächlich, äh, verzählt?
SEL (oder schon Alcatel?) hat mit einer Telefonanlage auch schon
versucht, den 31. November durch zu setzen. Mal sehen, ob's diesmal
klappt :)
greg schrieb:> Das braucht alles mit Sicherheit einen guten Batzen Logik.
Nö, das sind ganz einfache Zähler. Und die Schaltjahrhunderte sind auch
nicht implementiert.
Und für die Sommerzeit wirds richtig umständlich.
greg schrieb:> Es wäre doch deutlich einfacher und> flexibler, einen einfachen Zähler zu implementieren, der bspw.> Millisekunden hochzählt.
Neuere RTCs können das, die zählen die 32Bit bzw. 64Bit Sekunden.
Intern rechnet jeder PC das krude RTC-Format nach dem CPU-Reset schon
längst um.
Und während der Sommerzeit muß man dann nur noch 3600 addieren.
Herbert schrieb:> greg schrieb:>> Warum ist das eigentlich so? Es wäre doch deutlich einfacher und>> flexibler, einen einfachen Zähler zu implementieren, der bspw.>> Millisekunden hochzählt.>> Die RTC hat man im Normalfall dafür, wenn man ohne ausreichende> Stromversorgung (Batteriebetrieb) oder puffernd die Uhrzeit fortführen /> erhalten möchte. Kriterium ist also geringe möglichst langlebige> Stromversorgung. Das geht am besten wenn der Mikrocontroller so tief wie> möglich schläft und in stromsparender Hardware die Zeit fortgezählt> wird. Mit einem benutzergeschriebenen Programm kann man nie so tief> schalfen (aka. Strom sparen) wie ein RTC Timer der auch im tiefsten> Schalf noch in Hardware läuft. Außerdem hat man damit Wakeup Features in> der Hardware realsisert und der Controller muss nicht jede Sekunde> aufwachen, prüfen ob ein Alarmkriterium erfüllt ist und wieder schlafen> gehen. Wer wird aus der RTC Hardware Logik aufgeweckt wenn ein> Alarmkriterium erfüllt ist und auch nur dann. Außerdem ist eine RTC sehr> nett, und spart einem Programmieraufwand. (z.B. Aufwachen am 1.7.2017 um> 09:14:31, schreib die Zahlen in ein Register und zu dem Datum wacht er> auf). So musst du jetzt anfangen deine Millisekunden umzurechnen, dann> vergisst du Schaltjahre und Schaltsekunden und und und. Lazyness eben.
Naja, das geht etwas am Thema vorbei. Diese Vorteile sind mir schon
klar. In vielen Fällen ist das herumrechnen mit dem Kalender aber
komplizierter als mit einem einzigen Zähler (z.B. Sekunden seit der
UNIX-Epoche). Beispiel: Periodisches Aufwachen in einem Rhythmus, der
nicht glatt in das Kalenderschema passt (bspw. alle 37 Stunden).
In Software aus einem Zeitstempel ein Kalenderdatum zu machen und
umgekehrt ist dagegen recht stressfrei und maximal flexibel möglich, da
das die meisten C-Standardlibraries unterstützen, bspw. avr-libc und
newlib-nano.
Peter D. schrieb:> Und für die Sommerzeit wirds richtig umständlich.
Eigentlich geht das garnicht, weil die Umstellung von den Regierungen
immer wieder neu beschlossen wird, das könnte nächstes Jahr auch anders
sein. Stell dir vor es wäre Sommerzeit und keiner stellt um. Leider wird
da nichts draus.
Auch die Zeitpunkte der Umstellung sind nicht festgeschrieben und meines
Wissens auch nicht auf der ganzen Welt gleich, und überhaupt gibt es
eine Sommerzeit nicht überall, unsere wäre in Australien auch ganz fehl
am Platz. Da lässt man also hardwaremässig besser die Finger davon,
sonst müsste die RTC ihren Standort wissen und dazu eine Welttabelle
führen, die ständig upgedatet wird.
Ob es wohl RTCs für den jüdischen Kalender gibt?
Georg
greg schrieb:> Das braucht alles mit Sicherheit einen guten Batzen Logik.
Ziemlich harmlos. Schon für die Verhältnisse von vor 30 Jahren. Erst
recht heute.
> Warum ist das eigentlich so?
Nicht jedem Programmierer auf einem 2KB 8051 von anno dunnemal wird die
Aussicht geschmeckt haben, in Assembler Millisekunden-Timestamps ins
Datum umzurechnen, und umgekehrt.
Bei den LPC2000 hatte Philips das so gemacht, also mit einem simplen
Sekundenzähler. Sogar auf diesen Boliden war nicht jeder glücklich
damit, obwohl eigentlich sinnvoll. Aber Gewohnheiten ändern sich nur
langsam.
A. K. schrieb:> Aber Gewohnheiten ändern sich nur> langsam.
Der Feind des offensichtlich praktischeren ist die Gewohnheit (Hamwa
immer schon so gemacht).
eagle user schrieb:> SEL (oder schon Alcatel?) hat mit einer Telefonanlage auch schon> versucht, den 31. November durch zu setzen. Mal sehen, ob's diesmal> klappt :)
In diesem Zusammenhang auch schön ist die Interpretation von PHP für den
Datumsstring "00-00-00":
Interessant, wie hier Kabeljau, Forelle und Barsch in einen Topf
geworfen werden. Natürlich stimmt es: Ist ja alles Fisch. Der Regenwurm
kann auch gleich mit rein. Fühlt sich nicht besonders unähnlich an und
fällt in die Kategorie hat mal gelebt und sich bewegt. Ist darüber
hinaus tierisches Protein. Die Geschmäcker sind aber verschieden und der
Hunger auch.
Ursprünglich war es die Funktion einer RTC, in Zeiten ohne Strom, und
Internet dafür Sorge zu tragen, das der Rechner weiß wie spät es ist. So
kompliziert und vieldeutig ist das.
Zur Hochzeit der RTC gab es keine andere Möglichkeit. Mikroprozessoren
brauchten einfach zu viel Strom. "Normale" Quarze waren zwar relativ
Stabil aber oft nicht Uhrengenau.
Um sich die Programmierung der ganzen Schemata zur Datumserstellung zu
ersparen, war es nicht schlecht das ganze Fertig serviert zu bekommen.
Man beachte: Zu der Zeit war Speicher auch noch Mangelware.
Übrigens wegen der "üblichen" Anbindung an den Rechner, waren
Millisekunden auch etwas, was anderen passiert.
Fazit: Auch heute macht die RTC immer noch das, wofür sie geplant ist.
Manche aktuellen Prozessoren kommen, trotz neuem Kissenbezug, nicht an
deren Verbrauch ran.
Ja es stimmt: Der Porsche ist schneller wie der kleine 20-sitzige
Omnibus. Eine andere Rechnung besagt aber: Stimmt nicht! Werden 20
Personen von dem langweiligen A nach dem berühmten B transportiert, kann
der olle Bus das auf einmal, wärend der flotte Heinrich (4 Personen) 5
Mal fahren muss...
Peter D. schrieb:> Nö, das sind ganz einfache Zähler. Und die Schaltjahrhunderte sind auch> nicht implementiert.> Und für die Sommerzeit wirds richtig umständlich.
Deswegen ist es ja auch Schwachsinn die RTC-Zeit auf eine Lokalzeit zu
setzen, es sei denn man baut sich nur einen Wecker.
Jede ernsthafte Anwendung benutzt eine RTC mit UTC-Zeit.
Lokalzeitumrechnung mit allen Regelungen usw. wird in Software gemacht.
Dass es aber gleich ein UNIX-Timestamp sein muss, sehe ich nicht so.
Auch kann ich Deiner Argumentation nicht folgen, dass RTCs heute
überflüssig sind, denn die meisten Controller brauchen selbst im
niedrigsten Power-Level immer noch deutlich mehr Strom als eine
durchschnittliche RTC. Nimmt man besonders sparsame RTCs, relativiert
sich die Entladung der Lithiumzelle sogar und wird maßgeblich durch die
Selbstentladung der selben bestimmt.
Nicht jeder will in seinem Code noch nebenbei Timer laufen lassen und
irgendwelche Register hochzählen, auch weil oft die Ressourcen dafür
einfach nicht vorhanden sind.
Dass Du, lieber Peter, Deinen Code bis auf's Messer optimierst und alles
im Controller erledigen willst, ist Dein Bier, aber im kommerziellen
Umfeld ist so etwas nicht wartbar und ich hätte Dir das schon mehr als
1x um die Ohren geworfen, auch wenn es funktioniert.
Die RTCs erfüllen, damals wie heute, ihren Zweck hervorragend! Sie
zählen Zeit und das machen sie abhängig von ihrer Taktquelle auch sehr
genau. Ich brauche mich in meinem Programm nicht darum kümmern und es
wird einfach übersichtlicher. Braucht man die Zeit, fragt man die RTC
und fertig!
Es gibt übrigens auch Geräte, welche durchschnittlich länger
ausgeschaltet sind als eingeschaltet. Hier stellt sich die Frage
Supercap oder Lithium-Zelle gar nicht, weil es nur mit Lithium-Zelle
funktioniert. Die durchschnittliche Woche, die ein Supercap schafft,
dient nur dazu Netzausfälle zu überbrücken, also ist das etwas für
Geräte im Dauerbetrieb. Alle anderen Geräte, welche vielleicht 1x im
Monat eingeschaltet werden, sind mit einer Lithium-Zelle besser dran. :)
Viele Grüße!
Sven
