Ich möchte einen ATtiny schlafen schicken, wenn er sein Programm abgearbeitet hat. Ein Pin ist als Ausgang definiert und mit einem 10K Widerstand auf Vcc gelegt (Emitterfolger). Der letzte Schritt im Programm ist, diesen Ausgang auf LOW zu schalten. Was passiert nun, wenn der ATtiny in den Sleep-Mode geht? Wird der Pin dann auf LOW gehalten? Würde ein Strom über den PullUp fließen?
C Zieht ein ATtiny im Sleep-Mode Strom über einen PullUp?
- Ersteller AVR Neuling
- Erstellt am
TommyB
Team Bitschubse
Im Sleep Mode hältst du den Chip quasi nur an, er bleibt in dem Zustand in dem er vorher war.
Je nachdem welchen Mode du wählst läuft Timer, ADC, ... noch weiter um den Controller per Interrupt reanimieren zu können.
Dementsprechend würde auch ein Strom vom PullUp durch den AVR zu GND fließen.
Was man eventuell überdenken könnte:
Den PullUp weg lassen und stattdessen den AVR Internen verwenden.
Also Programm aktiv: Pin = Eingang, PullUp aktiv
Programm abgearbeitet: Pin = Ausgang Low. Sleep.
Ob das bei deiner Schaltung aber funktioniert weiß ich nicht (u. A. wegen dem Widerstandswert). Könnte man ja aber vielleicht mal testen.
Je nachdem welchen Mode du wählst läuft Timer, ADC, ... noch weiter um den Controller per Interrupt reanimieren zu können.
Dementsprechend würde auch ein Strom vom PullUp durch den AVR zu GND fließen.
Was man eventuell überdenken könnte:
Den PullUp weg lassen und stattdessen den AVR Internen verwenden.
Also Programm aktiv: Pin = Eingang, PullUp aktiv
Programm abgearbeitet: Pin = Ausgang Low. Sleep.
Ob das bei deiner Schaltung aber funktioniert weiß ich nicht (u. A. wegen dem Widerstandswert). Könnte man ja aber vielleicht mal testen.
Kann ich denn in der void loop den I/O vom Eingang zum Ausgang umdefinieren? Ginge das ganz normal mit:
pinMode(pin, INPUT); // Anschluss als Eingang definieren
digitalWrite(pin, HIGH); // Pull Up Widerstand aktivieren
Wenn dem so wäre, wäre die Idee echt gut. Das werde ich mal testen. Schlafen geht er übrigens so:
CodeBox C
Das ist nur abgeschrieben, daher weiß ich nicht, welcher Modus das jetzt ist. Das ist natürlich nur das Grundgerüst um zu testen, ob ich ihn per Taster wieder wecken kann.
pinMode(pin, INPUT); // Anschluss als Eingang definieren
digitalWrite(pin, HIGH); // Pull Up Widerstand aktivieren
Wenn dem so wäre, wäre die Idee echt gut. Das werde ich mal testen. Schlafen geht er übrigens so:
CodeBox C
/**
* Simple sketch to test how little power we can use when
* ATTiny goes to sleep.
* Most of the extra saving seems to be due to turning off ADC
**/
#include <avr/power.h>
#include <avr/sleep.h>
#define SWITCH_PIN 0
#define LED_PIN 2
void setup() {
pinMode(SWITCH_PIN, INPUT);
digitalWrite(SWITCH_PIN, HIGH);
pinMode(LED_PIN, OUTPUT);
ADCSRA &= ~(1<<ADEN); //turn off ADC
ACSR |= _BV(ACD); //disable the analog comparator
}
void gotoSleep() {
digitalWrite(LED_PIN, HIGH);
delay(250);
digitalWrite(LED_PIN, LOW);
GIMSK |= 1<<PCIE; //Enable Pin Change Interrupt
PCMSK |= 1<<PCINT0; //Watch for Pin Change on Pin5 (PB0)
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable();
sleep_mode();
// waking up from sleep mode.
sleep_disable();
GIMSK &= ~(1<<PCIE); //Disable the interrupt so it doesn't keep flagging
PCMSK &= ~(1<<PCINT0);
}
void loop() {
digitalWrite(LED_PIN, HIGH);
delay(1000);
digitalWrite(LED_PIN, LOW);
delay(1000);
gotoSleep();
// Wait for the button to be released
// while (digitalRead(SWITCH_PIN) == LOW) { }
}
void interrup() {}
// Interrupt for PIN0 falling edge
ISR(PCINT0_vect) {
}Das ist nur abgeschrieben, daher weiß ich nicht, welcher Modus das jetzt ist. Das ist natürlich nur das Grundgerüst um zu testen, ob ich ihn per Taster wieder wecken kann.
TommyB
Team Bitschubse
Du kannst jederzeit alles ändern (außer die Fuses).
Ich bin leider nicht so gut in C, kann daher nur raten. Sieht aber stark nach Power Down aus (Zeile 31)
Wichtigste Lektüre für dein Vorhaben ist das Datenblatt des Controllers.
Da steht drin welche Komponenten man deaktivieren kann (bzw. sollte wenn man sie nicht nutzt) um Strom zu sparen.
Du nutzt PCINT. Wenn möglich nutz die echten INT Pins. Umso tiefer kannst du ihn schlafen legen und umso weniger Strom frisst er.
Ich bin leider nicht so gut in C, kann daher nur raten. Sieht aber stark nach Power Down aus (Zeile 31)
Wichtigste Lektüre für dein Vorhaben ist das Datenblatt des Controllers.
Da steht drin welche Komponenten man deaktivieren kann (bzw. sollte wenn man sie nicht nutzt) um Strom zu sparen.
Du nutzt PCINT. Wenn möglich nutz die echten INT Pins. Umso tiefer kannst du ihn schlafen legen und umso weniger Strom frisst er.
Haste dafür 'ne Quelle?
Bei den mir bekannten Tinies gehen die konventionellen INTs und die PCINTs beide im Powerdown/Standby...
Einschränkung beim INT0 ist, daß der nur im Low-Level-Interrupt aufweckt (also nicht bei Flanken). Die PCINTs können ja eh nur auf Flanken triggern.
Zur Verwendung der internen Pullups: beim Start des Controllers sind die Beine Tristate (ohne Pullup) bis das Programm die aktiviert. Solange hängt der Pin in der Luft - nicht, daß da dann irgenwelche Probleme auftreten.
(P.S.: gilt natürlich nicht bei Pullups, die aufgrund einer Fuse-bedingten alternativen Funktion eh im Override sind - /Reset zum Beispiel)
P.P.S.: Mit SLEEP werden AFAIK (u.a.) die digitalen Input Buffer abgeschaltet (ausser Override durch alternative Fkt). DDR, PORT und ggf PUEN werden nicht manipuliert.
Die Sleep-Modi halten bestimmte Bereiche (mehr oder weniger, je nach Modus) des Controllers an (werden von der Clock abgekoppelt).
TommyB
Team Bitschubse
Aus dem Datenblatt vom Mega48/88/168/328:
Klingt für mich zumindest so als ob. Getestet habe ich es nie.
Ich nutz die auch eh nur wenn unbedingt nötig. Man muss denn ja auch noch prüfen welcher Pin den Interrupt ausgelößt hat (außer man nutzt nur einen).
Hast es doch selbst zitiert: "In some cases, the input logic is needed for detecting wake-up conditions, and it will then be enabled."
In der Tabelle mit den Signalen der alternativen Funktionen findest Du dann, daß DIEOE durch PCIEx und PCINTy das SLEEP-Signal übersteuert, und den Buffer mit DIEOV=1 aktiviert läßt. Hinter dem Buffer landet der Pinzustand (DI) dann auf dem entsprechenden PCINTy Input.
In der Tabelle mit den Wakeup-Sources haben die externen IRQs auch nur eine gemeinsame Spalte, beim Power Down findest Du dann im Text:
In der Tabelle mit den Signalen der alternativen Funktionen findest Du dann, daß DIEOE durch PCIEx und PCINTy das SLEEP-Signal übersteuert, und den Buffer mit DIEOV=1 aktiviert läßt. Hinter dem Buffer landet der Pinzustand (DI) dann auf dem entsprechenden PCINTy Input.
In der Tabelle mit den Wakeup-Sources haben die externen IRQs auch nur eine gemeinsame Spalte, beim Power Down findest Du dann im Text:
TommyB
Team Bitschubse
Wenn du nur Sleep betrachtest ja. Ich gehe aber zugleich vom PRR aus
So wie ich verstanden hatte soll so viel wie möglich an Strom gespart werden, da gehört das für mich mit dazu. Und genau da ist es für mich unklar.
So wie ich verstanden hatte soll so viel wie möglich an Strom gespart werden, da gehört das für mich mit dazu. Und genau da ist es für mich unklar.
TommyB
Team Bitschubse
Dann ergänzen wir mal noch einen entscheidenden (bereits angedeuteten) Punkt:
Die Flankentriggerung der konventionellen externen INTs benötigt AFAIK 'ne laufende I/O-Clock, deswegen gehen da nicht alle Sleep-Modi. Der Low-Level-IRQ wird asynchron getriggert, deswegen der Hinweis im Datenblatt, daß das nur mit dem Level-IRQ geht.
Die PCINTs können nur auf Flanken triggern - aber immer asynchron... Deswegen können die jeden Modus wecken.
Die Flankentriggerung der konventionellen externen INTs benötigt AFAIK 'ne laufende I/O-Clock, deswegen gehen da nicht alle Sleep-Modi. Der Low-Level-IRQ wird asynchron getriggert, deswegen der Hinweis im Datenblatt, daß das nur mit dem Level-IRQ geht.
Die PCINTs können nur auf Flanken triggern - aber immer asynchron... Deswegen können die jeden Modus wecken.
Ich verstehe nur Bahnhof... Eure Themen gehen Lichtjahre über das hinaus, was ich mir bisher angelesen habe.
Mit dem oben genannten Sketch geht der Tiny schlafen und hat dann im Testaufbau bei 5V einen Verbrauch von 0,35 - 0,4µA. Das ist für mich vollkommen ausreichend.
Mit dem oben genannten Sketch geht der Tiny schlafen und hat dann im Testaufbau bei 5V einen Verbrauch von 0,35 - 0,4µA. Das ist für mich vollkommen ausreichend.
Zuletzt bearbeitet:
Du schreibst leider nicht, um welchen Tiny es sich handelt (oder ich habe es überlesen).
Die PCINTs reagieren immer auf jede Flanke (d.h. ein IRQ, der einen schlafenden Controller wecken würde wird durch die nächste Flanke (egal welche) ausgelöst.
Die konventionellen externen IRQs (INT=0, INT1,...) können eingestellt werden - entweder sollen sie bei einer fallenden, oder bei einer steigenden, oder jeder Flanke auslösen (=flankengetriggert, bei jedem Wechsel ein IRQ), oder bei einem Low-Pegel (= levelgetriggert, dann wird der IRQ solange getriggert (immer wieder), wie der Pegel low ist).
Generell können beide IRQ-Arten den Controller wecken - die Flankentriggerung bei den konventionellen externen IRQs ist aber an die I/O-Clock gekoppelt, wenn also ein SLEEP-Modus verwendet wird der auch die I/O-Clock "anhält", kann der externe IRQ nicht triggern (solange die Clock steht -> wurde der Controller anderweitig geweckt, erkennt er dann(!) auch den externen IRQ (da die Clock ja wieder läuft...
Die Low-Level-Triggerung benötigt (wie auch die Flankentriggerung bei den PCINTs) keine I/O-Clock -> kann also den Controller aus jedem SLEEP-Modus wecken.
Achtung! - bei einigen Controllern scheint(!) es laut Datenblatt diesbezüglich Unterschiede zwischen INT0 und INT1 zu geben - inwiefern es sich dabei um Fehler im Datenblatt handelt, weiß ich nicht.
(Außerdem können bei einigen Controllern (zB Tiny261/461/861) die beiden externen IRQs nur auf denselben Triggermodus eingestellt werden (haben dieselben Interrupt Sense Control Bits))
Der PCINT sollte wie gesagt immer auf jede beliebige Flanke reagieren - Deine diesbezüglich Frage hast Du inzwischen wegeditiert -> läuft das jetzt wie erwartet?
Die PCINTs reagieren immer auf jede Flanke (d.h. ein IRQ, der einen schlafenden Controller wecken würde wird durch die nächste Flanke (egal welche) ausgelöst.
Die konventionellen externen IRQs (INT=0, INT1,...) können eingestellt werden - entweder sollen sie bei einer fallenden, oder bei einer steigenden, oder jeder Flanke auslösen (=flankengetriggert, bei jedem Wechsel ein IRQ), oder bei einem Low-Pegel (= levelgetriggert, dann wird der IRQ solange getriggert (immer wieder), wie der Pegel low ist).
Generell können beide IRQ-Arten den Controller wecken - die Flankentriggerung bei den konventionellen externen IRQs ist aber an die I/O-Clock gekoppelt, wenn also ein SLEEP-Modus verwendet wird der auch die I/O-Clock "anhält", kann der externe IRQ nicht triggern (solange die Clock steht -> wurde der Controller anderweitig geweckt, erkennt er dann(!) auch den externen IRQ (da die Clock ja wieder läuft...
Die Low-Level-Triggerung benötigt (wie auch die Flankentriggerung bei den PCINTs) keine I/O-Clock -> kann also den Controller aus jedem SLEEP-Modus wecken.
Achtung! - bei einigen Controllern scheint(!) es laut Datenblatt diesbezüglich Unterschiede zwischen INT0 und INT1 zu geben - inwiefern es sich dabei um Fehler im Datenblatt handelt, weiß ich nicht.
(Außerdem können bei einigen Controllern (zB Tiny261/461/861) die beiden externen IRQs nur auf denselben Triggermodus eingestellt werden (haben dieselben Interrupt Sense Control Bits))
Der PCINT sollte wie gesagt immer auf jede beliebige Flanke reagieren - Deine diesbezüglich Frage hast Du inzwischen wegeditiert -> läuft das jetzt wie erwartet?
Danke für die Ausführliche Erläuterung.
Ich nutze meist den Tiny85, da der Preisunterschied zu den kleineren Versionen so gering ist, dass es sich (für mich) nicht lohnt. Die Anzahl der I/O Pins reicht für meine kleinen Spielereien auch in den allermeisten Fällen aus und schnell genug ist er sowieso. Ich habe das jetzt so hin bekommen, wie ich es wollte. Es hakte etwas, weil ich einen kleinen Fehler in der Schaltung hatte. Den habe ich behoben und dann den Beitrag editiert, weil noch niemand drauf geantwortet hatte. Nun reagiert der IRQ-Pin zuverlässig auf die Verbindung mit GND, bzw. das Lösen der Verbindung mit GND. Bei 3,3V liegt der Verbrauch bei 0,2µA, bzw. bei Verbindung mit GND bei gut 0,5µA. Das ist selbst auf ein Jahr gerechnet ein Haus von gar nichts. Also perfekt für eine Batterieanwendung.
Ich nutze meist den Tiny85, da der Preisunterschied zu den kleineren Versionen so gering ist, dass es sich (für mich) nicht lohnt. Die Anzahl der I/O Pins reicht für meine kleinen Spielereien auch in den allermeisten Fällen aus und schnell genug ist er sowieso. Ich habe das jetzt so hin bekommen, wie ich es wollte. Es hakte etwas, weil ich einen kleinen Fehler in der Schaltung hatte. Den habe ich behoben und dann den Beitrag editiert, weil noch niemand drauf geantwortet hatte. Nun reagiert der IRQ-Pin zuverlässig auf die Verbindung mit GND, bzw. das Lösen der Verbindung mit GND. Bei 3,3V liegt der Verbrauch bei 0,2µA, bzw. bei Verbindung mit GND bei gut 0,5µA. Das ist selbst auf ein Jahr gerechnet ein Haus von gar nichts. Also perfekt für eine Batterieanwendung.
TommyB
Team Bitschubse
Schön, klingt ja gut
Nur ein kleiner Hinweis noch, da du von Batterieanwendung sprichst:
Solltest du die Debug Funktionen des Chips nutzen (debugWire, möglicherweise auch JTAG): Vorher deaktivieren. Sind die aktiv geht der Chip nie in den Sleep Mode rein, schluckt also trotzdem fröhlich weiter Strom. 2 Akkus hab ich so schon gekillt bis ichs denn mal wusste ^^'
Das mit LotadaC und mir war schon etwas technischer, ja. Brauchst du dir aber keinen Kopf drum zu machen. Es ging nur um PCINT vs. INT0/1. Das war mein Fehler der hier für die Verwirrung sorgte. Ich war beim Lesen des Datenblattes einfach verrutscht und war der Meinung dass im tiefstem Schlafmodus PCINT nicht mehr funktioniert. Stimmt aber nicht. Sorry dafür.
Nur ein kleiner Hinweis noch, da du von Batterieanwendung sprichst:
Solltest du die Debug Funktionen des Chips nutzen (debugWire, möglicherweise auch JTAG): Vorher deaktivieren. Sind die aktiv geht der Chip nie in den Sleep Mode rein, schluckt also trotzdem fröhlich weiter Strom. 2 Akkus hab ich so schon gekillt bis ichs denn mal wusste ^^'
Das mit LotadaC und mir war schon etwas technischer, ja. Brauchst du dir aber keinen Kopf drum zu machen. Es ging nur um PCINT vs. INT0/1. Das war mein Fehler der hier für die Verwirrung sorgte. Ich war beim Lesen des Datenblattes einfach verrutscht und war der Meinung dass im tiefstem Schlafmodus PCINT nicht mehr funktioniert. Stimmt aber nicht. Sorry dafür.
Also lags nicht am Programm - das sollte bereits gestimmt haben...
Problem gelöst, dann können wir ja noch ein wenig spammen...
Der Tiny25/45/85 ist quasi DER 8-Bein-Tiny:
-2 8-Bit-Timer, die zusammen 3 HW-PWM-Kanäle bieten
-Timer1 kann auf 2 Kanälen 2 Push-Pull-Ausgänge mit einstellbarer DeadTime realiesieren (Schaltwandler/Motortreiber etc)
-'ne PLL, womit der Controller intern mit 16MHz betaktet werden kann, und Timer1 mit 64MHz
-'n 8-Bit-ADC, der sogar differentiell messen kann (wahlweise mit 20fach Gain) und'n Temperatur"sensor"
-2 interne Spannungsreferenzen
-gibts auch als TSSOP (der einzige mir bekannte Tiny), lwas sich als Hobbyist noch gerade so verbasteln läßt (von @dino03 mal abgesehen) - so viel kleiner ist ein Tiny4/5/9/10 mit SOT23 auch nicht...
Das einzige, was er gegen den Tiny13 nicht bieten kann, ist die krumme interne RC-Frequenz - wenn man die brauchen sollte.
Der entsprechende Hinweis findet sich im Datenblatt dann beim dWire-Abschnitt (und nicht beim Sleep):
Der geht dann also schon in den Sleep, schaltet/koppelt dabei aber nicht wie sonst die entsprechenden Clocks ab.
Ich hab auch noch einen:
Die BOD aktiviert die internen Spannungsreferenzen, die dann natürlich auch im Sleep Strom verbrauchen. Je nach Hardware-Revision des Controllers, kann die BOD im Sleep aber auch automatisch abgeschaltet werden (was nochmal Strom spart). Beim Tiny85 ab HW-Revision "C"...
TommyB
Team Bitschubse
Eben, Du hast den entsprechenden Hinweis im DB erst nach zwei gekillten Akkus gefunden (bzw überhaupt erst danach gesucht)...
Naja, genau genommen hält "der Code" ja nur an, wenn die CPU-Clock (->CPU und SRAM) steht/abgekoppelt ist.
Im PowerDown sollte aber eben insbesondere auch die I/O-Clock (und die PCK-Clock) stehen/abgekoppelt sein, und da geht das dWire eben drüber.
Aber wir (ich) spalten mal wieder Haare...
Naja, genau genommen hält "der Code" ja nur an, wenn die CPU-Clock (->CPU und SRAM) steht/abgekoppelt ist.
Im PowerDown sollte aber eben insbesondere auch die I/O-Clock (und die PCK-Clock) stehen/abgekoppelt sein, und da geht das dWire eben drüber.
Aber wir (ich) spalten mal wieder Haare...