|
Anzeige
|
AVR: "sleep disable" unnötig?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:
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?
ja, dann mache es doch so.
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.
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"?
Wo, wann, und warum?
Beitrag #7481520 wurde von einem Moderator gelöscht.
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.
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?
Gast
#7481572
Wenn die CPU nicht fehlerfrei arbeitet habe ich eh verloren.
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.
Angehängte Dateien:
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.
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.
Sollte. Die bekannten Unterschiede stehen im Errata Sheet, Specification Update, oder wie immer das heisst. Vielleicht war da mal was.
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.
Das ist etwas völlig anderes, das kann man nicht vergleichen. (Aber ich muss zugeben, ich habe den Watchdog bis jetzt noch nie benutzt.)
Warum?
Man kann alles vergleichen.
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.
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.
Ja, ich denke, das ist es, was er damit sagen will.
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 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?
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.
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?
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.
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.
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.
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.
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.
Durch einen Fehler. Stell dich nicht so dumm.
Das tut niemand. Es ist lediglich defensive Fehlertoleranz.
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? 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.
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.
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?
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.
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.
Das ist lediglich deine Einzelmeinung.
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.
Guck dir einfach mal einen Automotive-µC für Safety an.
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.
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".
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.
Falsch. Die CPU folgt 100% exakt dem vorgegebenen Programm.
Du darfst deine Meinung ja behalten.
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.
Yeah, it's not a bug, it's a (useless) feature!
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?
Nein, da sind wir uns ganz und gar nicht einig.
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.
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.
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.
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.
Richtig. Und es gibt da auch noch deutlich kleinere Controller, wie den Renesas RL78.
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.
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.
Microchip schreibt: Recommended for Automotive Design Functional Safety Support
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:
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...
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.
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:
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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
