Hallo nochmal.
Ich konfiguiere grad o.g. Mikrocontroller mit dem internen Oszillator
8MHz. Den Oszillator kann man ja über OSCCAL noch abstimmen. Wenn ich
nun das im Datenblatt(S.213) angegebene Diagramm hernehme und auf genau
8MHz kalibrieren will, komme ich auf einen OSCCAL-Wert von ca. 108d.
Wenn ich den Takt aber rausführe und mit dem Oszi messe, sinds nur
7,3MHz.
Ist das normal oder sollte der stabiler sein? Oder kann man die
Genauigkeit noch irgendwie verbessern?
Danke schonmal...
MfG Andi
>angegebene Diagramm hernehme und auf genau>8MHz kalibrieren will, komme ich auf einen OSCCAL-Wert von ca. 108d.>Wenn ich den Takt aber rausführe und mit dem Oszi messe, sinds nur>7,3MHz.
Dann schreib doch mal andere Werte in OSCCAL rein.
Oder ist das zu viel verlangt?
Der interne Oscillator taugt für ne Ampelsteuerung,
aber auf keinen Fall für eine Uhr.
Na ist mir schon klar, dass wenn ich andere Werte reinschreib, der Wert
anders ist. Mir gehts nur drum, wenn ich mein Programm von Controller A
nach Controller B portiere, muss ich dann OSCCAL wieder durch
Ausprobieren neu kalibrieren?
Andi wrote:
> Mir gehts nur drum, wenn ich mein Programm von Controller A> nach Controller B portiere, muss ich dann OSCCAL wieder durch> Ausprobieren neu kalibrieren?
Ja. Außer du nimmst die Werte, die der Hersteller vorgibt und im Flash
hinterlegt.
>Ok danke erstmal für die Info. Und gibts dazu irgendwelche Alternativen?>Außer externen Takt nehmen?
Nein. Mir wird schon schlecht wenn ich mir
die temperaturabhängigkeit vom internen Oscillator
anschaue.
Andi wrote:
> Na ist mir schon klar, dass wenn ich andere Werte reinschreib, der Wert> anders ist. Mir gehts nur drum, wenn ich mein Programm von Controller A> nach Controller B portiere, muss ich dann OSCCAL wieder durch> Ausprobieren neu kalibrieren?
Beim Reset wird die Factory-Calibration geladen.
Wenn Du genauer sein willst, mußt Du jeden einzelnen Chip separat
kalibrieren.
Ich stelle mir diese Frage aber nie.
Entweder für die Applikation reicht die Factory-Calibration aus oder ich
pappe nen Quarz ran, und gut is.
Irgendwelche Kopfstände mit Nachkalibrieren sind mir zu teuer
(zusätzliche Arbeitszeit, verringerte Zuverlässigkeit).
Peter
> Und gibts dazu irgendwelche Alternativen?> Außer externen Takt nehmen?
Es gibt, wenn ich mich recht erinnere, allein drei Atmel-Appnotes
für verschiedene Methoden, ihn zu kalibrieren.
Dann gibt's noch eine Beschreibung von Cliff Lawson irgendwo in
avrfreaks.net. In einer Applikation, die via RS-232 mit einem PC
kommuniziert, erwartet er als erstes Zeichen bei der Verbindungsauf-
nahme ein CR. Dessen Bitzeiten benutzt er, um den RC-Oszillator
zu kalibrieren, ähnlich wie früher Modems ihr "autobauding" beim
Empfang des ersten AT gemacht haben.
Peter Dannegger wrote:
> Irgendwelche Kopfstände mit Nachkalibrieren sind mir zu teuer> (zusätzliche Arbeitszeit, verringerte Zuverlässigkeit).
Es gibt zuweilen Gründe, warum man den RC-Oszillator trotzdem nehmen
möchte. Der läuft nämlich in nur 6 Takten stabil an. Selbst ein
Keramikresonator braucht im Vergleich dazu eine Ewigkeit, und ein
Quarz auf Grund seiner hohen Güte noch 10mal länger. Der Energie-
verbrauch in der Anlaufp. Für einen Controller, der viel schläft, aber
häufig mal für kurze Zeit aufwachen soll, ergibt das eine deutliche
Minderung der Batterielebensdauer.
Aber es ist natürlich klar, dass solche Entscheidungen immer sehr
konkret von den Anwendungen abhängen. Der RC-Oszillator aktueller
AVRs ist ja in Punkto Stabilität auch eine Größenordnung besser als
der in den AVRs älterer Generation (ganz zu schweigen von den
allerersten im AT90S1200 oder ATtiny12).
>konkret von den Anwendungen abhängen. Der RC-Oszillator aktueller>AVRs ist ja in Punkto Stabilität auch eine Größenordnung besser als>der in den AVRs älterer Generation
Genau das hatte mich anfangs überrascht.
Und wenn ich durch den Quarz zwei Pins verliere, so schaue ich mir, je
nach Budget, die Verhältnisse etwas genauer an.
@ Peter Dannegger (peda)
>Entweder für die Applikation reicht die Factory-Calibration aus oder ich>pappe nen Quarz ran, und gut is.
Naja, es gibt aber noch andere Anwendungen, die eine RTC brauchen. Dann
nimmt man einen Uhrenquarz für die RTC (Strom Sparen) und kalibriert den
RC-Ozillator damit. Geht prima und vollautomatisch ;-)
MFG
Falk
Falk Brunner wrote:
> Dann> nimmt man einen Uhrenquarz
Sach ich doch.
Oder ist ein Uhrenquarz etwa kein Quarz?
Ob nun der CPU-Takt quarzstabil ist oder nur T2, ist für RTC-Anwendungen
eher nebensächlich (MHz-Quarze sind aber stabiler).
Und für UART oder CAN sollte bei nem Uhrenquarz in regelmäßigenm
Abständen eine Autokalibration des RC-Oszillators erfolgen.
Peter
Hallo ich bins nochmal.
Ich hab jetzt mal den Takt von 2 ATtinys461 über CLKOUT gemessen. Dabei
habe ich OSCCAL nicht beschrieben. Bilder und Messwerte sind im
Anhang...
Ist das so realistisch, dass der da 0,2MHz abweicht? Die Frequenz an
sich ist mir nicht ganz so wichtig, wichtig wäre mir halt nur, dass sie
bei jedem neuen Controller etwa gleich ist (also +-0,2MHz). Kann leider
im Datenblatt keine Toleranzangabe zum internen Takt finden...
MfG Andi
0.2MHz Abweichung bei 8MHz sind 2,5% Abweichung. Kein Grund zur Klage,
genauer darfst du das nicht erwarten.
Such mal im Datasheet unter 21.4.1 und 22.9.
