Hallo Forum, ich habe gerade eine Beobachtung gemacht, die ich mir nicht so recht erklären kann. Zwei ATMega328 mit identischer Firmware und identischen Fuses lassen jeweils alle 8 Sekunden eine LED blitzen. In der Firmware verwende ich dazu den Timer0, dessen Interrupt alle 1ms auslöst und eine uint32 Variable hochzählt. Im Grunde der millis() Funktion des Arduinos nachempfunden. Doch bereits nach ca. 30 Sekunden blitzen die beiden LEDs deutlich zeitversetzt. Nach 2 Minuten schon fast im Wechseltakt. Beide Controller hängen an der gleichen Spannungsquelle und werden zeitgleich eingeschaltet. Der interne Oszilator kann doch nicht sooo ungenau sein, oder doch? Beide Controller stammen aus der selben digikey Bestellung. Es kommt zwar überhaupt nicht drauf an, dass die synchron laufen oder hochgenau sind, etc... aber so ein Verhalten ist mir schon ein Rätsel. Wo könnte ich nach der Ursache suchen? Vielen Dank, Mike
> Wo könnte ich nach der Ursache suchen?
Im Datenblatt, Unterkapitel 'Calibrated Internal RC Oscillator
Accuracy'.
Dynamike schrieb: > Der interne Oszilator kann doch nicht sooo ungenau sein, oder doch? Im Datenblatt steht nicht ohne Grund "approximate 8.0MHz". Der Wert kann im Bereich 7.3 - 8.1MHz verändert werden. Stehen in den OSCCAL-Registern vernünftige Kalibierwerte? Durch Abgleich sind bis zu 5% Abweichung möglich.
> alle 8 Sekunden eine LED blitzen > Nach 2 Minuten schon fast im Wechseltakt Also rund 3 % - ist doch prima!
Bei Attinys ist es aus meiner Erfahrung noch deutlich schlimmer, die kann man quasi schon als VCO einsetzen ;)
Wolfgang schrieb: > Im Datenblatt steht nicht ohne Grund "approximate 8.0MHz". > Der Wert kann im Bereich 7.3 - 8.1MHz verändert werden. > Stehen in den OSCCAL-Registern vernünftige Kalibierwerte? > > Durch Abgleich sind bis zu 5% Abweichung möglich. Das ist zumindest ziemlich falsch formuliert, eigentlich aber kompletter Nonsense. 1) OSCCAL wird bei allen AVR8 automatisch durch werksseitig kalibrierte Werte vorbelegt. Die gelten allerdings ggf. nur für bestimmte Vorgaben von Vcc. Weicht die tatsächliche Versorgung davon ab, muß man nachbessern. Bei manchen (alten) AVR8 gibt es deshalb weitere Parametersätze für von der Vorgabe abweichende Werte von Vcc. Diese müssen aber von der Anwendung selber appliziert werden. Bei "neueren" AVR8 konnte Atmel die Abhängigkeit der Frequenz des internen Oszillators von der Versorgungsspannung ganz erheblich reduzieren, insbesondere so weit, dass diese zusätzlichen Parametersätze nicht mehr nötig waren. Hier genügt also unabhängig von Vcc immer der automatisch geladenen Default-Wert für OSCCAL, um die im DB angegebenen Fehlergrenzen für den internen RC-Oszillator einzuhalten. 2) Das Hauptproblem aller moderneren AVR8 ist die nach wie vor recht hohe Abhängigkeit des internen RC-Oszillators von der Temperatur. Es ist jederzeit möglich, unter Benutzung des OSCCAL-Registers auf besser 1% zu kalibrieren. Aber eben nur für eine bestimmte Temperatur. Sehr viele AVR8 bieten allerdings auch eine Messung dieser Temperatur (und der weniger wichtigen Versorgungsspannung). Benutzt man diese Features, ist es möglich, die Frequenz des RC-Oszillators zur Laufzeit über den gesamten erlaubten Bereich von Vcc und Temperatur auf besser 1% zu halten. Das erfordert allerdings leider eine "pro Exemplar"-Kalibrierung des Kennlinienfelds. Reichen 3%, dann geht es auch ohne. Man muss halt einfach nur wissen, was man tut...
Dynamike schrieb: > Es kommt zwar überhaupt nicht drauf an, > dass die synchron laufen oder hochgenau sind, etc... > aber so ein Verhalten ist mir schon ein Rätsel. Ich übersetze: Du hättest gerne ein Problem. Wenn es nicht darauf ankommt, dass sie synchron laufen: Finde Dich damit ab, freilaufende Oszillatoren sind eben so. Fals sie doch synchron laufen sollen, verwende eine gemeinsame Taktquelle. In zwei Minuten ist Freitag, der passende Tag für solcherlei Fragen.
c-hater schrieb: > Benutzt man diese Features, ist > es möglich, die Frequenz des RC-Oszillators zur Laufzeit über den > gesamten erlaubten Bereich von Vcc und Temperatur auf besser 1% zu > halten. Um einen Quarz für ein paar Cent einzusparen?? c-hater schrieb: > Man muss halt einfach nur wissen, was man tut... Ja, allerdings. c-hater schrieb: > Das erfordert allerdings leider eine "pro Exemplar"-Kalibrierung > des Kennlinienfelds Dafür kann man ganze Tüten voll Quarze kaufen. Aber wenn man einfach nichts gescheites zu tun hat... Georg
georg schrieb: > Um einen Quarz für ein paar Cent einzusparen?? Ja! 90% der Anwendungen laufen auch so.
georg schrieb: > Um einen Quarz für ein paar Cent einzusparen?? Das ist zumindest ein nützlicher Nebeneffekt. Viel wichtiger ist aber oft: Energie sparen. Das Problem bei Quarzen ist nämlich: sie brauchen ziemlich lange, bis sie einen stabilen Takt liefern können. Der RC-Oszillator ist hingegen fast sofort bereit. Die Runtime-Kalibrierung des Oszillators kostet dann zwar auch noch etwas Zeit, die Sache ist aber insgesamt immer noch viel schneller erledigt, als der Startup eines Quarz. > c-hater schrieb: >> Das erfordert allerdings leider eine "pro Exemplar"-Kalibrierung >> des Kennlinienfelds > > Dafür kann man ganze Tüten voll Quarze kaufen. Nö. Das muss halt einfach einmal programmiert werden und läuft dann in der Fertigung vollautomatisch im Anhang zur sowieso notwendigen Programmierung. Jeder, der wirklich Ahnung hat, kriegt sowas gebacken. Du gehörst da wohl nicht dazu...
Gerade bei Controllern die nur mit wenigen Pins daherkommen stoert ein zusaetzlicher Quarz/Piezoresonator. Da nehme ich doch lieber selbst uralte PICs, die das schon gefuehlt ewig besser koennen. Denen ist sowohl die Temperatur als auch die Spannung fast egal. Dazu muss man aber mal ueber den Tellerrand schauen. Da haben wohl viele Angst herunterzufallen.
edcrfv schrieb: > Da nehme ich doch lieber selbst uralte PICs, die das schon > gefuehlt ewig besser koennen. Nein wenns darauf ankommt nimmt man einen aktuellen Mega oder Tiny. Quarz ist heute selten nötig, die Genauigkeit langt (just von einer Uhr abgesehen) für die meisten Anwendungen. MCs sind auch nicht dazu da sie im Timing nebeneinander zu vergleichen.
c-hater schrieb: > Das ist zumindest ziemlich falsch formuliert, eigentlich aber kompletter > Nonsense. Ja, ja - für dich Fehlabgleich. Nicht ohne Grund hatte ich gefragt: Wolfgang schrieb: > Stehen in den OSCCAL-Registern vernünftige Kalibierwerte? Vielleicht hast du das auch inhaltlich erfasst? ;-)
> nimmt man einen aktuellen Mega oder Tiny
Voellig ueberteuerter 8 Bit Schnarpel.
Mehr als 50 Ct sind 8 Bit nicht mehr Wert.
Wolfgang schrieb: > Nicht ohne Grund hatte ich gefragt: > Wolfgang schrieb: >> Stehen in den OSCCAL-Registern vernünftige Kalibierwerte? > > Vielleicht hast du das auch inhaltlich erfasst? ;-) Diese Frage hat er dir doch beantwortet: Zitat "OSCCAL wird bei allen AVR8 automatisch durch werksseitig kalibrierte Werte vorbelegt." Im weiteren nannte er die Randbedingungen. Das ganze könntest du übrigens auch im Datenblatt nachlesen... Franz
Hallo, vielen Dank für eure Hinweise. Ich muss gestehen, dass ich den internen Oszillator bisher kaum verwendet habe und ihm deshalb auch keine Aufmerksamkeit zukommen ließ. Wenn ich OSCCAL auslese, dann hat einer 0x90, der andere 0xFA. Und wenn ich per CKOUT-Fuse den Takt auf einem Pin ausgebe und mit einem Oszi ;) messe, dann zählt der Controller 7.39MHz und der andere 8.05MHz. Das ist natürlich schon ein Unterschied. Hätte ich nicht gedacht. Vielen Dank für Eure Hilfe dazu. Mike
edcrfv schrieb: > ueberteuerter Hat der TO nach der Genauigkeit gefragt oder nach dem Preis? Kann man das irgendwie verwechseln? Das Kunststück hast du geschafft!
edcrfv schrieb: > Voellig ueberteuerter 8 Bit Schnarpel. > Mehr als 50 Ct sind 8 Bit nicht mehr Wert. In dem Preisbereich bewegen sie sich auch. Überhaupt sind die neuen Typen viel preiswerter als die alten.
Bitte 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.