Forum: Mikrocontroller und Digitale Elektronik AVR Sleep-Mode enable/disable, wozu?


von Paul H. (powl)


Lesenswert?

Hi!

Mal eine kurze Frage auf die ich im Datenblatt keine Antwort gefunden 
habe:

Wozu muss man den Sleep-Modus ständig aktivieren und deaktivieren? 
Reicht es nicht wenn man ihn einmal aktiviert? Kann es dann tatsächlich 
passieren dass der AVR irgendwann mal einfach so aus heiterem Himmel in 
den Sleep Mode geht? Da könnte ja jedes Modul aus heitem Himmel einfach 
irgendwas machen was es nicht soll.

lg PoWl

von Klugscheisser (Gast)


Lesenswert?

>Wozu muss man den Sleep-Modus ständig aktivieren und deaktivieren?
In gewisser Weise muss man den Sleep-Modus aktivieren, nämlich indem man 
den SLEEP-Befehl ausführt. Allerdings wacht der AVR, vorausgesetzt, ein 
entsprechender Interrupt und die seiner Peripherie zugeordnete 
Taktdomäne, ist aktiviert, von selbst wieder daraus auf.

Der Sleep-Modus ist kein Zustand, der unabhängig von der Tatsache aktiv 
ist, ob Befehle ausgeführt werden. Insofern kann der AVR auch nicht 
"spontan" einen Schlafanfall bekommen. Er wird wiegesagt, ausdrücklich 
durch die Ausführung eines Befehls aktiviert.
D.h. in gewisser Weise muss man den Sleep-Modus nicht ständig aktivieren 
oder deaktivieren. Auf welche Aussage im Datenblatt beziehst Du Dich 
dabei?

>Reicht es nicht wenn man ihn einmal aktiviert?
Nein.

>Kann es dann tatsächlich
>passieren dass der AVR irgendwann mal einfach so aus heiterem Himmel in
>den Sleep Mode geht?
Nein.

>Da könnte ja jedes Modul aus heitem Himmel einfach irgendwas machen was >es nicht 
soll.
Nein, das kann es nicht.

von Paul H. (powl)


Lesenswert?

ich habe mich wohl mal wieder unklar ausgedrückt.

ich meine damit nicht den befehl, der den AVR in den schlaf versetzt 
sondern das Sleep-Enable Bit imt Sleep Mode Control Register.

Danke dennoch für deine Erklärung :-)

lg Powl

von Falk B. (falk)


Lesenswert?

@Paul Hamacher (powl)

>ich meine damit nicht den befehl, der den AVR in den schlaf versetzt
>sondern das Sleep-Enable Bit imt Sleep Mode Control Register.

Das ist eine Vorsichtsmassnahme. Theoretisch kann es nicht aus Versehen 
passieren, dass der AVR in den Sleep Mode geht. Aber bei bestimmten 
Funktionen will man 200% Sicher gehen, und macht deshalb dieses 
zweistufige Verfahren.

MFG
Falk

von Klugscheisser (Gast)


Lesenswert?

OK. Das Sleep-Enable-Bit

Ich räume ein, das die Formulierung im Datenblatt (ich habe mal die vom 
128er genommen) in gewisser Weise offenlässt, ob der AVR "von alleine", 
also ohne Sleep-Befehl in den Sleep-Modus geht.

>To avoid the MCU entering the Sleep mode unless it is the programmers >purpose, 
it is recommended to write the Sleep Enable (SE) bit to
>one just before the execution of the SLEEP instruction and to clear it 
>immediately after waking up.

Ich habe leider keine Erfahrung damit, was passiert, wenn man das Bit 
gesetzt läßt, gehe jedoch davon aus, das der Sleep-Befehl die einzige 
Möglichkeit ist.

Dies bestätigend, steht im Datenblatt auch:
>To enter any of the six sleep modes, the SE bit in MCUCR must be written >to 
logic one and a SLEEP instruction must be executed.

von Hagen R. (hagen)


Lesenswert?

Ok, folgendes Szenario:

Sleep-Enable-Bit ist immer 1.
Sleep-Mode ist immer Power Down.
Aber die Hardware die den Prozessor aus den Power Down aufweckt ist 
nicht immer aktiv. Also zb. I2C als Slave wurde nicht konfiguriert wird 
aber im Laufe des Prozesses irgendwan mal aktiviert.

Nun wird durch einen Softwarefehler aber der Sleep Mode ausgeführt, also 
irgendwie kommt es dazu das der Prozessor den Sleep Opcode ausführt.

Der Prozessor höngt nun dauerhaft im Power Down Modus und kommt nicht 
mehr raus.

Würde man aber das Sleep-Enable-Bit erst dann setzen wenn alle 
Rahmenbedingungen stimmig sind dann kann ein evetuell auftretender 
Sofwtarefeler der unbeabsichtigt den Sleep Mode ausführt den Prozessor 
nicht in den Power Down versetzen, da ja noch nicht per Sleep-Enable-Bit 
scharf gemacht.

Ein Sofwtarefehler könnte zb. ein nicht behandleter Interrupt sein, dh. 
ISR Einsprungspunkt ist nicht definiert. Der Prozessor springt also 
irgnedwohin im FLASH, dort stehen zb. eine Tabelle mit Daten, und darin 
zufälligerweise der Opcode für ein Sleep.

Ähnliches gilt auch für andere Komponenten. Zb. WatchDog Timer. Man muß 
minimal 2 bestimmte Opcodes ausführen und das innerhalb von 4 
Taktzyklen. Angenommen ein ATMega8 mit 8K FLASH. Vereinfacht gibt es 256 
Opcodes, also die Wahrscheinlichkeit das per Zufall die exakt 2 
richtigen Opcodes nacheinander im FLASH auftreten (4 
Taktzyklen-Bedingung) beträgt dann 1/(8192*256*2) = 0.000000238. Es ist 
also fast ausgeschlossen das man per Zufall den WatchDog umprogrammiert.

Beides dient also dazu das Sofwtarefehler nicht ungewollt die Hardware 
in ungünstige Zustände versetzt.

Gruß Hagen

von Paul H. (powl)


Lesenswert?

hm ja das kann sein, trifft aber auch nur bei einem softwarefehler zu 
(der mit dem ganzen interruptgewurtschel zugegebenermaßen schnell mal 
unerkannt bleiben kann)

von Peter (Gast)


Lesenswert?

Es reicht schon aus wenn man mit den Stack auf den Heap trifft, und der 
nächst ret irgendwo im Flash ist. Das ist nicht wirklich ein 
Softwarefehler.

von Hagen R. (hagen)


Lesenswert?

Geht man von der Prämisse aus das die Hardware fehlerfrei ist dann 
beträgt die Wahscheinlichkeit dafür das dein Gerät auf Grund eines 
Softwarefehlers  nicht korrekt funktioniert exakt 100% ;)

Es ist also eine zwingende Notwendigkeit das die Hardware solche 
Features unterstützt da das Gerät mit 100% Sicherheit durch einen 
Softwarefehler lahm gelegt wird. Eine komplexere Software ohne Fehler 
gibt es nicht, bzw. die Wahrscheinlichkeit dafür ist verschwindend 
gering.

Ergo gibt es auch Standards, zb. in der Luft/Raumfahrt, die zwingend 
Mechanismen vorschreiben die verhindern das durch die vorhandenen 
Softwarefehler keine gravierenden Konsequenzen, also dann 
Hardwarefehlverhalten, auftreten können (sollen :-).

Und das Sleep-Enable-Bit ist solch ein HW-Feature.

Gruß Hagen

von Hagen R. (hagen)


Lesenswert?

>Es reicht schon aus wenn man mit den Stack auf den Heap trifft, und der
>nächst ret irgendwo im Flash ist. Das ist nicht wirklich ein
>Softwarefehler.

Na aber sicher ist dies ein Softwarefehler, wer war den die Ursache 
dafür ? Die Software selbstverständlich, da sie die Menge an Heap und 
Stack nicht berücksichtigt hat.

Es ist kein offensichtlich sichtbarer Fehler des Programmierers, aber 
denoch ein Fehler dieser Person bei der Programierung der Software. 
Einen solchen Überlauf zu verhindern liegt in der Aufgabe des 
Softwareentwicklers, primät auf AVRs etc.pp. Größere Prozessoren haben 
dafür aber auch Hardware, siehe Protected Mode und Exceptions dieser 
CPUs.

Gruß Hagen

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
Noch kein Account? Hier anmelden.