Forum: Mikrocontroller und Digitale Elektronik Tiny13: RC Oszillator kalibireren


von Jürgen Broß (Gast)


Lesenswert?

Hallo zusammen,

laut Datenblatt ATTiny13 ist der interne RC-Oszillator auf 9.6MHz bei
3V Versorgungsspannung und 25 Grad C Umgebungstemperatur mit einer
Genauigkeit von + - 10% kalibriert.

Ich möchte den Oszillator nun für 9.6MHz bei 5V, 25 Grad C auf + - 3%
kalibrieren. Der verwendete Chip trägt die Aufschrift ATTINY13 20PU.
Ich verwende das STK500 und AVR Studio 4.11 SP2.

Zum Thema habe ich die Application Note AVR053 "Calibration of the
internal RC oscillator" auf der Atmel Website gefunden. In der AA
steht "The calibration code is written in assembly, for the AVR Studio
4.11 assembler with the calibration package installed." und weiter
"All required changes are made in the root file “RC_Calibration.asm”
when calibrating using the AVR Tools.". Leider finde ich weder bei mir
auf dem Rechner noch auf der Atmel Website dieses "calibration
package" und die Datei "RC_Calibration.asm". Hat das schon mal
jemand von euch gefunden, installiert und benutzt?

Ich habe leider kein Oszilloskop zur Verfügung. Welche Methoden zur
Bestimmung des korrekten Wertes des Kalibrationsbytes verwendet ihr?

Viele Grüße

Jürgen

von Jörn G. aus H. (Gast)


Lesenswert?

Die Apikation Note beschreibt vor allem, wie man das Calibrieren so
einfach gestalten kann, dass man es auch in der Produktion machen
kann.

Bei nur einem AVR (und ohne Oszi) ist es einfacher, du programmierst
dir einfach einen Zähler, der schön lange zählt und misst die Zeit und
probierst dann verschiedene OSCAL Werte aus.

Besser ist es natürlich mit einem Freuqenzmesser oder Oszi und dann ein
einfaches Programm (immer in Assembler!).

Z.B. Pin High, dann 10 x NOPs, dann Pin low, wieder NOPS und
rücksprung. Assembler - weil du dann genau abzählen kannst, wie lang
die Befehle dauern und dir einen exakten Takt programmieren kannst.

Die Frequenz misst du dann einfach (können auch viele Multimeter) und
probierst wieder mit dem OSCCAL rum.

jörn

von Jürgen Broß (Gast)


Lesenswert?

Hallo Jörn,

vielen Dank für deinen Vorschlag. Ich werde das mal ausprobieren.

Viele Grüße

Jürgen

von Jürgen Broß (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe jetzt mal ein kleines Programm (siehe Anhang) geschrieben, das
LED0 (PB0) auf dem STK500 für toggelt. Laut Simulator benötigt die
Schleife 65280 Zyklen mit (0<<CS02)|(0<<CS01)|(1<<CS00), also clk/1
(sonst dauert es ewig im Simulator). Auf dem Chip benütze ich aber
clk/1024. Mal kurz nachrechnen: 9.6MHz/8=1.2MHz == 0.833µs (/8 wegen
Clock-Vorteiler). Da nur der Timerüberlauf gezählt wird und dieser nach
256 Counts stattfindet gilt: 0.833µs  256  1024 = 0.2184s. In Zeile 86
nehme ich dies mal 229 und komme so auf die oben angegebenen 50.0136s.
Je nachdem mit welcher Genauigkeit der Taschenrechner rechnet bekommt
man leicht unterschiedliche Rechenergebnisse.

Mit dem durch Atmel kalibrierten RC Oszillator habe ich im Durchschnitt
per Handstoppung 51,8s Laufzeit gemessen (bei 9.8MHz und 5V VCC. Das
ergibt einen Fehler von +3,6%. Das ist für meine Anwendung
ausreichend.

Grüße

Jürgen

von KOL (Gast)


Lesenswert?

Hallo,

kan mir vielleicht irgend jemand helfen...?

ich habe einen Oszillator in Basisschaltung... und jetzt muss ich
irgendwie Frequenzmodulation mit einem Oszilloskop sichtbar machen...

danke im voraus!!!

von Der Auserwählte (Gast)


Lesenswert?

Und wo ist da jetzt der Zusammenhang mit dem Posting, auf das du
antwortest?

von Michael (Gast)


Lesenswert?

Hi,

ich hab beim Tiny15 den RC Oszillator kalibriert. Das sollte ähnlich
wie beim Tiny13 funktionieren:

Beim Herunterladen des Programms in den Flash kann man im AVR Studio
die Registerkarte Advanced auswählen. Dort die gewünschte Frequenz
einstellen und "read Cal. Byte" klicken. Dann hast du den bei der
Produktion ermittelten Wert da stehen. Den kannst du dann ins E² oder
in den Flash schreiben (Speicherstelle angeben). Das Hauptprogramm muss
dann den Wert lesen (unter der eingestellten Speicherstelle) und ins
OSCCAL-Register schreiben. Fertig.

Gruß,
Micha

von Jürgen Broß (Gast)


Lesenswert?

Hallo Michael,

Danke für den Typ wie's beim Tiny15 gemacht wird. Hast du die
Abweichung mal bei deinem Tiny15 nachgemessen?

Beim Tiny13 ist es meinem Verständnis nach etwas anders. Im Datenblatt
des Tiny13 steht: "During reset, hardware loads the calibration byte
into the OSCCAL Register and thereby automatically calibrates the RC
Oscillator." Ich verstehe das so, daß ich das calibration byte nicht
ins FLASH oder EEPROM schreiben muß und es von da vom Pogramm auslesen
und ins OSCCAL Register schreiben muß sondern daß dies automatisch ohne
mein zutun durchgeführt wird. Oder verstehe ich das doch falsch?

Nichts desto trotz heißt es im selben Datenblatt weiter: "At 3V and
25°C, this calibration gives a frequency within ± 10% of the nominal
frequency." Das ist ein ganz schön großer Bereich, vor allem für eine
serielle Datenübertragung. Deshalb hatte ich mir das kleine Programm
geschrieben um mal zu sehen, welche Toleranz die Frequenz jetzt
wirklich hat.

Grüße

Jürgen

von Michael (Gast)


Lesenswert?

Hallo Jürgen,

stimmt, du hast recht. Bei Oszillatoren der Version 4.x wird das
Calibration Byte automatisch für die Default-Frequenz geladen. Damit
bekommt man dann 10% Genauigkeit, wie du geschrieben hast. Das gibts
beim Tiny15 nicht. Da musste man das selber machen und hatte dann aber
1% Genauigkeit. Der Tiny26, auf den ich jetzt umgestiegen bin
callibriert sich auch selber, sofern man die Grundfrequenz verwendet.
Die Genauigkeit soll dann 3% sein. Für eine Motorregelung
(Phasenanschnitt) reicht das aus, deshalb hab ich mich nicht weiter
darum gekümmert. Sorry...

Schon erstaunlich, dass Atmel beim 13er so ungenau kalibriert.
Aber mit deinem Testprogramm müsste es doch möglich sein, durch
probieren, ähnlich wie Jörn es vorgeschlagen hat, eine bessere
Genauigkeit (<10%) hin zu bekommen.

Viel Erfolg!
Gruß,
Michael

von Jürgen Broß (Gast)


Lesenswert?

Hallo Michael,

es beruhigt mich doch ungemein, daß du die Beschreibung genauso
verstehst wie ich. Ich hab' schon an meinen Englischkenntnissen
gezweifelt.

Im Moment versuche die Kalibrierung komplett zu vermeiden da ich diese
einfach als extrem lästig empfinde. Das verwendete serielle Protokoll
legt zu Beginn für 100 oder 150µs low auf die Leitung, die Toleranz
habe ich auch mal mit +-10% angenommen. Ich werde versuchen diese
Spanne per Pin Change Interrupt auszumessen und dann diesen Timerwert
für die folgenden 20 Bits (Bitdauer 50µs) verwenden. Dann bin ich
unabhängig von der Toleranz meines Empfängers und des Senders. Auf die
Toleranz des Senders habe ich ohnehin keinen Einfluß da es ein Kaufteil
ist.

Ich melde mich wieder wenns geklappt hat (oder natürlich wenn es doch
nicht funktioniert wie gedacht).

Grüße

Jürgen

von Philipp Sªsse (Gast)


Lesenswert?

Darf ich mich hier mal dranhängen?

Ich habe einen tiny13, der ein Graphikdisplay über Soft-UART ansteuert
und stieß dabei auf den verflixt großen Toleranzbereich des internen
Oszillators ... und fand diesen Thread.

Ich habe das Handbuch ebenfalls so begriffen, daß das OSCCAL
automatisch geschrieben wird und frage mich nur: warum ermittelt Atmel
das Kalibrierungsbyte nicht besser? Wenn die sich schon die Mühe
machen, da ein Kalibrierungsbyte reinzuschreiben und dieses Byte
0,5%-Schritte zuläßt, warum messen sie dann nicht gleich vernünftig?
Das ist für die doch wesentlich weniger Aufwand als für unsereinen?!

Jetzt versuche ich mal eine Routine, die ein einzelnes Startbit sendet
und anhand des Fehlercodes, der zurückkommt, die korrekte Kalibrierung
berechnet (erschlägt dann auch Temperatureffekte). So erspare ich mir,
jeden tiny händisch durchzumessen. Ich hoffe nur, ich finde den Platz
dafür, denn das Flash ist schon halb voll komprimierter Bitmaps und der
Rest reicht gerade für die Ansteuerung ... so ein Mist hat mir noch
gefehlt!

von Joern G. aus H. (Gast)


Lesenswert?

Wozu sollten die genauer messen, wenn der Wert z.B. von der Temperatur
abhängt, die sicher bei dir erstens nicht konstant und zweitens nicht
identisch zum Atmel Labor ist?!

Daher kalibiriert man eben genauer selber unter den gewünschten
Umgebungsbedingungen.

Am allerbesten ist es natürlich man kalibriert jedesmal zum Startup des
Controllers - natürlich benötigt man dann wiederum eine Taktquelle.
Komisch? Nö, denn trotzdem kommt dieser Fall oft vor, z.B. wenn man
eine Echtzeituhr benötigt, also dafür sowieso einen 32kHz Quarz, dann
braucht man nicht noch zusätzlichen einen 2. Quarz, sondern kann damit
den internen kalibrieren.

Gemacht wird das z.B. im Atmel Butterfly, den Quellcode dazu gibt es ja
frei im Netz. Seht euch das dort an.

Manche nehmen auch das DCF SIgnal zum kalibirieren.

jörn

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
Noch kein Account? Hier anmelden.