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???
Bist du sicher, das es nicht an einer ISR liegt die das delay verzögert. Der interne Takt ist schon recht genau. Wie groß ist deine Abweichung?
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.
Nachtrag: Wenn überhaupt, dann muss du die Frequenz vom AVR kalibrieren, den wert von F_CPU anzupassen bringt bei diese Code überhaupt nichts.
F_CPU ist via Makro definiert und kann zur Laufzeit gar nicht geändert werden.
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.
:
Bearbeitet durch Moderator
Im Prinzip einen Timer intern (RC) und einen extern (Quarz) takten und nach einem Durchlauf (IRQ) die Abweichung bestimmen und kompensieren.
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.
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. Dass da immer > Ungenauigkeiten bleiben, ist mir klar http://www.atmel.com/webdoc/avrlibcreferencemanual/group__util__delay_1gad22e7a36b80e2f917324dc43a425e9d3.html 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.
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
Wie genau muß denn das Timing für den 1-wire-Bus sein? Denn wie schon geschrieben wurde, der interne Oszillator schwankt mit der Temperatur. Oliver
:
Bearbeitet durch User
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.
Hi
>Mir fehlen nur die definierten Werte.
CKOUT-Fuse setzen und Messen.
MfG Spess
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.
:
Bearbeitet durch Moderator
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.
Doch, der Anfangspost passt schon. Er will halt kalibrieren, weil er meint, das für den 1-wire-Bus unbedingt zu brauchen. Oliver
:
Bearbeitet durch User
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.
Beitrag #5081526 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
Hier ist das die Application Note zu der von Atmel empfohlenen Prozedur: http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf > 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.
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
:
Bearbeitet durch User
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
> sind alle Fernbedienungen quarzstabilisiert?
IR Fernbedienungen enthalten meistens einen Keramik Resonator.
>>Die Programmieradapter von Atmel (z.B. ISP MkII) unterstützen eine >>Abgleichprozedur... > Habe ich da irgend etwas verpasst? Ja hast du. Und zwar die Application Note. Hier nochmal der Link für dich: http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf Und du solltest Du mal die zugehörigen Menüpunkte im Atmel Studio anschauen, während einer der genannten Programmieradapter angeschlossen ist.
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 | void init_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.
Angehängte Dateien:
-
Unbenannt.png
32 KB
Diese Kalibrierfunktion ist sogar schon in der GUI vom alten AVR Studio enthalten:
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
Auch das AVR Studio 4.19 hat eine entsprechende Funktion in der GUI. Sieht zumindest so aus - ich habe sie nie benutzt.
Angehängte Dateien:
-
Calibration.PNG
19 KB
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.
Angehängte Dateien:
-
Calibration2.PNG
17 KB
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
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.