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
>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.
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
@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
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.
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
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)
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.
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
>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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.