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!
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!
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.
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 bauenHolzer 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....
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.
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.
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.
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.
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.
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....
