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?
>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.
Wie groß ist die Taktfrequenz ohne Überschreiben von OSCCAL, d.h. mit dem bei RESET übernommenen Fabrikwert? Und wie genau ist das Oszilloskop?
Mir liegen 2 ATtiny461-20PU (0711) vor. Mit U=5.0V und T=14°C liegen diese bei: [8.00,8.06] bzw. [7.98,8.02] MHz.
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
Angehängte Dateien:
-
tinys.PNG
24 KB
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.
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.