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.
:
Bearbeitet durch User
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":
1 | There is no bug here, 00-00-00 means 2000-00-00, |
2 | which is 1999-12-00, which is 1999-11-30. |
3 | No bug, perfectly normal. |
https://bugs.php.net/bug.php?id=45647
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
:
Bearbeitet durch User
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.