Ich habe überall gesucht und nichts gefunden. Es gilt als selbstverständlich, die Schlafbereitschaft jedes Mal ein- und auszuschalten. Wir haben hier eine kompetente Meinung: Peter D. schrieb: > Das sleep_disable(); ist Mumptiz und sollte entfallen. Dann reicht auch > das sleep_enable(); einmalig im Init-code. Ich halte das für eine gute Sache und würde mich freuen, wenn sich noch jemand zu diesem Thema äußern könnte.
Also, ich wäre ganz froh, wenn ich morgens um 6:30 meine Schlafbereitschaft einfach ausschalten könnte... Meinst Du nicht, dass für eine sinnvolle Bewertung deiner Frage ein ganz klitzkleinwenig mehr Detailgrad vorhanden sein müsste? Nutzt Du den Sleep Mode überhaupt?
:
Bearbeitet durch User
Georg M. schrieb: > Ich halte das für eine gute Sache und würde mich freuen ja, dann mache es doch so.
Thilo L. schrieb: > Also, ich wäre ganz froh, wenn ich morgens um 6:30 meine > Schlafbereitschaft einfach ausschalten könnte... Meine schaltet sich natürlicherweise gegen 09:00 MESZ aus. Im Winter auch gegen 09:00 MEZ. Warum das so gut klappt, weiss ich nicht. Ich habe jedenfalls keinen AVR eingebaut.
Georg M. schrieb: > und würde mich freuen, wenn sich noch > jemand zu diesem Thema äußern könnte. Wir sollen über die Fakten aus dem Datenblatt abstimmen? Wieso verwendest du sie nicht so roh, wie sie sind, oder bist du auf der Suche nach "alternativen Fakten"? Georg M. schrieb: > Es gilt als > selbstverständlich, die Schlafbereitschaft jedes Mal ein- und > auszuschalten. Wo, wann, und warum?
:
Bearbeitet durch User
Beitrag #7481520 wurde vom Autor gelöscht.
Arduino F. schrieb: > Georg M. schrieb: >> Es gilt als >> selbstverständlich, die Schlafbereitschaft jedes Mal ein- und >> auszuschalten. > > Wo, wann, und warum? Ob es als selbstverständlich gilt, weiß ich nicht, aber das Datenblatt z.B. des Atmega168 empfiehlt es: To avoid the MCU entering the sleep mode unless it is the programmer’s 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. Und wenn das da so empfohlen wird, dann mache ich es auch so, auch wenn irgendeiner aus dem Forum es für unnötig hält.
:
Bearbeitet durch User
Rolf M. schrieb: > Ob es als selbstverständlich gilt, weiß ich nicht, aber das Datenblatt > z.B. des Atmega168 empfiehlt es: > > To avoid the MCU entering the sleep mode unless it is the programmer’s > 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. Das habe ich mich schon immer gefragt wozu das überhaupt im Datenblatt drinsteht. Gibt es noch eine andere Möglichkeit den Sleep Befehl auszuführen ohne explizit den Sleep Befehl abzusetzen?
Angehängte Dateien:
-
AVR_Sleep_Controller.png
81 KB
Rolf M. schrieb: > Ob es als selbstverständlich gilt, weiß ich nicht, aber das Datenblatt > z.B. des Atmega168 empfiehlt es Bei anderen AVRs findet man diese Empfehlung "to clear it immediately after waking up" nicht mehr. Und warum? Nicht mehr nötig, oder so selbstverständlich, dass gar nicht erwähnt werden muss? Das ist die Frage.
Rolf M. schrieb: > Und wenn das da so empfohlen wird, dann mache ich es auch so, auch wenn > irgendeiner aus dem Forum es für unnötig hält. Ich hatte damals bei Atmel explizit nachgefragt, aber nur eine Automatenantwort von nem Supportheini bekommen. Auf meine konkrete Frage war er überhaupt nicht eingegangen. Eine CPU muß sich so verhalten, wie es im Datenblatt steht, d.h. ein Sleep darf erst beim Sleepbefehl erfolgen. Somit ist schon rein logisch gesehen ein ständiges Sleepdisable/-enable zwischen Sleep-Befehlen absolut unsinnig. Ein Sleepdisable wäre nur dann sinnvoll, wenn im Programmablauf ein Sleep ohne direktes Sleepenable auftreten könnte. Aber sowas habe ich bisher in keinem Beispielcode je finden können.
Peter D. schrieb: > Eine CPU muß sich so verhalten, wie es im Datenblatt steht, d.h. ein > Sleep darf erst beim Sleepbefehl erfolgen. Somit ist schon rein logisch > gesehen ein ständiges Sleepdisable/-enable zwischen Sleep-Befehlen > absolut unsinnig. Ein Sleepdisable wäre nur dann sinnvoll, wenn im > Programmablauf ein Sleep ohne direktes Sleepenable auftreten könnte. Nach deiner Logik bräuchte man das SE-Bit überhaupt nicht. Einfach immer schlafen, wenn ein SLEEP-Befehl kommt. Fertig. Leider ist die Realität nicht so einfach. Dieses Bit erhöht die Robustheit gegen Fehler. Und das ist auf jeden Fall sinnvoll. Der Avr hat mehr solcher Sachen eingebaut. Zum Beispiel das WDCE-Bit. Das ist auch "unnötig". Oder der Watchdog ansich. Der ist auch "unnötig", wenn man das Programm richtig schreibt und der Prozessor richtig funktioniert.
Peter D. schrieb: > Eine CPU muß sich so verhalten, wie es im Datenblatt steht Sollte. Die bekannten Unterschiede stehen im Errata Sheet, Specification Update, oder wie immer das heisst. Vielleicht war da mal was.
Georg M. schrieb: > Bei anderen AVRs findet man diese Empfehlung > "to clear it immediately after waking up" > nicht mehr. Vermutlich hat mal jemand darauf geschaut, der logisch denken kann. Es ist sehr schwer, einmal im Datenblatt verankerte Behauptungen zu revidieren. Das habe ich z.B. beim zusätzlichen Timer3 des ATmega1284 erlebt. Das hat mehrere Revisionen gebraucht.
MaWin O. schrieb: > Oder der Watchdog ansich. Der ist auch > "unnötig", wenn man das Programm richtig schreibt und der Prozessor > richtig funktioniert. Das ist etwas völlig anderes, das kann man nicht vergleichen. (Aber ich muss zugeben, ich habe den Watchdog bis jetzt noch nie benutzt.)
Georg M. schrieb: > Das ist etwas völlig anderes, Warum? > das kann man nicht vergleichen. Man kann alles vergleichen.
MaWin O. schrieb: > Nach deiner Logik bräuchte man das SE-Bit überhaupt nicht. Wie gesagt, wann darf so programmieren, daß ein Sleep quasi als NOP interpretiert wird. Nur ist mir bisher keine praktische Anwendung dafür eingefallen. Das Sleepenable könnte z.B. in einem Interrupthandler erfolgen.
Peter D. schrieb: > Rolf M. schrieb: >> Und wenn das da so empfohlen wird, dann mache ich es auch so, auch wenn >> irgendeiner aus dem Forum es für unnötig hält. > > Ich hatte damals bei Atmel explizit nachgefragt, aber nur eine > Automatenantwort von nem Supportheini bekommen. Auf meine konkrete Frage > war er überhaupt nicht eingegangen. Der 1st-Leve-Support wird eh keine Ahnung haben. Wenn der es nicht für wichtig genug erachtet, es weiterzuleiten, kommt halt nix bei rum. MaWin O. schrieb: > Nach deiner Logik bräuchte man das SE-Bit überhaupt nicht. > Einfach immer schlafen, wenn ein SLEEP-Befehl kommt. Fertig. Ja, ich denke, das ist es, was er damit sagen will. > Leider ist die Realität nicht so einfach. Dieses Bit erhöht die > Robustheit gegen Fehler. Und das ist auf jeden Fall sinnvoll. Robustheit gegen was für Fehler? Dass man versehentlich eine SLEEP-Instruktion hinschreibt, obwohl der µC nicht einschlafen soll? Einstrahlungen von außen, die den µC so aus dem Tritt bringen, dass aus irgendeiner Instruktion plötzlich ausgerechnet ein SLEEP wird? Müsste man dann nicht konsequenterweise für so ziemlich jede Instruktion noch ein Bit einführen, das erst gesetzt werden muss, um sie zu aktivieren? Könnte ja sein, dass man die an der Stelle gar nicht wollte. Was macht SLEEP da jetzt so besonders? > Der Avr hat mehr solcher Sachen eingebaut. Zum Beispiel das WDCE-Bit. > Das ist auch "unnötig". Oder der Watchdog ansich. Der ist auch > "unnötig", wenn man das Programm richtig schreibt und der Prozessor > richtig funktioniert. Der Watchdog ist doch was viel allgemeineres. Wenn der µC aus welchem Grund auch immer nicht mehr so weiterläuft, dass er den Watchdog noch resetten kann, wird der µC selbst resettet. Das obige ist aber ganz spezifisch auf die SLEEP-Instruktion beschränkt. Warum gerade die und nicht z.B. CALL oder RETI?
Rolf M. schrieb: > Müsste man dann nicht konsequenterweise für so ziemlich jede Instruktion > noch ein Bit einführen, das erst gesetzt werden muss, um sie zu > aktivieren? Nein. Das SLEEP ist schon besonders, weil das Programm unendlich lange schlafen kann, wenn das Programm nicht vorbereitet ist. Deshalb ist der Befehl standardmäßig abgeschaltet. Rolf M. schrieb: > Der Watchdog ist doch was viel allgemeineres Ja, dann sag doch mal, warum man das WDCE-Bit braucht?
Ich bin immer davon ausgegangen, dass dieses Rumgekasper da ist, um irgendwelche Standards (MISRA oder so) zufrieden zu stellen (ein Haken mehr auf der Featurelist). Viele CPUs haben solche "Sicherheitsmaßnahmen", die gegen havoc-laufende Programme schützen sollen (sleep-enable, spezielle Watchdogsequenzen, geschützte Register, etc). Insbesondere sind diese Schutzmaßnahmen oft ad-hoc und nicht zielführend: ein Programm, das gegen die Schutzmaßnahmen verstößt wird nicht angehalten, sondern die Aktion wird ignoriert - was für ein Quatsch! Glauben die, dass der Rest trotzdem noch korrekt weiter läuft? Hilft es, wenn ich zusätzlich drei Ave Maria bete?
Foobar schrieb: > ein Programm, das gegen die Schutzmaßnahmen verstößt wird > nicht angehalten, sondern die Aktion wird ignoriert - was für ein > Quatsch! Glauben die, dass der Rest trotzdem noch korrekt weiter läuft? Die Wahrscheinlichkeit, dass ein Programm noch korrekt funktioniert wenn es weiterläuft ist deutlich höher als die Wahrscheinlichkeit, dass ein Programm noch korrekt funktioniert, was festhängt. > Viele CPUs haben solche > "Sicherheitsmaßnahmen", die gegen havoc-laufende Programme schützen > sollen (sleep-enable, spezielle Watchdogsequenzen, geschützte Register, > etc). Natürlich retten diese Features für sich gesehen alle nicht die Welt und sie können auch nicht jeden Fehler abfangen. Aber es kann die Gesamtfehlerwahrscheinlichkeit und auch eventuell die Fehlerschwere reduziert werden. Wenn man das alles als unnötig abtut, weil man ja nur korrekt zu programmieren braucht, dann braucht man auch keinen Speicherschutz auf dem PC oder auf sicherheitsrelevanten µCs.
Foobar schrieb: > Ich bin immer davon ausgegangen, dass dieses Rumgekasper da ist, um > irgendwelche Standards (MISRA oder so) zufrieden zu stellen (ein Haken > mehr auf der Featurelist). So sehe ich es auch. Profanes logisches Denken scheint nicht jedem gegeben zu sein. Ein Sleep sollte nicht gerade am Anfang der Mainloop stehen, so daß ein störinduziertes Flip des SE-Bits je ein Problem darstellen sollte. Und selbst dann kann man immer noch ein Sleepdisable an den Anfang des Initcodes setzen. In jedem Fall müssen nach Ende des Initcodes definierte Zustände vorliegen, sonst ist die CPU nur völliger Schrott.
:
Bearbeitet durch User
Peter D. schrieb: > So sehe ich es auch. Profanes logisches Denken scheint nicht jedem > gegeben zu sein. Ja. Man muss nur alles richtig machen. Und an alles denken. So einfach ist das im Grunde. Einfach ein korrektes Programm schreiben und schon funktioniert es. In der Praxis ist das natürlich nicht ganz so einfach. Defensive Techniken, wie Speicherschutz oder auch SEN und WDCE helfen Fehler zu vermeiden. Nicht mehr und nicht weniger. Wenn ihr das nicht braucht, dann nutzt es halt nicht. Es steht euch frei das SEN-Bit direkt in der Init zu setzen, obwohl ihr gar kein SLEEP verwendet. Falls ihr auf hängende Programme steht, die doch irgendwo verborgen ein SLEEP ausführen.
> Falls ihr auf hängende Programme steht, die doch irgendwo verborgen > ein SLEEP ausführen. Woher soll das kommen? Wir reden von einem festen Programm im ROM/Flash. Wenn da durch Störungen von außen durch Zufall ein Sleep ausgeführt wird, wieviel mehr ist vorher schon schiefgelaufen? Da bin ich froh, wenn die CPU möglichst schnell steht und nicht noch mehr Unfug anstellen kann (sie arbeitet ja schon eh nicht mehr nach Vorschrift). Und sowas als ein Heilmittel gegen Programmfehler zu sehen geht in die Richtung "Augen zu und durch" (aka beten) ... Als Debug-Mittel ok, aber dann auch möglichst schnell Bescheid geben und nicht ignorieren und versuchen weiterzumachen.
Foobar schrieb: > Woher soll das kommen? Durch einen Fehler. Stell dich nicht so dumm. > Und sowas als ein Heilmittel gegen Programmfehler zu sehen Das tut niemand. Es ist lediglich defensive Fehlertoleranz. > Als Debug-Mittel ok, aber > dann auch möglichst schnell Bescheid geben und nicht ignorieren und > versuchen weiterzumachen. Dir steht es frei den AVR exakt so zu konfigurieren, dass er das SLEEP eben nicht ignoriert. Einfach SEN setzen. Wo ist also das Problem?
:
Bearbeitet durch User
Diese WDCE Sequenz kann ich nachvollziehen, denn ein versehentlich aktivierter Watchdog führt immer dazu das der zuschlägt wenn das im Code nicht zyklisch per WDR unterbunden wird. Aber ein versehentlich aktiviertes Sleep Enable hat meiner Ansicht nach überhaupt keine Folgen wenn kein Sleep Befehl im Code ist.
Björn W. schrieb: > Aber ein versehentlich aktiviertes Sleep Enable hat meiner Ansicht nach > überhaupt keine Folgen wenn kein Sleep Befehl im Code ist. Es geht ja auch nicht darum, dass das SEN versehentlich aktiviert wird, sondern das SLEEP.
Warum auch immer - bereits im wohl ersten aller AVRs, dem AT90S1200, steht diese Empfehlung im Datasheet.
> Es ist lediglich defensive Fehlertoleranz.
Erkannte Fehler muß man behandeln, nicht ignorieren.
Foobar schrieb: > Erkannte Fehler muß man behandeln, nicht ignorieren. Nein, das muss "man" nicht. Der AVR gibt dir aber die Möglichkeit. Du kannst das SEN-Bit einschalten, abschalten oder wie im Manual steht toggeln. Es ist deine Entscheidung. Wo genau ist das Problem?
> Wo genau ist das Problem?
Dass ein Sleep ohne Sleep-Enable einfach ignoriert wird statt eine
Exception o.ä. auszulösen. Dadurch ist es ein nutzloses Feature - wie
Farbe über Rost zu pinseln.
Note: Sleep hier nur als Beispiel, bei den anderen
Registerschutzmaßnahmen ist es ähnlich.
:
Bearbeitet durch User
Foobar schrieb: > Dass ein Sleep ohne Sleep-Enable einfach ignoriert wird statt eine > Exception auszulösen. Ja gut. Dir ist aber schon klar, dass es sich hier um die extrem primitive AVR8-Architektur handelt? Wenn du solche Features brauchst, dann bist du bei AVR falsch. Ich programmiere ja auch keine Automotive-Safety-Anwendungen auf AVR, weil der das ganz einfach nicht kann. > Dadurch ist es ein nutzloses Feature Das ist lediglich deine Einzelmeinung.
MaWin O. schrieb: > Ich programmiere ja auch keine Automotive-Safety-Anwendungen auf AVR, > weil der das ganz einfach nicht kann. Wie kommst du da drauf? Ich könnte wetten das es genügend Steuergeräte für Autos gibt wo ein AVR drin werkelt und diese Sicherheitsrelevante Dinge machen.
:
Bearbeitet durch User
Björn W. schrieb: > Wie kommst du da drauf? Guck dir einfach mal einen Automotive-µC für Safety an. > Ich könnte wetten das es genügend Steuergeräte > für Autos gibt wo ein AVR drin werkelt und diese Sicherheitsrelevante > Dinge machen. Tja. Wette verloren. Das hat, wenn überhaupt, vielleicht mal jemand vor 15 Jahren gemacht. Der Stand der Technik ist einzuhalten. Da geht kein Weg dran vorbei.
>> Dadurch ist es ein nutzloses Feature > > Das ist lediglich deine Einzelmeinung. Ich wollte das noch nachträglich ausformulieren, du bist aber zu schnell gewesen: Die Situation ist, dass die CPU einen Programmablauffehler festgestellt hat, sie den einfach ignoriert und dir keine Möglichkeit bietet, darauf zu reagieren. Einfach nur: "Schau weg, nichts passiert." Doch, es ist das schlimmste passiert, was passieren kann: die CPU folgt nicht mehr dem vorgegebenen Programm! Deshalb das "nutzloses Feature".
Foobar schrieb: > Die Situation ist, dass die CPU einen Programmablauffehler festgestellt > hat Die CPU hat überhaupt gar nichts festgestellt. Sie führt den SLEEP-Befehl aus und dieser ist ein NOP. Wie im Datenblatt definiert. Die CPU weiß gar nicht, ob das ein Fehler ist. > Doch, es ist > das schlimmste passiert, was passieren kann: die CPU folgt nicht mehr > dem vorgegebenen Programm! Falsch. Die CPU folgt 100% exakt dem vorgegebenen Programm. > Deshalb das "nutzloses Feature". Du darfst deine Meinung ja behalten.
MaWin O. schrieb: > Guck dir einfach mal einen Automotive-µC für Safety an. > >> Ich könnte wetten das es genügend Steuergeräte >> für Autos gibt wo ein AVR drin werkelt und diese Sicherheitsrelevante >> Dinge machen. > > Tja. Wette verloren. > Das hat, wenn überhaupt, vielleicht mal jemand vor 15 Jahren gemacht. Also Doch. Aber ist ja auch Egal, ist ja kein Pimmelfechten hier. Atmel selbst hat ja auch einige der Controller im Datenblatt für Automotive Zwecke beworben, was aber sehr warscheinlich auch nur bedeutet das die dann gegenüber Störungen robuster sind. Im Auto findet man ja auch noch andere Controller, z.B. 8051 und 68k und sowas. Die sind auch nicht gerade dafür bekannt besonders gut mit Störungen zurechtzukommen. Und so richtig Safety (drei Controller mit Mehrheitsentscheidung), so wie in Bereichen wo das wichtig ist, das wirds bei Autos nicht geben. Viel zu teuer.
> Wie im Datenblatt definiert. Yeah, it's not a bug, it's a (useless) feature! > Die CPU folgt 100% exakt dem vorgegebenen Programm. In einem "geschützten" Programm wirst du ausschließlich die Sequenz "sleep-enable, sleep, sleep-disable" finden (und vermutlich genau ein mal). Wer benutzt schon im normalen Programmablauf ein Sleep als Nop-Ersatz? Ich dachte wir waren uns einig, dass ein Sleep ohne Sleep-Enable durch irgendwelche Glitches ausgelöst wird?
Foobar schrieb: > Ich dachte wir waren uns einig, dass ein Sleep ohne > Sleep-Enable durch irgendwelche Glitches ausgelöst wird? Nein, da sind wir uns ganz und gar nicht einig. Björn W. schrieb: > Atmel selbst hat ja auch einige der Controller im Datenblatt für > Automotive Zwecke beworben Automotive ist etwas ganz anderes als Automotive + Automotive-Safety. Vor 15+ Jahren war das noch das selbe. Aber heute bei Weitem nicht mehr. Da müsste man schon mit dem Klammerbeutel gepudert worden sein, heute Safety auf einem Nicht-Safety-Controller zu machen. Der Stand der Technik ist einzuhalten.
MaWin O. schrieb: > Da müsste man schon mit dem Klammerbeutel gepudert worden sein, heute > Safety auf einem Nicht-Safety-Controller zu machen. Was definiert denn eigentlich einen Safety-Controller? Ich will dir mit der Frage nicht ans Bein pissen sondern tatsächlich wissen was der Unterschied dabei ist.
Björn W. schrieb: > Was definiert denn eigentlich einen Safety-Controller? Das steht im Datenblatt drin und der Hersteller gibt in der Regel auch ein Application-Note und Sourcecode, der anzuwenden ist, um die Systeme zu betreiben. Was konkret gemacht und gebraucht wird, unterscheidet sich natürlich von Einsatzzweck zu Einsatzzweck. Aber solche Dinge wie ECC sind wahrscheinlich immer in irgendeiner Art und Weise verbaut. Oder eine Art von primitivem Speicherschutz ist oft mit an Bord. Das kann - muss aber nicht - soweit gehen, dass Peripherie oder auch CPUs doppelt vorhanden sind und in Hardware gegenseitig geprüft werden.
MaWin O. schrieb: > Das steht im Datenblatt drin und der Hersteller gibt in der Regel auch > ein Application-Note und Sourcecode, der anzuwenden ist, um die Systeme > zu betreiben. Du hast nicht zufälligerweise auch ein Link für so ein Datenblatt? Ich bin neuem gegenüber sehr Aufgeschlossen.
Björn W. schrieb: > > Du hast nicht zufälligerweise auch ein Link für so ein Datenblatt? > Ich bin neuem gegenüber sehr Aufgeschlossen. Such mal bei Infineon nach Aurix, bei ST nach Stellar, bei NXP nach S32 und bei Renesas nach RH850, dann hast du die wichtigsten aktuellen Plattformen zumindest mal gehört.
Klaus schrieb: > Such mal bei Infineon nach Aurix, bei ST nach Stellar, bei NXP nach S32 > und bei Renesas nach RH850, dann hast du die wichtigsten aktuellen > Plattformen zumindest mal gehört. Richtig. Und es gibt da auch noch deutlich kleinere Controller, wie den Renesas RL78.
Georg M. schrieb: > Bei anderen AVRs findet man diese Empfehlung > "to clear it immediately after waking up" > nicht mehr. Z.B. beim ATtiny204 steht nur noch: "A SLEEP instruction must be run to make the device actually go to sleep." Das bedeutet, der Zustand des SEN-Bits ist zwischen den Sleeps völlig ohne Belang. Ein ständiges Enable+Disable ist somit nur unnötiger Code und CPU-Last.
Björn W. schrieb: > Im Auto findet man ja auch noch andere Controller, z.B. 8051 und 68k und > sowas. Die sind auch nicht gerade dafür bekannt besonders gut mit > Störungen zurechtzukommen. Im Gegenteil, die 80C51 sind durch den Taktteiler 1:12 sehr robust und störfest. Mit den AVRs habe ich dagegen mehrfach Probleme beim CE-Test gehabt. Insbesondere die Typen, die keine Full-Swing Mode mehr haben, lassen sich leicht stören. Ich bin daher dazu übergegangen, an die AVRs nur noch Quarzoszillatoren anzuschließen. Die sind ja auch nicht mehr so riesig und exorbitant teuer, wie früher mal.
Peter D. schrieb: > Mit den AVRs habe ich dagegen mehrfach Probleme beim CE-Test > gehabt. Insbesondere die Typen, die keine Full-Swing Mode mehr haben, > lassen sich leicht stören. Microchip schreibt: Recommended for Automotive Design Functional Safety Support Z.B. https://www.microchip.com/en-us/product/ATTINY3217
MaWin O. schrieb: > Wenn ihr das nicht braucht, dann nutzt es halt nicht. Es steht euch frei > das SEN-Bit direkt in der Init zu setzen, obwohl ihr gar kein SLEEP > verwendet. Falls ihr auf hängende Programme steht, die doch irgendwo > verborgen ein SLEEP ausführen. Das "verborgene SLEEP" steht aber nicht alleine, sondern wie oben aus dem Datenblatt zitiert und auch hier empfohlen wird vor dem SLEEP sowieso das SE-Bit gesetzt: > To avoid the MCU entering the sleep mode unless it is the programmer’s > 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. Und - um den Datenblattauszug nochmals hervorzuholen - ich denke wenn der Programmierer ein SLEEP hinschreibt, dann ist das klar "the programmer’s purpose". Also wenn der Programmierer ein SLEEP hinschreibt obwohl er das gar nicht will UND sich nicht an die Empfehlung hält direkt davor das SE-Bit zu setzen UND es auch nicht global aktiviert ist dann läuft das Programm anders ab als vom Programmierer gewünscht und das ist ein Sicherheitsfeature. Naja...
MaWin O. schrieb: > Wenn ihr das nicht braucht, dann nutzt es halt nicht. Es steht euch frei > das SEN-Bit direkt in der Init zu setzen, obwohl ihr gar kein SLEEP > verwendet. Abgesehen vom letzten Teil mache ich das genauso. Wenn das Programm SLEEP verwenden soll, wird das SLEEP ENABLE Bit im Rahmen der Initialisierung gesetzt. Und wenn nur ein Sleep-Modus verwendet wird (wie in 99% aller Fälle) wird der SLEEP MODE auch da konfiguriert. Wenn das Programm hingegen kein Sleep verwendet, fasse ich das SE-Bit nicht an. Warum auch? Es wäre Verschwendung von Flash. Damit hatte ich noch nie Probleme. Den Fall, daß ein Glitch irgendwo ein SLEEP hin schmuggelt wo im Programm keins steht, betrachte ich nicht erst. Wenn wenn das passieren sollte, hätte ich wesentlich größere Probleme. Schließlich betrifft das andere Befehle dann ja genauso.
Jan H. schrieb: > Also wenn der Programmierer ein SLEEP hinschreibt obwohl er das gar > nicht will UND sich nicht an die Empfehlung hält direkt davor das SE-Bit > zu setzen UND es auch nicht global aktiviert ist dann läuft das Programm > anders ab als vom Programmierer gewünscht und das ist ein > Sicherheitsfeature. Naja... Nein, es geht hier nicht um einen möglichen Programmierer-Fehler. Das wäre zu einfach. Für die Programmiererfehler-Warscheinlichkeit gibt es keinen Unterschied, ob eine Zeile ("SLEEP!") im Code steht, oder drei Zeilen in einem Block per Copy & Paste: 1. ENABLE 2. SLEEP! 3. DISABLE
Tja, jeder so wie er halt will. Das ist doch das Schöne. Durch das Vorhandensein des SEN habt ihr die Möglichkeit zu Wählen. Außerdem hat man mit SEN natürlich auch noch die Möglichkeit den SLEEP ganz bewusst und explizit zu steuern. Wenn man in einer Situation ist, in der man nicht schlafen möchte, löscht man das SEN-Bit. Dann ist SLEEP ganz ohne zusätzliches Flag und Branch deaktiviert. Das ist ein nützliches Feature, ganz ohne Fehlerbehandlungsgedanke. Aber da gibts sicher auch wieder Leute, denen das nicht gefällt. Aber da gilt die gleiche Antwort: Dann nutzt es halt nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.