Ich hab mir grad ein paar Schaltpläne von Funkuhren ... angesehen. Unter anderem sind mir dann Echtzeit-Bausteine aufgefallen, nur versteh ich den Sinn nicht ganz. Ist ein Mikrocontroller denn zu ungenau und müsste ständig korrigiert werden oder besitzen sie keinen internen Timer?
Ein Microcontroller hat einen Timer, aber keine Uhr. Dh er kann mikrosekunden zaehlen, weiss aber nicht wann 16:32:15 Uhr ist. Das macht der RealTimeClock (RTC)
Schau dir doch mal den Stromverbrauch eines solchen RTC an, und dann schauste was dein µC Verbraucht wenn er das selbe macht, da sind viele RTC doch besser. Auch kannste dann noch wichtigere Sachen auf dem µC machen und brauchst dich um das ganze Uhr-Kalender-Alarm-Geraffel nicht mehr zu kümmern. Und das viele SPI oder I²C Anschluss haben macht sie einfach zum ansteuern.
Aber wenn ich jetz nur die Uhrzeit auf ein Display legen will? Ich könnte doch den Timer auch so einstellen, dass alle Sekunde ein Interrupt geliefert und eine Variable hochgezählt wird. Also kurzum: Wenn ich ne Uhr anzeigen will, sollt ich so nen Baustein verwenden? Könnte mir da jemand nen guten nennen? Hab bisher nur von den PCF85... gelesen, wobei es nicht viele Beispiele hierfür gibt.
Markus F. schrieb: > Ist ein Mikrocontroller denn zu ungenau und müsste ständig korrigiert > werden oder besitzen sie keinen internen Timer? Ein Controller ist gar nicht genau. Er braucht dafür einen Quarz oder Quarzoszillator, mit dem wird dann ein interner Timer betrieben. Nachteilig ist, dass die Behandlung der Uhr dann in die normale Firmware mit integriert werden muss, damit wird sie durch Störungen in dieser Firmware auch mit gestört (beim Debuggen usw.), sowie es entsteht zusätzlicher Aufwand für die Firmware. Mit den Hardware-RTCs lagerst du diese Problematik halt komplett auf einen IC (+ eingebauter Batterie) aus. Früher (also insbesondere zu Zeiten, als es noch keine preiswerten EEPROMs gab) wurde dabei gern noch ein wenig SRAM integriert, der von der gleichen Batterie gepuffert wird, und in dem man Konfigurationsdaten (bspw. auf Computern eine Seriennummer und Ethernetadresse) hinterlegt hat. Mittlerweile haben derartige Bausteine eher an Bedeutung verloren, da halt die Firmware für derartige Funktionalität in einem Controller so schwierig nicht zu implementieren ist und praktisch jeder bessere Controller eine derartige Lösung irgendwie anbietet.
Hallo, auch der RTC muß man erstmal sagen, wann es 16:32:15 Uhr ist. ;-) Geringer Stromverbrauch, eigene Bufferbatterie spielten da eine Rolle. Obwohl ich meine, daß inzwischen ein µC mit zusätzlichem Uhrenquarz und Sleepmode diese Seite auch hinbekommt. Ein Nachteil bleibt trotzdem: wenn der µC abstürzt, muß ihm wieder jemand sagen, wie spät es ist. Wenn dann kein DCF77 o.ä. greifbar ist, gewinnt eine RTC. Die stürzen äußerst selten ab. ;-) Gruß aus Berlin Michael
lightninglord schrieb: > Schau dir doch mal den Stromverbrauch eines solchen RTC an, und dann > schauste was dein µC Verbraucht wenn er das selbe macht, da sind viele > RTC doch besser. Seit Controller im Schlafmodus einen Eigenverbrauch haben, der im Bereich der Selbstentladung der Batterien angesiedelt ist, spielt das kaum noch eine Rolle.
hmm.... schrieb: > Ein Microcontroller hat einen Timer, aber keine Uhr. Dh er kann > mikrosekunden zaehlen, weiss aber nicht wann 16:32:15 Uhr ist. Das macht > der RealTimeClock (RTC) Nein, die weiß das auch nicht. Die muss man auch erstmal stellen, und sie hat nicht die Genauigkeit einer Atomuhr, muss also auch gelegentlich korrigiert werden. Also alles nichts, was nicht auch der Controller mit seinem eigenen Timer ebenfalls machen könnte.
Um aus Mikrosekunden 16:32:15 Uhr zu machen ist nicht viel Softwarekenntnis nötig. Ein Grund könnte sein: Die CPU in den Betriebspausen schlafen zu schicken. Das spart Strom und der Uhrenbaustein behält die Zeit im Auge. Er kann sogar die CPU aufwecken. und noch ein Grund: Die CPU wird mit dem inneren RC-Generator getaktet. Der ist zu ungenau für eine Uhr. und noch ein Grund: Uhrenbausteine brauchen sehr wenig Strom. Sie lassen sich leicht mit einer Batterie puffern. Nach längeren Stromausfällen oder Abschaltungen weiß das System dann immer noch wie viel Uhr es ist. und noch ein Grund: fällt mir jetzt nicht mehr ein.
> machen und brauchst dich um das ganze Uhr-Kalender-Alarm-Geraffel nicht > mehr zu kümmern. Vor allem ist der ganze Kalenderkram so kompliziert das vermutlich kaum einer das mal eben so auf die Reihe bekommt. .-) > Hab bisher nur von den > PCF85... gelesen, wobei es nicht viele Beispiele hierfür gibt. Man koennte ja das Datenblatt lesen und es einfach machen. Insbesondere vor dem Hintergrund das es ein I2C-Bus IC ist, koennte man ja dann noch die I2C-Bus Routinen woanders abschreiben. Wer das dann immer noch nicht hinbekommt sollte sich vielleicht besser eine Uhr kaufen. > Geringer Stromverbrauch, eigene Bufferbatterie spielten da eine Rolle. Eine Rolle spielt vor allem das die 32kHz Quarze besonders auf Genauigkeit getrimmt wurden. Und dann moechte man so einen 08/15 Microcontroller normalerweise auch nicht mit 32khz laufen haben. Und man moechte vielleicht auch nicht einen Quarzoszillator mit 32khz Quarz bauen weil die nicht so schwingfreudig sind. Jedenfalls nicht als Anfaenger. .-) Und man moechte vielleicht auch nicht einen normalen Quarz nehmen und den mit einem C-Trimmer erstmal muehselig auf Genauigkeit trimmen. Es gibt aber Controller die haben einen Anschluss fuer einen normalen Quarz und einen 32kHz. Olaf
Markus F. schrieb: > Ich hab mir grad ein paar Schaltpläne von Funkuhren ... angesehen. Unter > anderem sind mir dann Echtzeit-Bausteine aufgefallen, nur versteh ich > den Sinn nicht ganz. Das ist man von früher noch so gewohnt, wo MCs noch Haufen Außenbeschaltung brauchten und daher auch viel Strom. Und es wird einfach immer wieder übernommen, ohne darüber nachzudenken. Du hast recht, es ist sinnlos. Heutige MCs haben Stromsparoptionen, die z.B. an einem Goldcap völlig ausreichende Überbrückungszeiten gewärleisten. Man kann auch meistens nen 32kHz Uhrenquarz anschließen, um viel Strom zu sparen. Der Hauptquarz wird dann abgeschaltet. > Ist ein Mikrocontroller denn zu ungenau und müsste ständig korrigiert > werden oder besitzen sie keinen internen Timer? Natürlich ist ein MC mit Quarztakt auch quarzgenau. Eine Kalibration ist aber zu Anfang zu empfehlen, wenn kein spezieller Uhrenquarz verwendet wird. Ist ein Funkempfänger angeschlossen, kann die Kalibration automatisch erfolgen. Ich hab früher auch mal kurz mit RTCs gespielt, wurde mir dann aber zu aufwendig. Besonders die Kommunikation und das Umwandeln der verqueren 2..4-Bit Formate in vernünftige Zahlenwerte kostet nur unnötig Code. Sommerzeit muß man ja eh noch extra machen. CPU-intern Zeit und Datum zu zählen, hat den Charme, daß jede Task direkt drauf zugreifen kann und nicht unnötig CPU-Ressourcen mit I2C/SPI-Datenbussen und Formatwandlung belegt. Einen Timerinterrupt hat man ja eh in jeder Anwendung laufen. Ich sehe daher externe RTC-Bausteine als ein überkommenes Relikt aus vergangenen Zeiten an. Peter
Moin, Viele µC integrieren mittlerweile eine RTC in ihrem Baustein. Diese kann man meistens sogar separat mit Spannung versorgen (Battarie puffer) Problem ist eher, das diese RTC alleine mehr strom braucht als eine gute Externe RTC auch wenn der rest der CPU abgeschalten ist. Hängt warscheinlich mit den Fertigungsprozessen zusammen, die bei Externen RTCs auf Stromsparen getrimmt ist, bei der MCU auf geschwindigkeit. Die miesten MCU mit RTC können auch einen zusätzlichen Quarz ansprechen einen für RTC und SlowClock den 2ten für die HighSpeedClock
Ich bin auch gerade dabei eine Funkuhr zu bauen. Allerdings sind meine LED-Dot-Matrix-Anzeigen derart "rechenintensiv" anzusteuern, dass ich nicht auch noch den Overhead einer Software-RTC haben wollte (mit allen Vor- und Nachteilen). Deshalb benutze ich eine I²C-RTC (DS1307). Bei Maxim kann man sich kostenlose Samples davon schicken lassen. Die Uhrzeit im DCF-Telegramm wird nach decodierung und Plausibiltätsprüfung in die RTC geschrieben. Bei gutem Empfang also 1x je Minute. Bleibt DCF aus, läuft die RTC eben einfach so weiter. Sven
> Allerdings sind meine LED-Dot-Matrix-Anzeigen derart "rechenintensiv"
Du arbeitest noch mit den MCS48? :-P
Olaf
Einen Vorteil sollte der RTC noch haben: Er wird sich nicht durch zusätzlich eingefügte Befehle "Rechenzeit stehlen lassen" im Gegensatz zu irgendwelchen programmierten Zähl-Zeitschleifen.
Termite schrieb: > Problem ist eher, das diese RTC alleine mehr strom braucht als eine gute > Externe RTC auch wenn der rest der CPU abgeschalten ist. Urban legend. Ein PCF8583 braucht bei 5 V typisch 10 µA standby (maximal 50 µA). Ein ATmega1281 (also ein schon eher großer Controller) braucht typisch 3 µA im power-save mode bei 5 V. Wie Peter schon schrieb, im Großen und Ganzen sind das Relikte aus vergangenen Zeiten, als die Verhältnisse im Controllerbereich noch nicht so waren, wie sie es mittlerweile sind.
oszi40 schrieb: > Einen Vorteil sollte der RTC noch haben: Er wird sich nicht durch > zusätzlich eingefügte Befehle "Rechenzeit stehlen lassen" im Gegensatz > zu irgendwelchen programmierten Zähl-Zeitschleifen. Wer eine Uhr mit programmierten Zähl-Zeitschleifen implementiert, hat aber auch irgendwie die Sache nicht verstanden. ;-) Ob der es hin bekommen wird, ein I²C zu bedienen?
Jörg Wunsch schrieb: > Wer eine Uhr mit programmierten Zähl-Zeitschleifen implementiert, hat > aber auch irgendwie die Sache nicht verstanden. ;-) Ob der es hin > bekommen wird, ein I²C zu bedienen? Wenn er BASCOM benutzt: ja. Aber dann wartet die nächste Hürde: Der Wecker soll morgens um 7 klingeln und BASCOM hat keine Routinen zum Zeitvergleich :-)
Karl heinz Buchegger schrieb: > Wenn er BASCOM benutzt: ja. > Aber dann wartet die nächste Hürde: Der Wecker soll morgens um 7 > klingeln und BASCOM hat keine Routinen zum Zeitvergleich :-) Unter C kriegt man erst recht nicht alles vorgekaut. Für den Weckzeitvergleich muß man sich folgende äußerst komplizierte Routine selber schreiben:
1 | if( time.minute == alarm.minute && time.hour == alarm.hour ){ |
2 | // tue was
|
3 | }
|
Peter
Ich weiss nicht in welchen Stueckzahlen ihr Leute euer Zeug baut. Es gibt da so eine Grenze unterhalb der RTC guenstiger ist als : Bei jedem Debug lauf, bei jedem Firmware update, die Uhr neu zu stellen dauert und ist umtriebig. Speziell wenn die Uhrenfunktionalitaet wichtig ist. So eine DS1302, DS1306, DS1337 ist ein paar Euro. Dh unterhalb hundert Stueck ist eine extra RTC das Geld wert, oberhalb tausend Stueck sollte man drauf verzichten. Man kann auf der Leiterplatte ja beides vorsehen und nur das Eine bestuecken.
Ein noch nicht ausgesprochener Vorteil einer separaten RTC ist der Speicher. Da kann man sich den Filepointer fuer ein externes flash anlegen, der dann dadurch auch ein Reprogramming ueberlebt.
Die 10µA vom PCF8583 sind Datenblattwerte; real werden 2-3µA bei Raumtemperatur benötigt. Der Nachfolger PCF8563 braucht bei 3V nur noch 0,25µA (auch Datenblatt :-). Den setze ich immer noch ein. Er läuft noch mit 1V und kann damit Pufferbatterien bis zum vorletzten Elektron ausreizen. µPs machen schon früher schlapp. Bei meinen Stückzahlen zahle ich etwa 55ct/Uhr. Da lohnt keine aufwendige Programmierung samt Korrektur eines AVR. Muß jeder selber entscheiden.
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.