AVR ATmega 8: Interner RC-Oszillator läuft viel zu schnell

Aug 05, 2005 10 Replies

Ich habe ein seltsames Problem: Ich habe eine Schaltung mit einem ATmega 8 entwickelt. Da Platz eingespart werden muß, soll die Schaltung mit dem internen RC-Oszillator bei 8 MHz laufen. Auf einem STK500 Board läuft das alles auch einwandfrei.



Nun habe ich eine kleine Platine entwickelt, auf der ein ATmega8 im TQFP Gehäuse sitzt. Wenn ich diese eigentlich korrekt programmiere, also die Fuses entsprechend einstelle und auch das 8 MHz Kalibrationsbyte auslese und durch mein Programm in OSCCAL schreiben lasse, dann scheint das Teil nicht mit 8 MHz sondern deutlich schneller zu laufen.



Folgender Programmcode sollte eigentlich einmal pro Sekunde eine Portleitung umschalten:



for(;;) { PORTD ^= 2; for (uint8_t x=0; x


"Michael Holzt" schrieb im Newsbeitrag news: snipped-for-privacy@mir.nadeshda.org...

Portleitung

Ich

12 Mhz geht eigentlich nur, wenn man 8 Mhz einstellt und mittels OSCCAL den Takt weiter hochsetzt. Versuch doch mal rauszukriegen, in welchem Bereich sich der Takt mit OSCCAL ziehen lässt. Im Datenblatt auf Seite 276 ist ein "Clock vs OSCCAL"-Diagramm drin.

-Klaus-

Ich glaube mich daran zu erinnern, dass bei 8MHz nur maximal 35ms Verzögerung mit _delay_ms erreichbar ist. Kuck mal ins Header-File - da steht es nochmal genau drin.

Mfg Thomas Pototschnig

formatting link

"Thomas Pototschnig" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Um das zu testen würde ich dann 5 * _delay_ms(10) versuchen...

-Klaus-

Oder am besten eine Int-Routine Schreiben, die einen Port-Pin toggelt. Dann diese durch einen Timer-Overflow X-Mal in der Sekunde aufrufen und mit Oszi messen.

cu,

Steffen

Ja, Du hast leider recht. Das ärgerliche ist, daß das eigentlich nur eine Testroutine war, um ein anderes Problem (Empfang auf der Seriellen scheint nicht zu klappen) einzugrenzen.

Nun gut, die Taktfrequenz ist es wohl dann schon mal doch nicht.

"Erst war es ein Kernel alle halbe Jahre, zum Schluss konnte ich mit dem Compilieren nicht mehr aufhören." (Torsten Kleinz im IRC)

RC oszis sind voelling unzuverlaessig. Ich hab das gleiche problem mit einem PIC gehabt, der angeblich 4MHz hatte, aber bei meiner Charge von

20 STueck liefen die mit allem zwischen 3,2 und 4,4MHz. Von wegen kalibireit mit 5% Genauigkeit.

Die Loesung war aber recht einfach: ich erwarte als erstes Byte ueber die serielle Schnittstelle ein 'u'. Das Bitmuster ist 01010101. Ich zaehle dann einfach die Cycles von der esten Flake bis zum letzten bit, und schreibe das Ergebnis in die Zahlerregister fuer den RS232 Taktgeber. Und Schon kann ich prima senden und empfangen. Auf die Art kann mir nicht nur die Taktfrequenz des PIC Wurscht sein, sondern ich unterstuetze auch gleich noch mehrere Baudraten, naemlich genau die, mit der das 'u' gesendet worden ist.

Am Fri, 5 Aug 2005 16:03:05 +0000 (UTC) schrieb Michael Holzt:

Hast Du deinen Oszillator mit dem OSCAL kalibriert? Zum Test reicht es ja, wenn du Dir das passende Byte bei deinem Prüfling mit dem Programmer ausliest und in der Startup Phase deines Programm einfach reinschreibst.

Ansonsten gibt's ja genügend Tips.

Noch ein anderer Tip: Schreib dir dein eigened delay_ms() als asm Unterprogramm, prüfe die Zeiten im Debugger (AvrStudio) und wiederhole deine Tests.

Genausogut kannst Du natürlich auch erst dein vorhandenes Programm im Debugger prüfen...

HTH

Alexander

Matthias Melcher schrieb:

Michael hat ja auch keinen PIC. ;-)

Nein, der (kalibrierte) RC-Oszillator des AVR wird seinem Anspruch, dass man damit ,,aus der Dose raus'' eine RS-232 betreiben kann, nach allen Berichten wohl ganz gut gerecht.

cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

Das entspricht dem was ich hier festgestellt habe. Allerdings mußte ich heute feststellen, daß auf die von AVR mitgelieferten Kalibrierbytes offenbar nicht immer Verlass ist. Angegeben war 0xAA für 8 MHz, aber beim Abgleich mit einem Oszilloskop habe ich einen genauen Takt erst bei 0xAE erreicht, und dann funktionierte auch die serielle Schnittstelle sauber.

Bei einem anderen ATmega8 hingegen war das Kalibrierbyte korrekt. Am besten wohl nicht ganz auf nen Quarz verzichten, sondern zumindest einen kleinen

32.768 kHz Uhrenquarz (braucht keine Cs) anschließen. Damit kann man den internen RC-Oszillator recht genau kalibrieren.
"Erst war es ein Kernel alle halbe Jahre, zum Schluss konnte ich mit dem Compilieren nicht mehr aufhören." (Torsten Kleinz im IRC)

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required