ich verwende m328 mit 8MHz intern.
F_CPU ist mit 8000000 angegeben. ich Möchte jetzt F_CPU kalibrieren, so
dass _delay_ms(1000) möglicht genau eine Secunde ergibt. Dass da immer
Ungenauigkeiten bleiben, ist mir klar
Das ganze soll dann mittels einer Fernbedienung als Normal ausgemessen
werden, so dass mir mittels Fernbedienung für verschiedene MCUs der Wert
für F_CPU auf dem display angezeigt wird.
Hat jemand für die Kalibrierung ein fertiges Programm???
Peter II schrieb:> Wie groß ist deine Abweichung?
genau das ist die Fragestellung.
Ich habe für die fb diese routine:
1
//signal messen
2
while(endwhile){
3
i=0;
4
while(ir_pin&&i<60001)i++;
5
tmp[n]=i;//Speichert Anzahl der Ticks bis Flankenwechsel
6
if(i==0)endwhile=0;
7
i=0;
8
while(!ir_pin&&i<60001)i++;
9
tmp[n+1]=i;
10
if(i==0)endwhile=0;
11
if(n<48)n=n+2;
12
}
Ich habe festgestellt dass die Zahl der Ticks in tmp[1] bei
verschiedenen m328 - alle mit 8MHz intern - und gleicher nec-fb
erheblich abweicht.
Ergebnis der Kalibrierung kann aber auch sein, das 8000000 immer der
richtige Wert ist. Ist aber eher unwahrscheinlich.
Kalibrieren bedeutet einen externen Clock dagegen laufen zu lassen, und
das Osccal Regsiter zu aendern bis der Wert genau genug ist. Dabei
sollte aber beachtet werden, dass der internen Oszillator eine bleibende
Empfindlichkeit auf Temperatur und speisung aufweist. siehe Datenblatt.
Fuer die Kalibration siehe :
http://www.ibrtses.com/embedded/avrosccal.html
grundschüler schrieb:> Ich habe für die fb diese routine:
Benutze für eine Zeitmessung einen Timer, dafür ist dieser in Deinem µC
eingebaut. Der Timer ist unabhängig von der Anzahl der Takte, welche
Deine Zeile
1
while(ir_pin&&i<60001)i++;
je nach Compilerversion und Optimierung braucht.
Wenn sonstige ISRs Dir dabei dazwischenknallen, wird Dein Zählergebnis
"erheblich" verfälscht.
Eine timergestützte Stoppuhr ist auf dem AVR sehr simpel.
Ich habe das Gefühl, ihr seid alle irgendwie daneben. Oder habe ich das
total missverstanden?
Der TO will den internen Oszillator nehmen und damit eine möglichst
genaue Sekunde erhalten (mit von ihm akzeptierten Ungenauigkeiten).
Keine externen Quarz - denn wozu soll er dann den internen Oszillator
abgleichen wollen?
Für ein vorhandenes Prozessordevice kann man folgendes machen, um das
delay-Makro für 1000 Millisekunden genauer zu bekommen:
- F_CPU manuell verändern (darauf baut _delay_ms() auf), bis die Sekunde
weitgehend stimmt.
- oder den Parameter für _delay_ms so lange anpassen (998, 999, 1001
...), bis die Sekunde weitgehend stimmt
- oder den Wert für OSCCAL anpassen, bis die Sekunde weitgehend stimmt.
Alle Maßnahmen erfordern jeweils einen Compilerlauf und eine Messung mit
einem Frequenzzähler (das wäre dann die Kalibrierung). Sie sind nicht
zur Laufzeit möglich und auch nicht sinnvoll. Er hat ja keine externe
Referenz (Quarz, Quarzoszillator), sonst könnte er gleich diese als
Taktquelle nehmen und eine ausreichend genaue Sekunde erhalten.
Bei anderen Temperaturen werden sich mehr oder weniger große
Abweichungen ergeben.
Bei jedem einzelnen Prozessor ist die Prozedur erneut durchzuführen.
cd schrieb:> Die Funktion _delay_ms ist für 1s nicht spezifiziert. Der maximale Delay> in MHz beträgt 262.14 ms/F_CPU, also bei 8 MHz 31ms.
hast du auch den nächsten Satz gelesen?
When the user request delay which exceed the maximum possible one,
_delay_ms() provides a decreased resolution functionality. In this mode
_delay_ms() will work with a resolution of 1/10 ms, providing delays up
to 6.5535 seconds (independent from CPU frequency). The user will not be
informed about decreased resolution.
grundschüler schrieb:> F_CPU ist mit 8000000 angegeben. ich Möchte jetzt F_CPU kalibrieren, so> dass _delay_ms(1000) möglicht genau eine Secunde ergibt.
Verbaue einen Quarz. Der interne RC-Osc reagiert auf Temperatur- und
Spannungsschwankungen im Prozentbereich.
Und _delay_ms verlängert sich übrigens um jedweilige Interrupts, da es
diese Zyklen nicht mitzählen kann.
F_CPU ist ein Makro. Wenn man das als Variable redefiniert fliegt einem
_delay_ms() um die Ohren, denn dann ist dann eine float Berechnung drin.
Die macht der C-Optimizer nur dann raus wenn F_CPU ein konstantes Makro
ist.
HildeK schrieb:
Danke. Ich dachte schon, niemand versteht mich.
Peter II schrieb:> wie viel ist erheblich?
habe jetzt mittels kleiner Programmänderung
1
//NEC -code
2
if(ir_div>17&&ir_div<25){//nec 95
3
4
tmp1[tmp1_zl++]=tmp[1];
5
if(tmp1_zl>4)tmp1_zl=0;
6
7
8
tmp1[5]=0;
9
for(i=0;i<5;i++){
10
tmp1[5]+=tmp1[i];
11
}
12
13
lcd_goto(1,10);
14
lcd_int(tmp1[5]/5);
15
lw("x");
die Abweichung anzeigen lassen
mcu1: 7360 - mcu2:7400
Wenn mcu2 genau 8MHz hätte, hätte mcu1 einen 7956756-MHz-Takt.
Den genauen Wert bestimmen, ist sicher nicht schwierig. Einen Timer mit
definierten Werten für 8 MHz eine Stunde laufen lassen, sec+min+hou
zählen und mit der Küchenuhr vergleichen.
Mir fehlen nur die definierten Werte.
HildeK schrieb:> Er hat ja keine externe> Referenz (Quarz, Quarzoszillator), sonst könnte er gleich diese als> Taktquelle nehmen und eine ausreichend genaue Sekunde erhalten.>
Anders funktioniert Kalibrieren nunmal nicht. Ob er dabei auf die Uhr
guckt oder einen Frequenzzähler dranhängt - er benutzt einen
(Quarz-)Referenztakt.
Die Investition in einen Quarzoszillator (Quarz+Inverter+Hühnerfutter)
zum Kalibrieren von RC-Oszillatoren scheint mir auch nicht
unrealistisch.
Jim M. schrieb:> Verbaue einen Quarz. Der interne RC-Osc reagiert auf Temperatur- und> Spannungsschwankungen im Prozentbereich.
Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren. Der
1Wire-Bus basiert auf Zeitmessung. um das so genau wie möglich
hinzubekommen, brauche ich möglichst exakte Werte, die dann in #define
F_CPU eingegeben werden. Dass dann immer noch Schwankungen zu erwarten
sind, ist klar.
grundschüler schrieb:> Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren. Der> 1Wire-Bus basiert auf Zeitmessung. um das so genau wie möglich> hinzubekommen, brauche ich möglichst exakte Werte, die dann in #define> F_CPU eingegeben werden. Dass dann immer noch Schwankungen zu erwarten> sind, ist klar.
nein. Man ändert F_CPU nicht aber, sondern Kalibriert den m128!. Schau
ins Datenblatt wie das geht.
grundschüler schrieb:> mcu1: 7360 - mcu2:7400
Ist das die Abweichung, die Dir Probleme bereitet? Das sind 0,5%. Das
bekommst Du nie mit dem internen RC-Oszillator hin. Schon eine Differenz
der Versorgungsspannung beider mc's um 0,2V oder ein
Temperaturunterschied von 8 Grad bewirken eine größere Differenz.
Gruß, Stefan
grundschüler schrieb:> Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren. Der> 1Wire-Bus basiert auf Zeitmessung.
Warum brauchst Du dafür eine genaue Zeitmessung?
Ich denke, Du solltest Deinen Aufbau bzw. Vorhaben nochmal deutlich
genauer beschreiben.
batman schrieb:> Anders funktioniert Kalibrieren nunmal nicht.
Richtig, aber das Ziel war, den Prozessor nicht mit einem dauerhaft
angeschlossenen Quarz zu betreiben, sondern den internen Oszillator mit
den vorhandenen Möglichkeiten abzugleichen. Klar ist dazu irgend eine
Referenz notwendig.
Habe selber einen Tiny25 als DCF-Uhr programmiert. Er läuft mit dem
internen Oszillator, den ich für dieses Device vorher mit einem
Frequenzzähler an CKOUT mittels OSCCAL abgeglichen habe. Genau so was
schwebt dem TO wohl vor.
Gut, wenn das DCF-Signal mal 1 Stunde weg ist, dann hab ich eben ev.
einige Sekunden Ablage.
grundschüler schrieb:> mcu1: 7360 - mcu2:7400
Kommen wir doch mal zur ursprünglichen Aufgabe zurück:
Du möchtest die Zeiten zwischen Flanken messen, um das IR-NEC-Protokoll
zu decodieren.
Um das NEC-Protokoll sicher zu decodieren, ist Deine angegebene
Abweichung 7360 vs. 7400 ein Witz. IRMP verkraftet beim
NEC-Protokoll, wo sich die Pausendauern für das Bit 0 (560µs) und 1
(1690µs) erheblich unterscheiden, Abweichungen von bis zu 40% im Timing.
Es ist doch überhaupt kein Problem, zu schreiben:
1
if(dauer>7100&&dauer<7600)
2
{
3
// Bit ist gültig
4
}
5
else
6
{
7
// Bit ist ungültig
8
}
Für so ein simples IR-Protokoll braucht man weder einen Quarz noch eine
supergenaue Zeitmessung. Wenn man sich die Zeiten unter
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC
anschaut, dauert die Pause eines 1-Bits dreimal(!) so lange wie die
eines 0-Bits. Da kann man sogar noch die Temperatur um 70° schwanken
lassen, um das ohne Quarz unterscheiden zu können.
Frank M. schrieb:> Du möchtest die Zeiten zwischen Flanken messen, um das IR-NEC-Protokoll> zu decodieren.HildeK schrieb:> Habe selber einen Tiny25 als DCF-Uhr programmiert. Er läuft mit dem> internen Oszillator, den ich für dieses Device vorher mit einem> Frequenzzähler an CKOUT mittels OSCCAL abgeglichen habe. Genau so was> schwebt dem TO wohl vor.Oliver S. schrieb:> Wie genau muß denn das Timing für den 1-wire-Bus sein?
Hier scheinen deutlich unterschiedliche Vorstellungen zu kursieren, was
der TS wohl machen will ... ohne den TS kommen wir da nicht weiter.
Stefan K. schrieb:> deutlich unterschiedliche Vorstellungen
Sorry - das war mein Beispiel. Der TO hat nie von DCF geredet, nur vom
Abgleich des internen Oszillators ...
grundschüler schrieb:> Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren.
Das ist für mich eine ziemlich eindeutige Beschreibung dessen, was er
vor hat.
Oliver
HildeK schrieb:> Sorry - das war mein Beispiel.
Kein Problem, so hatte ich Dich auch verstanden und es sollte keine
Kritik sein.
Was mir nicht ganz klar ist: die Anwendungen, die sich etwas abzeichnen
(OneWire, IR-NEC-Protokoll?), benötigen nicht wirklich einen Abgleich,
weil ihr Timing dazu viel zu unkritisch ist. Gleichzeitig scheinen 0,5%
Abweichung ein Problem zu sein. Daher meine Vermutung, dass da noch
etwas anderes dahintersteckt, was hier noch nicht genannt wurde.
Viele Grüße, Stefan
grundschüler schrieb:> Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren.
Dann brauchst Du AFAIK auf beiden Seiten Quarze, damit die Kommunikation
sicher funktionert - ähnlich wie bei UART.
Hier im Forum kann man mit etwas Suchen die Leute finden bei denen der
RC Osc im kühlen Keller oder auf dem Dach so weit auseinander läuft das
die UART Kommunikation abreisst.
Stefan K. schrieb:> Hier scheinen deutlich unterschiedliche Vorstellungen zu kursieren, was> der TS wohl machen will
Ja, das stimmt... er will wohl at Runtime die Taktfrequenz seines µCs
ermitteln, indem er ein NEC-Signal einer Fernbedienung zur Kalibrierung
verwendet:
grundschüler schrieb:> Das ganze soll dann mittels einer Fernbedienung als Normal ausgemessen> werden,grundschüler schrieb:> Ich habe festgestellt dass die Zahl der Ticks in tmp[1] bei> verschiedenen m328 - alle mit 8MHz intern - und gleicher nec-fb> erheblich abweicht.
Was der TO dabei nicht beachtet: Die Sender einer IR-Fernbedienung sind
noch unzuverlässiger als sein ATMega328: Jede NEC-Fernbedienung liefert
ein abweichendes Timing - teilweise mit Abweichungen um bis zu 30%. Auch
wenn der TO die nächsten 10 Jahre dieselbe Fernbedienung zur
"Kalibrierung" nutzen wird, wird er feststellen, dass morgen bei einer
anderen Zimmertemperatur seine Fernbedienung ganz andere Werte
ausspuckt. Ich spreche da aus Erfahrung.
Eine Infrarot-Fernbedienung zur Kalibrierung zu nutzen ist einfach
Unsinn.
HildeK schrieb:> Sorry - das war mein Beispiel. Der TO hat nie von DCF geredet, nur vom> Abgleich des internen Oszillators ...
Nein, er hat von "Kalibrierung" gesprochen.
Es bedeutet nicht "Abgleich", sondern nur "Messen":
https://de.wikipedia.org/wiki/Kalibrierung
Oliver S. schrieb:> Das ist für mich eine ziemlich eindeutige Beschreibung dessen, was er> vor hat.
Dazu passt aber der Anfangspost nicht. Und wenn das das Problem ist,
dann ist die Anwort sehr einfach. Eine Kalibration ist dann schlicht
überflüssig.
Gruß, Stefan
Jim M. schrieb:>> Ich habe zwei AVRs, die per 1Wire miteinander kommunizieren.>> Dann brauchst Du AFAIK auf beiden Seiten Quarze, damit die Kommunikation> sicher funktionert - ähnlich wie bei UART.
Oder auch nicht. Da werden Sync Flanken pro Bit vom Master gesendet, das
hatte ich vergessen.
Oliver S. schrieb:> Er will halt kalibrieren
Nochmal !!! (siehe oben)
Kalibrieren heißt in etwa "messen" und nicht abgleichen, einstellen,
justieren, etc.
Die Programmieradapter von Atmel (z.B. ISP MkII) unterstützen eine
Abgleichprozedur, bei der ein einzelner µC in der Zielschaltung mit
einem Quarz im Programmieradapter verglichen und korrigiert wird.
Der dazu nötige Korrekturwert für das OSCCAL Register wird dabei im
EEPROM Abgelegt. Danach musst du dein Programm so ändern, daß es diesen
Wert beim, Start liest und in das OSCCAL Register rein schreibt.
Soweit ich weiß, werden alle AVR Mikrocontroller schon ab Werk
kalibriert geliefert. Diese Prozedur macht daher nur Sinn, wenn bei Dir
die Versorgungsspannung oder Temperatur abweicht. Im Datenblatt findest
du die konkreten Bereiche, für die im Werk kalibiert wird.
Aber wie gesagt nützt das wenig, wenn die Versorgungsspannung oder die
Temperatur nicht konstant sind. R/C Oszillatoren sind halt Prinzip
bedingt nicht sehr stabil.
Jim M. schrieb:> Dann brauchst Du AFAIK auf beiden Seiten Quarze, damit die Kommunikation> sicher funktionert - ähnlich wie bei UART.
Der OneWire Bus ist wesentlich toleranter gegen Timingschwankungen als
eine UART-Kommunikation. Er ist ja speziell entworfen für die
Kommunikation mit Minimal-Chips.
Viele Grüße, Stefan
justy schrieb:> Kalibrieren heißt in etwa "messen" und nicht abgleichen, einstellen,> justieren, etc.http://www.duden.de/rechtschreibung/kalibrieren
Bei zwei von den drei Beduetungen beinhaltet es sehr wohl auch
einstellen bzw. abgleichen.
Oliver
Zudem möchte er eine IR-Fernbedienung zum Kalibrieren benutzen.
Der Punkt ist einfach, dass der TO nicht F_CPU verändern soll, sondern
OSCCAL verändern muss. Dazu braucht er eine Referenz, und die ist die
IR-Fernbedienung.
Also einfach die Zeit messen, die von der FB kommt, und dann ein
bisschen am Oszillator spielen. Das ganze so lange, bis die Zeit stimmt.
Setzt übrigens voraus, dass die Fernbedienung genauer ist als der RC des
Controllers. Ich vermute, dass das nicht unbedingt garantiert ist (oder
sind alle Fernbedienungen quarzstabilisiert?).
justy schrieb:> Kalibrieren heißt in etwa "messen" und nicht abgleichen, einstellen,> justieren, etc.
Toll, und er wills abgleichen. Gemäß Duden ist das auch völlig korrekt
ausgedrückt, Herr Deutschlehrer:
"Kalibrieren
(..)
(von Messgeräten, ihren Funktionen o. Ä.) durch Vergleichen bestimmter
Messdaten mit geeichten Normalen kontrollieren, prüfen und mit der Norm
in Übereinstimmung bringen"
Stefan U. schrieb:> Erzähle das den Autoren der Application Note.
Warum, in der AN ist es korrekt verwendet.
Stefan U. schrieb:> Vielleicht werden die> Begriffe in deutsch und englisch etwas unterschiedlich verwendet.
Genau.
Da die obigen Texte in Deutsch verfasst sind, sorgt die mehrfach falsche
Verwendung eher für Verwirrung.
Stefan U. schrieb:>> Kalibrieren heißt in etwa "messen" und nicht abgleichen,>> einstellen, justieren, etc.>> Erzähle das den Autoren der Application Note. Vielleicht werden die> Begriffe in deutsch und englisch etwas unterschiedlich verwendet.
Zitat Wikipedia:
"Der Begriff Kalibrierung wird häufig mit den nicht synonymen
Wörtern Eichung, Konformitätsaussage, Spezifikationsprüfung,
Abgleich, Justierung oder Zertifizierung verwechselt, zur Abgrenzung
siehe unten."
[...]
"Ein Abgleich oder eine Justierung kann im Anschluss an eine
Kalibrierung und eine Konformitätsprüfung erfolgen (wenn z.B.
die festgestellte Abweichung unzulässig hoch ist), ist aber
nicht zwingender Bestandteil. Nach jeder Justierung muss eine
erneute Kalibrierung stattfinden, weil durch die Änderung am
Messgerät eine vorher durchgeführte Kalibrierung bedeutungslos wird."
ich will eigentlich nur wissen, wie meine MCU wirklich taktet. Das ist
wie beim Autofahren: Tacho 120 ist tatsächlich nur 112. Manchem ist das
egal - ich kenne halt gerne die Abweichung. IR und 1Wire funktioniert
sicher auch mit 5% Abweichung. Ich habe im Programm einen F_CPU Wert von
genau 8MHz stehen. Auf der Taktfrequenz basieren die Timer, mit denen
bei mir ein smh-Signal generiert wird und die delays, die manchmal
wichtig sind -manchmal auch nicht.
DIe 8MHz werden wahrscheinlich nie genau stimmen. Ob ich den Wert jetzt
ändere oder den tatsächlichen Wert -bei bestimmten Bedingungen- als
Kommentar dahinterschreibe weiß ich noch nicht. Vielleicht sind die
Abweichungen auch so groß, dass ich dann auf externen Quartz umstelle.
Ich will nur wissen was ich mache und deswegen den Takt genauer
bestimmen als die Atmel-Vorgabe von 8MHz.
Danke jedenfalls für die zahlreichen Beiträge.
justy schrieb:> Da die obigen Texte in Deutsch verfasst sind, sorgt die mehrfach falsche> Verwendung eher für Verwirrung.
Siehe Duden ( http://www.duden.de/rechtschreibung/kalibrieren ):
- das Kaliber bestimmen, messen
- (besonders von Werkstücken) auf ein genaues Maß bringen, ausrichten
auf eine einheitliche, genormte Größe bringen
- (von Messgeräten, ihren Funktionen o. Ä.) durch Vergleichen bestimmter
Messdaten mit geeichten Normalen kontrollieren, prüfen und mit der
Norm in
Übereinstimmung bringen
Nach Duden und nach meinem Verständnis ist die Verwendung des Wortes
auch in Deutsch für diesen Vorgang zulässig.
Außer dir hat jeder verstanden, was gemeint war.
grundschüler schrieb:> Ich habe im Programm einen F_CPU Wert von> genau 8MHz stehen. Auf der Taktfrequenz basieren die Timer, mit denen> bei mir ein smh-Signal generiert wird und die delays, die manchmal> wichtig sind -manchmal auch nicht.
Wichtig zu wissen: mit einem modifizierten Wert für F_CPU kannst du die
_delay_ms anpassen, nicht aber die Timer.
grundschüler schrieb:> ich will eigentlich nur wissen, wie meine MCU wirklich taktet.
Dann programmiere die CKOUT-Fuse und schließe einen Frequenzzähler an
PB0 (CLKO) an. Da kommt der Systemtakt direkt raus.
> DIe 8MHz werden wahrscheinlich nie genau stimmen.
Vor allem sind sie nicht konstant!
Was immer du misst, gilt nur in diesem Augenblick, bei dieser
Temperatur, bei dieser Versorgungsspannung. Den systematischen Fehler
kannst du da auch rausrechnen (z.B. durch Messen der Temperatur), bis zu
einem gewissen Punkt.
> Ich will nur wissen was ich mache und deswegen den Takt genauer> bestimmen als die Atmel-Vorgabe von 8MHz.
Du kannst mit dem RC für bestimmte Randbedingungen recht genau werden,
indem du den Oszillator softwareseitig nachstellst. Dazu brauchst du
aber eine Referenzquelle, die in jedem Fall genauer sein muss, als der
verbaute RC.
Deinen Autotacho wirst du sicherlich auch nicht mit Straßenschildern und
Armbanduhr justieren.
Hi
>Die Programmieradapter von Atmel (z.B. ISP MkII) unterstützen eine>Abgleichprozedur, bei der ein einzelner µC in der Zielschaltung mit>einem Quarz im Programmieradapter verglichen und korrigiert wird.
Habe ich da irgend etwas verpasst? Von einem derartigen Abgleich ist mir
nichts bekannt. Der ISP kann den zwar den werksseitig ermittelten Wert
auslesen und im EEPROM oder Flash speichern. Von dort muss das Programm
den Wert ins OSCCAL-Register Schreiben.
MfG Spess
Frank M. schrieb:> Eine Infrarot-Fernbedienung zur Kalibrierung zu nutzen ist einfach> Unsinn.
Du bist mit deinen Aussagen manchmal etwas drastisch. Zwei AVRs auf den
Tisch, FB 5x klicken. Der von den beiden mcus angezeigte Wert gibt das
Verhältnis der Taktfrequenzen dann ziemlich exact wieder. Also kein
Unsinn.
Habe meinen Timer jetzt mal berechnet:
1
voidinit_timer_smh(void){
2
/*
3
cs02+01+00:
4
0 no clock
5
1 no presc
6
2 /8
7
3 /64
8
4 /256
9
5 /1024
10
*/
11
12
TCCR0A|=(1<<WGM01);
13
// 1; Timer0 Vorteiler: 64 -> bei 16 MHz:
14
// 16.000.000 / 64 = 250000 Mal pro Sek gibts einen Takt an den Timer
15
// 8.000.000 / 1024 = 7812 Mal pro Sek gibts einen Takt an den Timer
16
TCCR0B|=((1<<CS02)|(1<<CS00));//1024
17
18
// Timer0 soll bei 250 einen Output Compare Interrupt ausl?sen ->
19
// 250.000 / 250 = 1000 mal pro Sek gibts einen Interrupt
20
// 7812 /78 = 100 mal pro Sek gibts einen Interrupt
21
OCR0A=78;//abgleich mit uhr
22
23
//7812/78 =>9,9846ms
24
//planmäßige Abweichung zu 60x60sec => 3594,4700460829493087557603686636
25
26
27
28
//Compare Interrupt aktivieren
29
TIMSK0|=(1<<OCIE0A);
30
31
//Globale Interrupts aktivieren
32
sei();
33
}
Planmäßige Abweichung wären 5,5 sec je Stunde. Aufgrund der
tatsächlichen Abweichung müsste man dann die Taktfrequenz ziemlich genau
berechnen können.
Hi
>Ja hast du. Und zwar die Application Note. Hier nochmal der Link für>dich:>http://www.atmel.com/Images/Atmel-2555-Internal-RC...
Ok. Habe ich zwar in meiner AppNotes-Sammlung. Aber Irgenwie ignoriert.
>Und du solltest Du mal die zugehörigen Menüpunkte im Atmel Studio>anschauen, während einer der genannten Programmieradapter angeschlossen>ist.
Atmel Studio habe ich zwar, weil ich ATSAME70Q19 programmieren muss.
Aber normalerweise bin ich mit dem AVR Studio 4 unterwegs. Muss ich
morgen mal in der Firma nachsehen.
MfG Spess
Hi
>Auch das AVR Studio 4.19 hat eine entsprechende Funktion in der GUI.>Sieht zumindest so aus - ich habe sie nie benutzt.
Auch im 7er Studio gibt es nur den Punkt 'Oscillator Calibration' (siehe
Anhang). Und der liest auch nur per ISP das Calibration Byte aus und
speichert es im EEPROM bzw. Flash. Da ist, genau wie im 4er Studio,
nichts mit messen.
MfG Spess
Ja, im AVR Studio 4.19 sieht der Dialo prinzipiell genau so aus. Die
Eingabefelder und Buttons sind lediglich ein bisschen anders angeordnet.
> Da ist, genau wie im 4er Studio, nichts mit messen.
Schade. Dann muss man wohl wirklich das Kommandozeilen-Tool verwenden.
Oder sich eine eigene Methode ausdenken.
Ich frage mich allerdings, wozu dann die Drop-Down Liste "Calibrate for
8Mhz" dient?
Stefan U. schrieb:> Ich frage mich allerdings, wozu dann die Drop-Down Liste "Calibrate for> 8Mhz" dient?
Da kannst du auswählen, bei welcher Frequenz du kalibrieren möchtest.
Ich hab mal irgendwo (Datenblatt/Application note) gesehen, daß der
interne RC mehrere Abgleichpunkte hat für verschiedene Frequenzen hat.
Hi
>Ich hab mal irgendwo (Datenblatt/Application note) gesehen, daß der>interne RC mehrere Abgleichpunkte hat für verschiedene Frequenzen hat.
Genau. Z.B. haben die ATTiny25/45/85 normal einen 8MHz Oszillator. Wenn
der 'ATtiny15 compatibility mode' gesetzt ist, einen 6,4MHz Oszillator.
Für beide Modes gibt es unterschiedlich Calibration Bytes.
MfG Spess
