Ziel: Ich möchte mir eine Digitaluhr mit einem ATmega32 bauen. Für die Generierung des Taktes verwende ich Timer/Counter1 (16-bit) im CTC-Modus, Prescaler 256, um jede Sekunde ein Interrupt auszulösen, in dem die Zeit sekundengenau aktualisiert wird. Im Register OCR1A habe ich den Wert 31.249 eingetragen, nach der Formel 8.000.000 MHz / (2 x 256 x 0,5 Hz) - 1 Die Uhr läuft aber ca. um eine Sekunde pro Minute zu langsam. Gibt es also noch was anderes zu beachten? Die ISR ist übrigens die einzige ISR im Programm, und sie ist auch relativ lang, weil in ihr auch die Anzeige aktualisiert wird. Aber das sollte doch keinen Unterschied machen, da der Counter ja sowieso nach dem Compare Match sofort wieder von Null hochzählt, unabhängig von der Länge der ISR, oder sehe ich da was falsch? Bin selbst auch erst Neuling in Mikrocontroller-Programmierung, also dankbar für jede Hilfe!
Der ATmega32 läuft aber nicht mit dem internen RC-Oszillator, oder? Falls doch, wären die 1.7 % Abweichung gar nicht so schlecht.
> Gibt es also noch was anderes zu beachten? Ja, z.B. [0] HTH [0] https://www.mikrocontroller.net/articles/AVR-Tutorial:_Uhr#Ganggenauigkeit
Ahh, alles klar, also mir war nicht bewusst dass der interne Oszillator doch so ungenau ist... naja deshalb sag ich ja ich bin neu auf dem Gebiet... danke jedenfalls für die Hilfe!
Wenn es einfacher (und damit billiger) genauso gut ginge, würde die Quarz-Technologie nicht den Uhren-Alltag dominieren.
Zum Testen mit dem internen kann man diesen RC noch kaliibrieren mal im DB nachgucken. Wenns Projekt dann fertig wird oder du einen Kristall hast nutze den Kritall.
Kannst auch einen 32,768kHz-Quarz für den Timer2 benutzen z.B. jede Sekunde einen Interrupt auslösen. Der Rest des MC kann dann problemlos mit dem internen RC-clock laufen.
Richtig! H.Joachim S. schrieb: > Der Rest des MC kann dann problemlos > mit dem internen RC-clock laufen. Oder gar schlafen.
Oh, ich seh gerade - beim Mega32 geht das gar nicht. Man kann zwar einen 32kHz-Quarz benutzen, aber der ist dann auch der Takt für alles. Für ne Digitaluhr kommt man aber sogar mit den 32kHz aus, gibt ja nicht wirklich was zu tun. Bei moderneren AVRs kann man den separat verwenden.
Nach diesem Datenblatt kann man den Timer sehr wohl asynchron betreiben. http://ww1.microchip.com/downloads/en/DeviceDoc/doc2503.pdf TOSC1 und TOSC2 sind dann die Pins für den Uhrenquarz. Und nicht XTAL1 und XTAL2 // oder habe ich da was übersehen? (der Mega32 gehört nicht zu meinen Standardbauteilen. eher der Mega328P)
Arduino Fanboy D. schrieb: > // oder habe ich da was übersehen? Nein. Das gilt für die Megas nahezu(*) durchgehend. Uhrenquarz gehört sinnvollerweise asynchron an Timer2 betrieben. (*)nahezu: Mir fällt derzeit keine Ausnahme von dieser Regel ein, möchte aber nicht ausschliessen, dass es doch eine geben könnte. Auf jeden Fall ist der Betrieb an Timer2 schon deshalb vorzuziehen, weil es bei vielen Mega überhaupt keine oder nur eine sehr eingeschränkte Möglichkeit gibt, einen 32kHz-Uhrenquarz als Systemtaktgeber zu verwenden. Man muss hier sehr genau wissen, was man tut, wenn man möchte, dass der Quarz eine längere Betriebszeit überleben soll. Das hat Abhängigkeiten nicht nur vom konkreten AVR8, sondern auch von der Betriebsspannung, mit der er läuft. Das ist übrigens auch so eine Sache, über die die Datenblätter keine erschöpfende Auskunft liefern, nichtmal das entsprechende AN hilft hier wirklich weiter, weil in den DBs üblicherweise nicht direkt steht, welche Variante des Quarzoszillators verwendet wird, man ist hier auf deduktive Fähigkeiten angewiesen, muss also selber aus den DB-Angaben die verwendete Oszillatorvariante ermitteln können und zusätzlich auch noch, ob zwar eine prinzipiell geeignete Variante vorliegt, aber die benötigte Konfiguration möglicherweise trotzdem für das konkrete Device nicht erreichbar ist. Hier könnte die Doku definitiv noch massiv verbessert werden... Noch weitaus unübersichtlicher ist die Situation bei den Tinys, denn dort entfällt ja die unkomplizierte Variante des Betriebs über Timer2 und man muss den Quarz als Systemtaktquelle verwenden, wenn man ihn denn verwenden möchte. Die Probleme sind dann allerdings exakt dieselben wie bei den Megas. Hier ist die bestmögliche Lösung für Laien: nur die Tinys verwenden, die explizit für den Betrieb mit Uhrenquarz spezifiziert sind. Leider sind das garnicht so sehr viele Typen... Und klar: egal ob Tiny oder Mega: sobald man einen Uhrenquarz als Systemtakt einsetzt, wird der Einsatz des PowerDown zum Energiesparen praktisch unmöglich. Auf Grund der hohen Güte und der geringen möglichen Energiezufuhr dauert es nämlich eine echte Ewigkeit, bis die Dinger einen einigermaßen stabilen Takt liefern. Größenordnung bis ca. 1s.
Holzer schrieb: > Ziel: Ich möchte mir eine Digitaluhr mit einem ATmega32 bauen Holzer schrieb: > Bin selbst auch erst Neuling in Mikrocontroller-Programmierung warum m32? der ist alt, mehr Platz hat man im m644 oder 1284p und beide sind Pin und SW kompatibel! wenn der m32 reicht geht auch m328p kleiner als Chip auch 32KB flash und zum Entwickeln gibt es den Arduino Nano 328p
Chris H. schrieb: > Zum Testen mit dem internen kann man diesen RC noch kaliibrieren mal im > DB nachgucken. Einmal habe ich so auch versucht. Ich wollte wissen, ob Kalibrieren wirklich für etwas taugt. Die Antwort: Kalibrieren ist einfach zu grob für Verwendung als Uhr. OSCCAL ist einfach zu grob, +-1 bedeutet zu große Unterschied. Für Aufgaben, wo +-1% ausreicht, so wie USART, könnte Kalibrieren noch etwas bringen. Aber nicht für eine Uhr.
Maxim B. schrieb: > Aber nicht für eine Uhr. OSCCAL = $00 = 50% - 100% deiner 8Mhz = $7F = 75% - 150% deiner 8Mhz = $FF = 100% - 200% deiner 8Mhz Bedeutet du müsstest erstmal die reale RC-Frequenz rausbekommen und dann die Abweichung berechnen die dann in OSCCAL einzutragen ist. Welcher Wert steht denn jetzt in OSCCAL drine ? Möglichkeit 2 Anstatt den internen RC zu nutzen einen externen Kristal anschließen und so weiterverfahren wie bis her. Möglichkeit 3 Krummen Quarz nehemen OCR1A(PD5) toggeln und auf XTAL1 geben mit einer Frequenz von 32,768kHz. T2-Teiler auf 1024 und du hast 32 Ticks Möglichkeit 4 Quarz beliebiger Freqeunz an OSC oder auch der interne RC füe den Systemtakt verwendne und an XTAL1/2 einen Uhrenquarz mit 32,768kHz anschließen....
Angehängte Dateien:
-
2018-08-27_143050.png
36 KB
Chris H. schrieb: > OSCCAL = $00 = 50% - 100% deiner 8Mhz > = $7F = 75% - 150% deiner 8Mhz > = $FF = 100% - 200% deiner 8Mhz Nein, das darf nicht so krass sein, siehe Bild. Übersetzt: Aus der Fabrik : 8MHz +/- 10% ergibt 7,2MHz bis 8,8MHz. Wenn man max 1% Fehler haben will, darf die Frequenz nur zwischen 7,3MHz und 8,1MHz betragen, d.h. die Frequenz kann nur zwischen 91,25% und 101,25% variieren. Demzufolge sollten für OSCCAL nur Werte zwischen 0x58 und 0x70 verwendet werden. Ist von Exemplar zu Exemplar verschieden, aber bestimmt nicht so, dass ein OSCCAL Wert von 10 oder 250 nötig wäre. Ausserdem bewirken solch extreme Werte mit an Sicherheit grenzender Wahrscheinlichkeit eine Fehlfunktion.
Maxim B. schrieb: > Einmal habe ich so auch versucht. Ich wollte wissen, ob Kalibrieren > wirklich für etwas taugt. Die Antwort: Kalibrieren ist einfach zu grob > für Verwendung als Uhr. OSCCAL ist einfach zu grob, +-1 bedeutet zu > große Unterschied. Du hast die Möglichkeiten nicht so ganz begriffen. Wenn ein Schritt zu grob ist, dann wendet man eben in mehr oder weniger schneller Folge zwei benachbarte Schritte an. Über das Zahlenverhältnis der beiden angewandten Schritte kann man im Prinzip jeden denkbaren Zwischenwert (langfristig) herstellen. Das wäre also eigentlich genau das richtige für eine Uhr, dann da kommt's vor allem drauf an, den langfristigen Fehler gering zu halten, wenn die zwischenzeitlich mal ein paar hundert Takte vor- oder nachgeht, interessiert das kein Schwein. Aber leider ist das (die geringe Auflösung von OSCCAL) garnicht das eigentliche Problem. Das ist vielmehr: der RC-Oszillator hat eine recht starke Abhängigkeit von der Umgebungstemperatur (und auch eine, allerdings deutlich unkritischere, von der Versorgungsspannung). D.h.: wenn du bei 22,0°C und 5,0V kalibrierst, kannst du mit o.g. Methode eine schon ganz brauchbare langfristige Genauigkeit herstellen. Leider aber nur unter der Bedingung, dass du das Device weiterhin auf exakt 22,0°C temperierst und die Spannung auf genau 5,0V hältst... Erkennst du das eigentliche Problem?
Marc V. schrieb: > Nein, das darf nicht so krass sein, siehe Bild. Na so stehts im Datenblatt. Ich saug mir das doch nicht aus den Fingern DB S.27 Marc V. schrieb: > Ausserdem bewirken solch extreme Werte mit an Sicherheit grenzender > Wahrscheinlichkeit eine Fehlfunktion. Nö, bei anderen Frequenzen als 1/2/4/8Mhz wirds kritisch wenn man kalibriert. Max 10% über Nominalfrequenz könnte Probleme beim Flash/EEprom geben aber siehe DB S.27 Wo hast du eigentlich diese Tabelle her? Bräuchte mal nen Bezug denn diese ist im DB des ATM32 nicht vorhanden
Chris H. schrieb: > Wo hast du eigentlich diese Tabelle her? Bräuchte mal nen Bezug denn > diese ist im DB des ATM32 nicht vorhanden Ist für M328P, habe erst jetzt gesehen, dass es um M32 geht, sorry.
Chris H. schrieb: > OSCCAL = $00 = 50% - 100% deiner 8Mhz > = $7F = 75% - 150% deiner 8Mhz > = $FF = 100% - 200% deiner 8Mhz > > Bedeutet du müsstest erstmal die reale RC-Frequenz rausbekommen und dann > die Abweichung berechnen die dann in OSCCAL einzutragen ist. > Welcher Wert steht denn jetzt in OSCCAL drine ? So viel Theorie habe ich damals nicht gemacht. Das war viel einfacher: ich habe eine Uhr programmiert und OSCCAL möglichst genau eingestellt. Leider hatte ich bei einem Wert eine Uhr, die eine Minute in 60,5 Sek absolvierte, und wenn ich den Wert um 1 größer machte, war eine Minute schon 59,5 Sek. lang. D.h. solche Uhr kann Genauigkeit etwa +- ~12 Min. pro Tag haben. Ich bin nicht sicher, ob jemand so eine Uhr braucht. c-hater schrieb: > Du hast die Möglichkeiten nicht so ganz begriffen. Wenn ein Schritt zu > grob ist, dann wendet man eben in mehr oder weniger schneller Folge zwei > benachbarte Schritte an. Über das Zahlenverhältnis der beiden > angewandten Schritte kann man im Prinzip jeden denkbaren Zwischenwert > (langfristig) herstellen. Klingt schön. Da aber RC-Oszillator nicht besonders stabil ist, sollten wir die Uhr sehr oft kalibrieren. In jedem Fall, wenn Temperatur sich etwas ändert. D.h. Kalibrator sollte in Uhr eingebaut werden. Dann so oder so brauchen wir doch Quarz :) Ist es nicht einfacher, das Ganze einfach von Quarz laufen lassen ? Quarz kann man schon für 17 Cent haben. Noch 2 Cent für 2 Chip-Kondensatoren. Will man aber eine gute Lösung, so ist am besten Uhr-IC zu nehmen, so wie DS3231. IC hat eingebaute Quarz und dazu noch Temperaturfühler, so daß auch die kleine Abhängigkeit für Quarz von Temperatur ausgeglichen wird! Das kostet nur 2 Pins für I2C-Interface. ATMega selbst kann dann von RC-Oszillator laufen.
:
Bearbeitet durch User
Maxim B. schrieb: > Das war viel einfacher: > ich habe eine Uhr programmiert und OSCCAL möglichst genau eingestellt. Wird aber, wie C-hater schrieb, nur einmal eingestellt oder du hinterlegst dir einen Algorhytmus der dir die richtigen Bits ausrechnet. Und wer hat euch solch Flausen in den Kopf gesetzt das man immer kalibrieren muss ? > Leider hatte ich bei einem Wert eine Uhr,.... Man nutzt trotzdem zum Feintuning nicht das OSCCAL sondern die Timerbits OCRyx, da hier die Auflösung deutlich besser ist. Und du vergisst das du es auf 8Mhz berechnet hast welche gar garnicht vorhanden sind, probiers mal nur mit 7,999940Mhz di Rechnung..... Somit bleibt nur die Möglichkeit eines oder zwei Quarze. Selbst mit einem 4Mhz-Quarz bekommt man eine Uhr, die recht genau läuft, weniger als 1s auf 24h. Nochmal die Möglichkeiten lesen von > Chris H. > Firma: Selbständig Denkender)(keiningenieur) > Datum: 27.08.2018 13:48
Chris H. schrieb: > Man nutzt trotzdem zum Feintuning nicht das OSCCAL sondern die Timerbits > OCRyx, da hier die Auflösung deutlich besser ist. 1. für Timer 1 (und Timer 3) kann man wichtigere Aufgaben finden 2. auch dann ist Auflösung zu grob, wenn auch genauer (etwa +- 1,5 Sek pro Tag). Meine Uhr aus dem Jahre 1984 oder 1985 hat so eine Einstellung mit +- 0,1 Sek pro Tag. Muß man heute etwas machen, was nicht einmal der Entwicklung vom 1980 entspricht? 3. Stabilität von RC-Oszillator ist sowieso derart schlecht, daß diese Berechnungen sinnlos bleiben.
Maxim B. schrieb: > Klingt schön. Da aber RC-Oszillator nicht besonders stabil ist, sollten > wir die Uhr sehr oft kalibrieren. In jedem Fall, wenn Temperatur sich > etwas ändert. Beitrag "Re: ATmega: interner Tempsensor"
Joachim B. schrieb: > Maxim B. schrieb: >> Klingt schön. Da aber RC-Oszillator nicht besonders stabil ist, sollten >> wir die Uhr sehr oft kalibrieren. In jedem Fall, wenn Temperatur sich >> etwas ändert. > > Beitrag "Re: ATmega: interner Tempsensor" Der interne Sensor ist sehr praktisch in solchen Fällen. Nur leider beim Mega32 nicht existent. (soweit mir bekannt) Also bleibt zur selbstkalibrierung nur der WDT. Dessen Temperaturabhängigkeit ist umgekehrt, zum Haupttaktgenerator. Für die serielle Kommunikation wirds dann reichen, aber als Uhr taugt das nicht wirklich.
Arduino Fanboy D. schrieb: > Der interne Sensor ist sehr praktisch in solchen Fällen. > Nur leider beim Mega32 nicht existent. (soweit mir bekannt) warum auch m32 es gibt bessere und modernere, von 644 - 1284p sowie m328p Beitrag "Re: AVR Timer/Counter Zeit berechnen"
Man kann sogar eine Uhr mit 74xx bauen... Die Frage ist aber "wozu" ? DS3231 kostet wenig. Wenn aber aus rein sportlicher Interesse, dann Quarz nehmen. Die kosten heute weniger als guten Kondensator. Wenn man interne Thermosensor von Mega nutzen will, dann sollte man durch viele Experimente genaue Abhängigkeit RC von Temperatur ermitteln. Dann noch Abhängigkeit Spannung von Temperatur und RC von Spannung. Im Datenblatt steht das nur so ungefähr, man braucht das viel genauer zu wissen. Dann Programm: Temperatur messen, auf Abhängigkeiten multiplizieren, Korrektur ermitteln... Falls statt 7805 317 steht, wieder: Abhängigkeit Spannung von Temperatur messen, Programm korrigieren... Kommt neue Kiste mit IC, dann alles wieder neu machen: IC verändern sich von Die zu Die... Am Ende: Genauigkeit um eine oder zwei Ordnungen schlechter als bei Quarz für 17 Cent... Bestimmt sehr interessant. Aber praxisfern. Es gibt viele andere Dinge zu machen, die viel interessanter und für Praxis wichtiger sind.
:
Bearbeitet durch User
Chris H. schrieb: > Man nutzt trotzdem zum Feintuning nicht das OSCCAL sondern die Timerbits > OCRyx, da hier die Auflösung deutlich besser ist. Maxim B. schrieb: > 3. Stabilität von RC-Oszillator ist sowieso derart schlecht, daß diese > Berechnungen sinnlos bleiben. LOL. Genau. Selbst ein Fehler von 30% ist absolut uninteressant, Stabilität ist wichtig. Absoluten Fehler kann man ganz leicht korigieren solange dieser stabil bzw. konstant bleibt, egal ob der Fehler 2ppm oder 500000ppm beträgt.
Maxim B. schrieb: > Dann noch Abhängigkeit Spannung von Temperatur und RC von Spannung. Im > Datenblatt steht das nur so ungefähr, man braucht das viel genauer zu > wissen. Dann Programm: Temperatur messen, auf Abhängigkeiten > multiplizieren, Korrektur ermitteln... Falls statt 7805 317 steht, > wieder: Abhängigkeit Spannung von Temperatur messen, Programm > korrigieren... Kommt neue Kiste mit IC, dann alles wieder neu machen: IC > verändern sich von Die zu Die... Am Ende: Genauigkeit um eine oder zwei > Ordnungen schlechter als bei Quarz für 17 Cent... deswegen würde ich eher einen Quarz oder eine RTC einsetzen, der ganze Kalibrieraufwand lohnt doch nicht! ich finde es jeden Morgen faszinierend wie genau FunkuhrWecker und Rolladenautomatik mit RTC DS3231 syncron laufen.
:
Bearbeitet durch User
Joachim B. schrieb: > ich finde es jeden Morgen faszinierend wie genau FunkuhrWecker und > Rolladenautomatik mit RTC DS3231 syncron laufen. Auch. Ich habe noch vor dem Urlaub mein Probemodul programmiert, um I2C mit DS3231 zu testen. Erstaunlich, wie genau das läuft! Ich denke, Frequenz von diesem Modul könnte man notfalls für Kalibrieren von F-Meter nutzen.
Marc V. schrieb: > Selbst ein Fehler von 30% ist absolut uninteressant, Stabilität ist > wichtig. Fehler ist auch uninteressant nur die Stabilität ist mal beim internen RC für gewisse Anwendung nicht optimal. Ebenso kann die UART natürlich mit dem internen RC genutzt werden nur muss man gucken welche Geschwindigkeiten man haben will bzw wo der Fehler gering ist. Alle Baudraten funktionieren eben mit nichten des internen RC! Siehe DB Seite 315/316 interne RC und mal nur zur Info auf die UART verwiesen ab S.163. Diese Tables beziehen sich alle auf einen externen Quarz viel Spaß mit dem internen RC als Basistakt bei der UART... Die Umgebung mal nicht mit einbezogen... > Absoluten Fehler kann man ganz leicht korigieren solange dieser > stabil bzw. konstant bleibt, egal ob der Fehler 2ppm oder 500000ppm > beträgt Mir ist das durchaus bewusst und schon oft genug so gemacht nur dem TO fehlt im Moment Erfahrung um die Uhr mit solchen Sachen voll zu stopfen. Fakt ist der TO sollte sich einen Quarz besorgen und erstmal die Uhr aus dem Systemtakt heraus programmieren um ein Gefühl zu entwickeln....
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.