Ich habe mir gerade den Artikel "Sleep Mode" und insbesondere den Abschnitt "Morgenmuffel" angeschaut (https://www.mikrocontroller.net/articles/Sleep_Mode#Morgenmuffel). Mir ist klar, dass der Artikel für einen älteren AVR geschrieben wurde und möglicherweise erklärt das auch schon alles. Könntet ihr mir trotzdem mal eben bestätigen, dass der folgende Gedankengang korrekt ist? Danke! Nehmen wir als Beispiel einen ATmega328p mit externem 8-MHz-Quarz und der Einstellung (in Eclipse) "Ext. Crystal Osc. 8.0- MHz Start-up time PWRDWN/RESET: 16k CK/14 CK + 65 ms", das entspricht den Fuses CKSEL[3:0]=1111, SUT[1:0]=11. Ich verstehe das Datenblatt wie folgt: Der Watchdog-Oszillator ist verantwortlich für die 65 ms, die sind aber nur dazu da, auf die Spannungsversorgung zu warten. Beim Aufwachen aus einem Sleep-Modus (egal welchem) fallen die 65 ms weg. Die 16k Clocks (die zusätzlichen 14 werden m.E. auch nur beim echten Reset verwendet, aber das spielt keine große Rolle) hingegen beziehen sich nicht auf den Watchdog, sondern auf den Quarz (oder allgemeiner die Haupt-Taktquelle). Ich habe ein paar zugegebenermaßen rudimentäre Test gefahren und die Zeit zwischen einem externen Interrupt und der Reaktion des AVR gemessen. Meine Methodik ist nicht sehr genau, aber es kamen ungefähr 2 ms heraus. Wenn ich auf "1k CK/14 CK + 65 ms" (CKSEL[3:0]=1110, SUT[1:0]=00) gehe, bekomme ich ca. 130 us Verzögerung. Das deutet meines Erachtens darauf hin, dass meine Interpretation korrekt ist und es nicht wie im Artikel beschrieben der Watchdog ist, der die Clocks erzeugt. Für die Tabelle würde das bedeuten, dass man Einschwingzeiten im Bereich von 10 ms auf diese Weise gar nicht hinbekommen kann. Schließlich ist 16k die maximale Einstellung und die bringt (bei einem 8-MHz-Quarz) nur 2 ms. (Bonus-Frage: Ist das ein Problem? Mit welcher Größenordnung muss ich bei 08/15-Quarzen wie sie auf Arduinos & Co. verbaut sind rechnen?)
Bert 4. schrieb: > bekomme ich ca. 130 us Verzögerung Da spielt der Quarz nicht mit. Ein Quarz im MHz-Bereich braucht um die 10ms zum Anschwingen, bei 32kHz-Quarzen kann es sogar mehrere Sekunden dauern. Schnell aufwachen geht nur mit RC-Oszillator oder Keramikresonator.
Peter D. schrieb: > Da spielt der Quarz nicht mit. Ein Quarz im MHz-Bereich braucht um die > 10ms zum Anschwingen, bei 32kHz-Quarzen kann es sogar mehrere Sekunden > dauern. Dann mal ganz dumm gefragt: Wenn das so ist, warum bietet der AVR so eine unpassende Auswahl an Verzögerungen an? Es gibt ja nur 258, 1k und 16k clocks, also (bei 8 MHz) 32 us, 125 us und 2 ms. Womit muss ich rechnen, wenn ich eine zu kurze Einschwingzeit habe? Stürzt mir der AVR ab? Oder ist nur die Frequenz ein bisschen daneben? In meinem konkreten Beispiel muss ich weniger als 1 ms nach einem Pin-Change-Interrupt per SPI reagieren. Das funktioniert mit den 125 us zunächst einwandfrei, aber ich will natürlich, dass das Teil auch langfristig und nicht nur bei Zimmertemperatur läuft. Den Standby-Modus würde ich zwecks Stromsparen gerne vermeiden. Ich sollte vermutlich einen Keramikresonator nehmen, richtig? Mit was für einem Stromverbrauch muss ich bei denen rechnen im Vergleich zum Quarz?
Bert 4. schrieb: > Stürzt mir der AVR ab? Oder ist nur die Frequenz ein bisschen daneben? Gute Frage. Wenn Glitches auftreten könnte es durchaus Probleme geben. > In meinem konkreten Beispiel muss ich weniger als 1 ms nach einem > Pin-Change-Interrupt per SPI reagieren Wenn Du dafür den Quarz anwerfen musst, haste Dir den falschen µC ausgesucht. Ein Nordicsemi NRF5x z.B. kann seinen Quarz in <=1 ms anwerfen - und müsste das für SPI via externem Interrupt nicht mal tun, denn dafür reicht der interne RC Oszillator. Bei AVR kannste aber die Taktquelle AFAIK nicht ohne Fuses ändern.
Hallo, damit der Ablauf überhaupt startet muß der Quarz ja schon soweit angeschwungen sein daß ein halbwegs brauchbarer Takt anliegt. Bis dahin macht der AVR nach Reset/PowerOn erstmal ja garichts... Die Zeit ist also die Zeit zwischen "ausreichend" angeschwungen und schwingt stabil und dafür wird es auch ausreichen. Gruß aus Berlin Michael
Bert 4. schrieb: > Peter D. schrieb: >> Da spielt der Quarz nicht mit. Ein Quarz im MHz-Bereich braucht um die >> 10ms zum Anschwingen, bei 32kHz-Quarzen kann es sogar mehrere Sekunden >> dauern. > > Dann mal ganz dumm gefragt: Wenn das so ist, warum bietet der AVR so > eine unpassende Auswahl an Verzögerungen an? Es gibt ja nur 258, 1k und > 16k clocks, also (bei 8 MHz) 32 us, 125 us und 2 ms. > > Womit muss ich rechnen, wenn ich eine zu kurze Einschwingzeit habe? Dieses folgt nicht aus jenem. In der Zeit, die der Quarzoszillator zum Anschwingen braucht, liefert er ja keine Impulse. Zumindest keine verwertbaren. Sobald der Quarz halbwegs schwingt und die Amplitude der Impulse reicht, um den Zyklenzähler zu triggern, beginnt die definierte Startverzögerung von N Zyklen. Die Zeit für das Anschwingen des Quarzes kommt auf diese Zeit nochmal oben drauf und ist generell kaum vorhersagbar, weil sie vom Quarz und der Dimensionierung drum herum (Bürde-Kondensatoren etc.) abhängt. Stell es dir einfach so vor, daß nach dem Anschalten der Versorgung die Amplitude aus dem Quarzoslillator langsam ansteigt. Zu einem bestimmten Zeitpunkt reicht die Amplitude gerade aus, den Schaltungsteilen dahinter Taktimpulse zu liefern. Aber weil die Amplitude nur gerade so ausreicht, können Rauschen oder kleine Schwankungen der Betriebsspannung dazu führen, daß hin und wieder mal ein Impuls fehlt. Oder daß die Impulsbreite asymmetrisch ist. Der Zyklenzähler im AVR sorgt nun dafür, daß diese Phase mit erratischen Taktstörungen abgewartet wird. Denn da die Amplitude ja weiter steigt, kann man davon ausgehen, daß sie nach N Impulsen so weit oben ist, daß keine Störungen mehr auftreten. Die Zahl N muß nur groß genug gewählt werden, daß der Oszillator nicht mehr als N Schwingungen braucht um von "Amplitude reicht gerade so" bis auf "Amplitude reicht ganz sicher" hoch gelaufen zu sein.
@Michael @Axel: Danke, eure Erklärungen haben mir sehr geholfen! Und implizit habt ihr mir auch bestätigt, dass meine Interpretation des Datenblatts korrekt und die des Artikels falsch (oder zumindest unpassend für den 328p) war. @Jim: Die Auswahl des AVR ist nicht tragisch, weil ich im Moment sowieso erst in der Experimentierphase bin. Den AVR habe ich halt genommen, weil ich damit mit Abstand am meisten Erfahrung habe. (Vielleicht zur Erklärung, auch wenn das mit der ursprünglichen Frage wenig zu tun hat: Es geht mir darum, einen batteriebetriebenen CC1101 im Empfangs-Modus zu halten und die MCU (welche auch immer) nur zu wecken wenn absolut nötig. Der CC ist natürlich im Wake-on-Radio-Modus, sonst wäre die ganze Stromsparerei ja ohnehin für den Eimer. Ziel in ferner Zukunft sind irgendwelche Hausautomationssachen. Ob die einen Quarz brauchen hängt dann vor allem an den angeschlossenen Sensoren/Aktoren ab (manche wollen z.B. UART). Für SPI reicht sicher auch der interne RC. Ich werde mir mal Keramikoszillatoren anschauen und gucken ob die genügend wenig Strom brauchen und hinreichend genau für UART sind. Ein uC-Wechsel steht durchaus auch zur Debatte, z.B. habe ich einen PIC24FJ im Auge, weil es den auch mit AES-/TRNG-Hardware gibt, was für Funkanwendungen ja praktisch ein Muss ist.)
Es gibt auch die Möglichkeit den AVR mit dem internen RC-Oszillator laufen zu lassen und an den asynchronen Timer einen 32kHz Quarz zu pappen. Der kann sogar im Power-Save ständig laufen. Damit kann man dann den RC-Oszillator fein justieren oder den Baudratenteiler für die UART berechnen.
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.