Im Powerdown-Modus nimmt ein Controller wie der ATtiny2313 nur eine sehr geringe Leistung auf. Das ist schön. Weniger schön ist, dass er in diesem Modus nicht so ohne weiteres über die Serielle Schnittstelle ansprechbar ist. Denn für die asynchrone Datenübertragung muss das Timing genau stimmen, so dass ein externer Quarz erforderlich ist. Der benötigt einige Zeit, um einzuschwingen - zu viel Zeit, um die eingehenden Bytes mitzulesen. Darum habe ich den Powerdown-Modus bislang nicht genutzt, wenn auch die Serielle Schnittstelle aktiv sein sollte. Nun hatte ich kürzlich einen Hinweis gelesen, dass man mit einem kleine Trick die oben angeführte Klippen umschiffen kann: Angeblich sollte man durch das Senden von 0xFF (oder 0x00 ?) den Controller aus dem Sleep wecken und anschließend seriell mit ihm kommunizieren können. Das wollte ich mir mal genauer ansehen - das Ergebnis ist in der readme.pdf beschrieben. Michael S.
Du kannst auch den internen RC-Oszillator als Takt nutzen, gegebenenfalls mußt ihn vorher noch über das OSCAL-Register kalibrieren. Ich würde auf jedenfall noch die Fuses auf kurzes Delay nach dem Aufwachen setzten. Das Aufwecken über ein Dummy-Byte ist natürlich die sicherste Methode, völlig Zeit unkritisch.
Hallo, genau das gleiche "Problem" hatte ich bei meinem atmega168 auch. Ich verwende auf Grund des geringen Verbrauchs auch den Power Down Mode. Der uC kann bei mir über zwei Quellen geweckt werden. 1.) Ich habe den Watchdog Timer so konfiguriert, dass er den Controller alle 8s aufweckt. Anschließend werden Messungen durchgeführt und wenn nichts zu tun ist, geht er wieder in den Power Down Mode. 2.) Da der Controller auch im Power Down Mode von außen ansprechbar sein muss, kann er auch über die UART Schnittstelle geweckt werden. Ich habe hierfür 2 Modi für die UART-Schnittstelle definiert. a.) Wenn der Controller in den Power Down Mode geht, wird der RX Pin der UART Schnittstelle zum PCINT PIN umkonfiguriert. b.) Sobald der entsprechende PCINT Interrupt aufgerufen wird, wird der RX Pin wieder in den normalen UART Mode konfiguriert. Da ich das Protokoll selber in der Hand habe, habe ich einfach ein Wakeup Pattern definiert, dass ich mit jeder UART Message mitsende. Bei einer Datenrate von 19.200 bit/s benötige ich 6 Dummy bytes (6 x 0xFF). Mein F_CPU beträgt hierbei 16 MHz. Ich muss mal ein wenig an den Fuses spielen und schauen ob ich es auch mit weniger Dummies hinbekomme.... Was mir noch sehr komisch vorkommt: War ein IO Pin vor dem Power Down auf High (3,3V), ist er im Power Down Mode plötzlich auf +5V = Supply???? Ich bin davon ausgegangen, dass im Power Down Mode die IOs gar nicht mehr getrieben werden...Wie ist es bei euch? Grüße, Sabine
Sabse schrieb: > Ich bin davon ausgegangen, dass im Power Down Mode die IOs gar nicht > mehr getrieben werden...Wie ist es bei euch? Meine AVRs behalten Ihre IO-Pegel bei, wenn ich sie schlafen lege.
"Start-up Time from Power-down and Power-save": 6 Takte bei "Calibrated Internal RC Oscillator" 16 K Takte bei "Crystal Oscillator" Ersteres dauert bei 8 MHz 0.75 us, Letzteres bei 16 MHz 1 ms. 1 Byte dauert bei 19200 Bd (8N1) 0.52 ms. (Wobei Atmel unter "K" vielleicht auch 16384 versteht)
Quatsch, nochmal: Wobei Atmel unter "16 K" vielleicht auch 16384 versteht.
Sabse schrieb: > Was mir noch sehr komisch vorkommt: War ein IO Pin vor dem Power Down > auf High (3,3V), ist er im Power Down Mode plötzlich auf +5V = > Supply???? Dann ist ja schon mal die Frage warum die Ausgangsspannung im Normalzustand nur 3.3V bei H-Pegel beträgt wenn die Versorgungsspannung 5V beträgt? Hast du da ne PWM? Die stoppt natürlich wenn der Takt vom μC angehalten wird und der Ausgang ist High oder Low - reiner Zufall. Sascha
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.