Hallo Forum! Wie schaltet man ein Gerät geordnet aus? Brownout-Detection? Reset-Controller? Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es zu keinen unerwünschten Effekten kommt? Danke für eure Teilnahme!
Frank O. schrieb: > Wie schaltet man ein Gerät geordnet aus? z.B. mit einem Schalter Frank O. schrieb: > Brownout-Detection? Ist schon sowas wie Pflicht! Denn: Frank O. schrieb: > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Das ist Unfug.
Frank O. schrieb: > dass es zu keinen unerwünschten Effekten kommt welche auswirkung hat ein unerwünschter Effekt * bei einem elektronischen Würfel? * in einem elektrischen Lockenwickler? * im Stellwerk der Eisenbahn? * im Flugzeug? * im Atomkraftwerk? merkst du was?
:
Bearbeitet durch User
Ich schreibe nach jedem Befehl 5 NOPs, dass beim Abschalten mit hoher Wahrscheinlichkeit grad ein NOP dran ist. Hat sich super bewährt - nie Probleme! Gruss Chregu
Es gibt sogenannte Button Controller. Sowas wie den hier: https://www.analog.com/en/products/ltc2954.html Der kann beispielsweise einen Spannungsregler mit Enable-Eingang schalten. Durch einen kurzen Druck auf den Button wird das System eingeschaltet. Nach einem weiteren kurzen Druck auf den Button bekommt der Prozessor einen Interrupt und kann sich selber mit dem KILL-Signal abschalten, wenn es ihm genehm ist. Nach einem langen Druck wird der Prozessor hart abgeschaltet - wie bei einem PC. fchk
Arduino F. schrieb: > Frank O. schrieb: >> Brownout-Detection? > Ist schon sowas wie Pflicht! Ja klar, das denke ich auch. Bisher waren meine Sachen eher klein und hatten nur wenige Zeilen Code. Dieses Mal will ich mir schon im Vorfeld auch Gedanken über solche Sachen machen. Brownout-Detection habe ich auch immer eingeschaltet. Mir ist natürlich auch klar, dass die Hardware schon so gebaut werden muss, dass es dort zu sicheren Zuständen kommt.
Frank K. schrieb: > Es gibt sogenannte Button Controller. Sowas wie den hier: > > https://www.analog.com/en/products/ltc2954.html Danke Frank! So etwas wollte ich lesen. Christian M. schrieb: > Ich schreibe nach jedem Befehl 5 NOPs, dass beim Abschalten mit hoher > Wahrscheinlichkeit grad ein NOP dran ist. Hat sich super bewährt - nie > Probleme! Wird das System dann nicht deutlich langsamer? Aber sicher eine gute Idee vor und hinter kritischen Sachen.
Daniel F. schrieb: > welche auswirkung hat ein unerwünschter Effekt Diese Frage habe ich mir schon vor dem Beitrag gestellt und genau deshalb habe ich diesen Beitrag geschrieben, nachdem ich in der Suche nichts fand.
Frank O. schrieb: > Hallo Forum! > Wie schaltet man ein Gerät geordnet aus? Das hängt vom Gerät ab. Kann plötzliches Abschalten unerwünschte Folgen bei angeschlossenem Equipment haben? Am Controller selber sind nur aktuelle Schreibvorgänge in nichtflüchtigen Speicher kritisch, die unvollständig bleiben könnten. Am besten ist, wenn die Software das Selber-Ausschalten selber übernimmt. Ungeplantem Ausschalten am besten mit gepufferter Betriebsspannung begegnen, damit noch etwas Reaktions-Zeit bleibt. Also kurzum- ohne zusätzliche Vorbereitung in Hardware gehts nicht.
:
Bearbeitet durch User
Frank O. schrieb: > Wie schaltet man ein Gerät geordnet aus? In dem man die Versorgungsspannung abschaltet. Leider sinkt die wegen der Pufferkondensatoren aus Sicht des uC langsam ab. Daher ist eine > Brownout-Detection bei modernen Prozessoren Pflicht. Ansonsten führen sie zum Schluss ggf. defekte Befehle aus und zerstören ihren EPROM Inhalt oder treiben sonstige Dinge. Wenn der uC vor dem Abschalten noch andere Dinge tun muss, beispielsweise Peripherie in sicheren Zustand bringen oder Parameter in EEPROM speichern, dann gibt es meist einen power fail intrrupt.
Frank O. schrieb: > Christian M. schrieb: >> Ich schreibe nach jedem Befehl 5 NOPs, dass beim Abschalten mit hoher >> Wahrscheinlichkeit grad ein NOP dran ist. Hat sich super bewährt - nie >> Probleme! > > Wird das System dann nicht deutlich langsamer? > Aber sicher eine gute Idee vor und hinter kritischen Sachen. Dein Ironiedetektor funktioniert nicht. Schalte den mal aus und wieder ein.
Frank O. schrieb: > Wie schaltet man ein Gerät geordnet aus? Das sollte im Pflichtenheft stehen, was das Gerät beim Ausschalten alles machen soll. Frank O. schrieb: > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Sorgfältig arbeiten, Ablaufplan erstellen, in Module aufteilen und jedes Modul für sich testen.
Thilo R. schrieb: > Dein Ironiedetektor funktioniert nicht. Schalte den mal aus und wieder > ein. Und nicht die NOPs vergessen!
Frank O. schrieb: > Mir ist natürlich auch klar, dass die Hardware schon so gebaut werden > muss, dass es dort zu sicheren Zuständen kommt. Das ist genau der Punkt. Abgesehen von Brown out sind die Ausgänge undefiniert wenn der Controller unter seine Betriebsspannung kommt. Bei der Wald und Wiesen Elektronik, die ich so mache, hat mich das noch nie gekümmert, aber z.B. in der Luftfahrt wird das anders sein. ;-) Dann ist aber auch das Verhalten der Peripherie beim Ausschalten interessant.
Frank O. schrieb: > Brownout-Detection? Reset-Controller? > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Nicht Oder, Und. Idealerweise muss das Programm beim Ausschalten garnichts machen. Zum Beispiel kann man Benutzereingaben sofort ins EEPROM schreiben und muss nicht warten, ob er evt. noch etwas ändern will. Dabei gibt es auch noch 2 Möglichkeiten: man schreibt, und hofft, dass der Elko gut geladen ist oder man misst die Elko-Spannung und wenn sie zu niedrig ist, fängt man garnicht an zu schreiben. Natürlich müssen Ausgänge definiert abgeschaltet und eingeschaltet werden. Zum Beispiel dürfen 24V-Relais je nach Typ und Temperatur erst bei 22V eingeschaltet werden. Es gibt nämlich nicht nur aus und ein, sondern auch "ein" mit zu wenig Kontaktdruck und zu hohem Übergangswiderstand. Man sollte "Brown Out" auch wörtlich nehmen. Bei kurzen Netzausfällen geht VDD nicht auf 0.0V. Es gibt dann z.B. einen Power Fail Interrupt aber keinen Reset. Aus dem Zustand muss das Programm auch wieder starten können. Oder es gibt einen Reset nur für einen Teil der Chips. Oder ein Chip ist danach in einem undefinierten Zustand, weil der interne Reset nur funktioniert, wenn VDD kleiner als 0.2V wird. Bis 0.7V runter geht es ziemlich schnell, aber wenn keine Diode mehr leitet, kann es Minuten bis 0.1V dauern. Also ja, man braucht einiges an Hardware, aber das Programm muss die auch richtig bedienen können.
Frank O. schrieb: > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Dazu musst du erstmal formulieren, was in deiner Anwendung "unerwünschte Effekte" sind und wie die Hardware aufgebaut ist.
Frank O. schrieb: > Brownout-Detection habe ich auch immer eingeschaltet. Das ist schon mal gut! War deinem Text nicht zu entnehmen. Sollte allerdings 99% aller µC Anwendungen zur Genüge abdecken. Frank O. schrieb: > Dieses Mal will ich mir schon im Vorfeld auch Gedanken über solche > Sachen machen. Auch gut! Aber leider ist geheim, welche Sorgen dich da wirklich plagen (könnten).
Christian M. schrieb: > Ich schreibe nach jedem Befehl 5 NOPs, dass beim Abschalten mit hoher > Wahrscheinlichkeit grad ein NOP dran ist. Mit 9 NOPs kannst du die Explosionswahrscheinlichkeit sogar noch weiter senken, immerhin von 16 auf 10%! :) Leider wird es ab da immer weniger besser, nur wenn du den ganzen Speicher mit NOPs füllst, ist der Knalleffekt ausgeschlossen... :( Gerhard H. schrieb: > Ungeplantem Ausschalten am besten > mit gepufferter Betriebsspannung begegnen, damit noch etwas > Reaktions-Zeit bleibt. Nicht nur puffern, das wichtigste dazu ist der Alarm, wenn die Elkos zwar noch voll sind, das Netzteil aber schon "weg" ist!
Jens M. schrieb: > das wichtigste dazu ist der Alarm Der kommt meistens genau dann wenn keiner in der Nähe ist :) Aber klar, ohne passendes Signal kann der Controller nicht wissen wann er "einpacken" muss.
Rainer W. schrieb: > Dazu musst du erstmal formulieren, was in deiner Anwendung "unerwünschte > Effekte" sind und wie die Hardware aufgebaut ist. Hat gerade gar nichts mit der konkreten Anwendung zu tun. Ich habe mal wieder (muss ich dringen sein lassen) zu viel Gerümpel auf dem Tisch gehabt und alles auf einen Haufen gekippt. Jedenfalls war der Pin kaputt und anstatt PWM kam da so viel raus, dass des Mosfet eingeschaltet blieb. War für ein Test aufgebaut und ich habe das einfach als "Ambilight" laufen lassen. Nun blieb der Fet an, nachdem ich den Nano vom Steckbrett nahm. Mir war sofort klar, dass das natürlich auch in der realen Hardware definitiv nicht sein darf und ein Pulldown dran gehört. In dem Zusammenhang kam mir der Gedanke. Also nichts wirklich Konkretes. Da ich schon lange nichts mehr gemacht habe, dachte ich, ist es besser solche Sachen einfach einmal zu besprechen.
Jens M. schrieb: > Mit 9 NOPs kannst du die Explosionswahrscheinlichkeit sogar noch weiter > senken, immerhin von 16 auf 10%! :) Ein Witz der schon vorher blöd war, wird nicht besser, wenn man ihn ständig wiederholt. Indianer reiten zwar ein Pferd, bis es tot ist, aber sie essen es dann auf, statt zu versuchen weiter drauf zu reiten.
Peter D. schrieb: > Sorgfältig arbeiten, Ablaufplan erstellen, in Module aufteilen und jedes > Modul für sich testen. Danke Peter! Ja, da bin ich gerade dabei. Aber das weißt du ja schon.
Ein Mikrocontroller Programm geordnet ausschalten... Was soll das sein ? 1) Ein System muss sich geordnet in einen sicheren Zustand bewegen. 2) Ein System muss im Fehlerfall in einen sicheren zustand uebergehen. Ja, aber deswegen wird das Programm ja nicht abgeschalten. Allenfalls moechte man Benachrichtigungen, Fehlerdiagnose, Testmoeglichkeiten, und die Moeglichkeit zum Wieder anfahren, falls sich die Situation gebessert hat.
Arduino F. schrieb: >> Brownout-Detection habe ich auch immer eingeschaltet. > Das ist schon mal gut! > Sollte allerdings 99% aller µC Anwendungen zur Genüge abdecken. Das Einschalten deckt null Komma nichts ab. Wichtig ist, was man in der Brown-out-Routine tut, und das ist oft keineswegs trivial. Übrigens: Bei Geräten mit Batterieversorgung kann es vorkommen, dass bei ziemlich schwacher Batterie ein Brownout auftritt, wenn man mit dem µP eine Last einschaltet. Auch das muss man bedenken. Und es ist sehr schwer wirklich "in echt" zu testen.
Arduino F. schrieb: Jens M. schrieb: > nur wenn du den ganzen Speicher mit NOPs füllst, ist der Knalleffekt > ausgeschlossen... :( Vielleicht besser, in den letzten Speicherplatz ein Jump $-1 zu schreiben. Sonst weiß der arme Prozessor gar nicht, wo und wie es weiter geht.
Rolf schrieb: > Das Einschalten deckt null Komma nichts ab. Wichtig ist, was man in der > Brown-out-Routine tut, und das ist oft keineswegs trivial. Der TO will es nicht sagen, aber ihm nutzt olle 8Bit AVRs, möchte ich behaupten. Und da ist die Routine recht klar: Reset! Ohne jede Alternative. Damit sind alle Fehlfunktionen unterbunden, die sonst bei Unterspannung auftreten könnten. Rolf schrieb: > Übrigens: Bei Geräten mit Batterieversorgung kann es vorkommen, dass bei > ziemlich schwacher Batterie ein Brownout auftritt, wenn man mit dem µP > eine Last einschaltet. Vielleicht aufhören zu jammern, und mal die Batterie wechseln?
Arduino F. schrieb: > Der TO will es nicht sagen, Ist doch Blödsinn. Ich habe doch geschrieben wieso ich drauf gekommen bin. Frank O. schrieb:
Frank O. schrieb: > Ist doch Blödsinn. Selber! Ich sehe nicht, dass du irgendwo konkretisiert hast, auf welchen AVR oder sonstige µC sich deine Eingangsfrage bezieht. Gut, da gibts eine Anekdote über einen Nano. Die hat aber nichts mit "µC Abschalten" zu tun.
Arduino F. schrieb: > Gut, da gibts eine Anekdote über einen Nano. Die hat aber nichts mit "µC > Abschalten" zu tun. Ok! Ich baue den Flux-Compensator. Und damit ich nicht irgendwo in der Zeit lande, muss der Mikrocontroller bei weniger als 1.1GW sicher abschalten. Jetzt zufrieden? Es gibt keinen konkreten Anlass. Frei nach dem Motto: "Warum ist die Banane krumm?"
Arduino F. schrieb: > Reset! > Ohne jede Alternative. > Damit sind alle Fehlfunktionen unterbunden, die sonst bei Unterspannung > auftreten könnten. Da setzt man besser früher bei der Spannungsabsicherung (auch für angeschlossene, empfindliche Hardware) an und lässt es erst gar nicht zum Reset bei Unterspannung kommen. Das ist höchstens eine Notlösung- und nur bei einem Teil von Anwendungen überhaupt brauchbar. Frank O. schrieb: > Frei nach dem Motto: "Warum ist die Banane krumm?" Das lässt sich durchaus alles im Detail diskutieren. Und sei es aus Langeweile.
:
Bearbeitet durch User
Logischerweise sollte man beim Atomkraftwerk erst die Brennstäbe in Sicherheit bringen, bevor man die Logik abschaltet.
Manche USB Geräte machen anscheinend gar keine Sicherheitsüberprüfung. Hier, zum Beispiel meine Tasta
Gerhard H. schrieb: > Das lässt sich durchaus alles im Detail diskutieren. Und sei es aus > Langeweile. Hier mit Sicherheit. :-)
Frank O. schrieb: > Hat gerade gar nichts mit der konkreten Anwendung zu tun. Du siehst an deinem Beispiel, dass es sehr auf die angeschlossene Hardware ankommt. Ein Mikrocontroller, an den keine weitere Hardware angeschlossen ist, kann ungestraft beliebigen Unfug treiben, ohne dass es irgend jemanden stört.
Lu schrieb: > Logischerweise sollte man beim Atomkraftwerk erst die Brennstäbe in > Sicherheit bringen, bevor man die Logik abschaltet. Ein AKW benötigt einen aktiven Failsafe, einfach einen bestimmten Zustand herstellen und danach ist alles gut funktioniert bei einem AKW eben nicht.
Franks µC-Weihnachtsbaumbeleuchtung definiert abzuschalten ist wesentlich einfacher: Stecker ziehen. Kannst jedoch gerne die neue Maschinenverordnung lesen (102 Seiten), um deine Gefahren zu berücksichtigen. https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32023R1230
Arduino F. schrieb: > Der TO will es nicht sagen, aber ihm nutzt olle 8Bit AVRs, möchte ich > behaupten. Kannst du das mal bitte ins Deutsche übersetzen? > Und da ist die Routine recht klar: Reset! > Ohne jede Alternative. > Damit sind alle Fehlfunktionen unterbunden, die sonst bei Unterspannung > auftreten könnten. Durch einen Reset kann eine für die Peripherie wichtige Funktion mittendrin – also quasi undefiniert – unterbrochen werden. Obendrein braucht man spezielle Hardware, sonst läuft der µP nach einem Reset weiter. >> Übrigens: Bei Geräten mit Batterieversorgung kann es vorkommen, dass bei >> ziemlich schwacher Batterie ein Brownout auftritt, wenn man mit dem µP >> eine Last einschaltet. > Vielleicht aufhören zu jammern, und mal die Batterie wechseln? Finde den Denk- und Argumentationsfehler.
Rolf schrieb: > Obendrein braucht man spezielle Hardware, sonst läuft der µP nach > einem Reset weiter. Was ja auch richtig ist. Das Programm muss warten, bis die Spannung ganz weg ist oder durchstarten, falls es nur ein kurzer Brown Out war.
In der Regel will man etwas erreichen, beim herunterfahren. Das ist niedriger Stromverbrauch, definierter Zustand der Peripherie oder was auch immer. Davon hängt ab, was sinnvoll ist. Will man nur die CPU stillegen, ist es wohl das einfachste, sie in Idle zu schicken. Da kommt man auch wieder schnell wieder heraus, z.B. mit einem Interrupt. Wenn man auf Batterie läuft, will man eventuell einen Stromverbrauch im unteren µA-Bereich haben, dann will man vermutlich alle Pins auf einen definierten Zustand und alle Peripherie im Disable haben, und die CPU in den sleep/deep-sleep versetzen. Meine Init-Routinen haben immer dafür auch immer einen Bool, der Peripherals auch wieder in den Ursprungszustand zurückversetzen kann. Willst du nur einen Reset, zum Beispiel um den Controller aus einer Exception zu retten, müsste man eben kucken was man Resetquellen zur Verfügung hat. Zur Not nutzt man den Watchdogtimer. Ob man in einem µC sowas brauchen sollte, steht auf einem anderen Blatt. Zum Debuggen ist das aber sehr praktisch.
Hallo, wo liegt denn nun das eigentliche Problem? Ich verstehe die Diskussion nicht. Erstmal muss man definieren welche Ereignisse zum Abschalten führen können bzw. sollen. Kann bspw. eine Unterschreitung der Batteriespannung sein. Dann muss man diese eben überwachen und bei Erkennung gezielte Maßnahmen abarbeiten. Oder es soll auf Tastendruck hin der µC in einen sicheren Zustand gebracht werden. Oder oder oder. Wenn man das definiert hat schaltet man alles so wie man es für richtig hält und belässt den µC bspw. in einer endlosen Warteschleife im Nichtstun oder bringt ihn in den endlosen Standby oder was man gerade bezweckt. Darin bleibt er bis man aktiv eingreift. Bsp. von mir Datalogger mit Powerbank versorgt und schreibt auf SD-Karte. Für die Versorgung habe ich die Powerbank modifiziert um die interne Akkuspannung zyklisch zu überwachen. Bei Unterschreitung einer Mindestspannung wird der letzte SD-Karten Schreibvorgang normal beendet und weitere gesperrt. Dann wird noch eine Kleinigkeit in ordnungsgemäßen Zustand gebracht und zum Schluss wird das Programm in eine leere Endlosschleife gebracht. Ab dann kann die Powerbank abschalten wann sie will. Leider gibt es diese Powerbank nicht mehr zu kaufen, denn die benötigt keine Mindestlast. Weil hier welche von Brown Out reden. Wenn dieser plötzlich auslösen sollte kann man vorher nichts sicher "runterfahren". Dann gibt es nur noch die Frage soll er aus bleiben oder soll er sauber resetet erneut einschalten. Die Frage nach dem ordnungsgemäßen "runterfahren" stellt sich zu dem Zeitpunkt nicht mehr. Das müsste man vorm Brown Out detektieren können. Danach ist es nutzlos für ein sauberes ausschalten. Wenn die Frage weiter greift was passiert wenn die Versorgung plötzlich weg ist und eine Maschine in einem sicheren Zustand sein soll, bspw. NOT-AUS, dann gibt es ganz andere Dinge zu beachten wie das µC Programm, denn das kann in der Regel dann nichts mehr machen, wird erst beim Wiedereinschalten interessant. Dann geht es um Dinge wie, wie sollen sich Pneumatikventile verhalten? Greifer auf oder doch lieber geschlossen lassen usw. Betrifft die Auswahl der Ventile und auch die Frage soll die Druckluft solange wie möglich erhalten bleiben oder soll sie kontrolliert abgelassen werden. So als Bsp. Das Geflecht der Gedankengänge kann unendlich werden.
:
Bearbeitet durch User
ArnoNym schrieb: > In der Regel will man etwas erreichen , beim herunterfahren. Solange das nicht klar beschrieben wird, ist dieser Thread unsinnig. Für mich ist ein µC Bestandteil eines Gerätes, um den sich der Benutzer nicht kümmern muß: Netzschalter aus, Strom weg, fertig und Ruhe. Die einzige Ausnahme könnte ein Gerät sein, welches Daten auf z.B. SD-Karte speichert. Da muß man dafür sorgen, die Datei abgeschlossen zu haben, bevor man vom Strom geht. Eine solche Konstellation habe ich, Betrieb mit Akku. Da gibt es einen FET in der Versorgung, über den der µC den Gesamtaufbau incl. sich selbst vom Strom nimmt und keinen mechanischen Netzschalter. Da fordere ich AUS über einen Taster an und der µC kann erstmal die Logdatei schließen, bevor alles stromlos wird. Sehe ich als Ausnahme und Frank sucht ein Problem, was er garnicht hat.
Veit D. schrieb: > wo liegt denn nun das eigentliche Problem? Ooops, da kam ein Kommentar, während ich geschrieben habe. > Bsp. von mir Datalogger mit Powerbank versorgt und schreibt auf > SD-Karte. Für die Versorgung habe ich die Powerbank modifiziert um die > interne Akkuspannung zyklisch zu überwachen. Bei Unterschreitung einer > Mindestspannung wird der letzte SD-Karten Schreibvorgang normal beendet > und weitere gesperrt. So ähnlich habe ich es in einem Aufbau. Der µC misst seine Akkuspannung und trennt sich selbst, bevor Fehlfunktionen wegen Unterspannung drohen. Deine weiteren Ausführungen passen genau zu meinen Gedanken. Pauschal "geordnet Abschalten" gibt es nicht, man muß den individuellen Aufbau bewerten.
Manfred P. schrieb: > Pauschal "geordnet Abschalten" gibt es nicht, man muß den individuellen > Aufbau bewerten. Stimmt. Wer abschalten will sollte schon wissen was genau.
Veit D. schrieb: > Das Geflecht der Gedankengänge kann unendlich werden. So ähnlich waren meine Gedanken dabei. Aber mittlerweile denke ich, dass das meiste dabei eh die zu steuernde Hardware betrifft.
Veit D. schrieb: > Das Geflecht der Gedankengänge kann unendlich werden. So ähnlich waren meine Gedanken dabei. Aber mittlerweile denke ich, dass das meiste dabei eh die zu steuernde Hardware betrifft. Manfred P. schrieb: > Pauschal > "geordnet Abschalten" gibt es nicht, man muß den individuellen Aufbau > bewerten. Da wären wir jetzt an einem Punkt, der doch schon einen Sinn dieser Diskussion ergibt.
Veit D. schrieb: > ... und eine Maschine in einem sicheren Zustand sein soll, bspw. NOT-AUS, Finde den Widerspruch. Bei vielen Maschine willst du keinen NOT-AUS. Nimm als Beispiel einfach einen Kran, der seine Last mit einem Elektromagneten hält. Da brauchst du einen koordinierten NOT-HALT, aber keinen kompromissloses NOT-AUS, sonst kann dir da sofort gewaltig etwas auf die Füße fallen.
NOT-HALT, NOT-AUS ... Sinn des sprichwörtlichen NOT-Knopfes ist eigentlich immer, eine Anlage in einen sicheren Zustand zu bringen- und damit nicht etwa neue Schwierigkeiten zu provozieren. Frank O. schrieb: > Da wären wir jetzt an einem Punkt, der doch schon einen Sinn dieser > Diskussion ergibt. Vielleicht wären wir jetzt an einem Punkt wo Du mal genauer spezifizierst, welche Controllerschaltung Du da nun eigentlich "geordnet abschalten" willst. Im Allgemeinen und Ungefähren wird die Diskussion hier nämlich sonst nur vom Durchkauen aller denkbaren Abschalt-Situationen und vom missverständnis-trächtigen Wechselspiel unterschiedlichster Wort-Interpretationen leben.
:
Bearbeitet durch User
Gerhard H. schrieb: > NOT-HALT, NOT-AUS ... Sinn des sprichwörtlichen NOT-Knopfes ist > eigentlich immer, eine Anlage in einen sicheren Zustand zu bringen- Eben - deswegen ist NOT-AUS (aka stromlos schalten) in vielen Anlagen ein No-Go. Da nützt es überhaupt nichts, wenn du beides in einem Topf schmeißt.
Rainer W. schrieb: > (stromlos schalten) in vielen Anlagen ein No-Go Sicherlich. Deshalb können hinter dem Begriff "NOT-AUS" aber trotzdem komplexere Vorgänge stehen als die blanke Stromtrennung für alles. Letztlich ist es doch egal wie der eine rote Knopf genannt wird. Darüber möchte man in der Gefahrensituation nicht mehr nachdenken müssen. Hauptsache er bewirkt das Richtige. Wir haben bei uns in chemischen Anlagen auch NOT-AUS Taster. Die bewirken zum Beispiel den Stopp von Produkt-Strömen und haben mit Stromzufuhr rein gar nichts am Hut.
:
Bearbeitet durch User
Frank O. schrieb: > Manfred P. schrieb: >> Pauschal >> "geordnet Abschalten" gibt es nicht, man muß den individuellen Aufbau >> bewerten. > > Da wären wir jetzt an einem Punkt, der doch schon einen Sinn dieser > Diskussion ergibt. Nöö, vollkommen sinnlos, ohne zu wissen, worum es konkret geht. Ein µC selbst braucht keinen geordneten Rückzug. Es ist eher die Anwendung um den µC herum, die das bestimmt. Und von der konkreten Anwendung wissen wir hier nichts. Rainer W. schrieb: > Nimm als Beispiel einfach > einen Kran, der seine Last mit einem Elektromagneten hält. Da brauchst > du einen koordinierten NOT-HALT, aber keinen kompromissloses NOT-AUS, > sonst kann dir da sofort gewaltig etwas auf die Füße fallen. Mit Helm und Arbeitsschutzschuhen ist das doch alles kein Problem ... ;-)
Jens G. schrieb: > Ein µC selbst braucht keinen geordneten Rückzug Wie schon gesagt nur für den Fall, daß gerade in (eigenen) nichtflüchtigen Speicher geschrieben wird.
Gerhard H. schrieb: > Jens G. schrieb: >> Ein µC selbst braucht keinen geordneten Rückzug > > Wie schon gesagt nur für den Fall, daß gerade in (eigenen) > nichtflüchtigen Speicher geschrieben wird. Ja, das ist aber dem µC selbst trotzdem egal, ob die Daten dabei korrumpiert werden. Es ist weiterhin die Anwendung, die evtl. verlangt, daß Maßnahmen gegen Datenkorruption vorgesehen werden (ich gebe zu, üblichwerweise will man das ... ;-).
Jens G. schrieb: > Es ist weiterhin die Anwendung, die evtl. verlangt, daß Maßnahmen gegen > Datenkorruption vorgesehen werden Das wäre dann eben dieser Punkt: Frank O. schrieb: > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Mikrocontroller und laufendes Programm- das lässt sich natürlich schlecht voneinander trennen. Die Controller-Hardware selber nimmt beim unvermittelten Abschalten/Reset keinen Schaden- könnte je nach Anwendung und bei Wiederanlauf dabei aber trotzdem funktionsunfähig werden- wenn es dabei nämlich auf richtige Daten in seinem EEPROM oder einem angeschlossenen nichtflüchtigen Speicher ankommt- die zuvor gerade beim Schreiben waren und jetzt fehlerhaft sind.
:
Bearbeitet durch User
Angehängte Dateien:
-
Zufallszeichen_.jpg
49 KB
Gerhard H. schrieb: > Wie schon gesagt nur für den Fall, daß gerade in (eigenen) > nichtflüchtigen Speicher geschrieben wird. Aber beim Wieder-Neustart sollten die Zufalldszeichen im SRAM mit Routine auch gelöscht werden. Sonst steht da im Display oben links zwei undefinerte " oder sowas (Siehe Bild) Der ganze Inhalt rutschte eine Stelle nach rechts. ciao gustav
Karl B. schrieb: > Aber beim Wieder-Neustart sollten die Zufalldszeichen im SRAM mit > Routine auch gelöscht werden. Sonst steht da im Display oben links zwei > undefinerte " oder sowas (Siehe Bild) > Der ganze Inhalt rutschte eine Stelle nach rechts. Richtig und vollständig initialisiert sollte ein solches Display keine solchen Probleme machen. Ganz unabhängig ob nach dem Einschalten oder dem Warmstart. Nur mit dem letzten Anzeigestatus kann man dann leider eben nicht in jedem Fall weitermachen.
:
Bearbeitet durch User
Veit D. schrieb: > Weil hier welche von Brown Out reden. Wenn dieser plötzlich auslösen > sollte kann man vorher nichts sicher "runterfahren". (...) Die Frage nach > dem ordnungsgemäßen "runterfahren" stellt sich zu dem Zeitpunkt nicht > mehr. Das müsste man vorm Brown Out detektieren können. Danach ist es > nutzlos für ein sauberes ausschalten. Wir sind hier nicht im Kontext "Stromversorgungsnetze oder -einrichtungen". Im Kontext µP bedeutet Brownout das Absinken der Versorgungsspannung unter einen bestimmten vorgegebenen Wert – mehr nicht. Dieser Wert bedeutet aber je nach Vorgabe nicht unbedingt, dass der µP bei Unterschreiten grundsätzlich nicht mehr sicher arbeiten kann. Es ist lediglich eine Warnung. Der µP kann dann noch mehr oder weniger lange problemlos weiterlaufen und Dinge erledigen. Beispielsweise kann die Versorgung per Elko oder Batterie gestützt sein oder es kann überhaupt eine reine Batterieversorgung sein. Da kann man vorher einigermaßen genau wissen, wie lange der Strom noch mindestens für sicheres Arbeiten reichen wird.
Hallo, für Batterieversorgung o.ä. und deren Überwachung mittels BOD sind die Einstellungen dafür nicht zu grob? Das wäre dann die Info Möglichkeit mit Interrupt. Ich habe BOD am µC als Notabschaltung betrachtet damit ein Programm keinen Mist machen kann, damit kein Bit quer liegt bzw. nicht quer liegen kann. ;-) Im Sinne wenn dann gar keine Programmausführung statt einer Fehlerhaften.
:
Bearbeitet durch User
Frank O. schrieb: > Wie schaltet man ein Gerät geordnet aus? Die Antwort ist gleichzeitig einfach und schwer. Die einfache Antwort: So wie es für das Gerät in den Anforderungen festgelegt wurde. Der schwere Teil ist: Die Anforderungen können beliebig komplex sein ;-) > Oder kann man schon beim Programmieren gewisse Regeln einhalten, dass es > zu keinen unerwünschten Effekten kommt? Beim Programmieren ist es ein bisschen spät, würde ich sagen. Erst mal kommt die Spezifikation. Und in der sollten auch Ausfallszenarien enthalten sein.
Rainer W. schrieb: > Bei vielen Maschine willst du keinen NOT-AUS. Nimm als Beispiel einfach > einen Kran, der seine Last mit einem Elektromagneten hält. Da brauchst > du einen koordinierten NOT-HALT, aber keinen kompromissloses NOT-AUS, > sonst kann dir da sofort gewaltig etwas auf die Füße fallen. Ich kann mir ja im Leben vieles vorstellen. Aber wie will man bei einem Ausfall der primären Energieversorgung in diesem Szenario einen sicheren Zustand erreichen? Sicher kann man eine Art Batterie bzw. USV in dem Kran verbauen. Die wird auch die Steuerelektronik noch eine Weile am Leben erhalten können bei einem Stromausfall. Aber eine schwere Last, die ausschließlich durch einen Elektromagneten gehalten wurde, der jetzt stromlos ist - die wird einfach der Schwerkraft folgen. Oder übersehe ich hier etwas?
Jens G. schrieb: > Es ist eher die Anwendung um > den µC herum, die das bestimmt. Und von der konkreten Anwendung wissen > wir hier nichts. Das ist aber doch auch eine wichtige Erkenntnis, wenngleich die Diskussion ein anderes Ergebnis hervorgebracht hat.
Zu einer "primären Energieversorgung" zählt aber z.B. auch eine (hallen)globale Pneumatikversorgung(sleitung). Hydraulische Energieversorgung wird wird üblich vor Ort generiert. Das "sichere Abschalten (bei Not-Aus usw.)"..., darüber denken Planer/Konstrukteure/Ingenieure vor! und auch während (Änderungen auf Kundenwunsch) der Konstruktionsphase gründlich nach. ...das geht dann auch - wie ich und die Kollegen gemacht und erfahren habe(n). mfG fE
:
Bearbeitet durch User
Bei unseren Fahrzeugen gibt es einen Überwachungsrechner. Aber auch die verschiedenen Rechner haben überwachende Elemente.
Karl B. schrieb: > Aber beim Wieder-Neustart sollten die Zufalldszeichen im SRAM mit > Routine auch gelöscht werden. Das ist einer der Nachteile von Assembler. Unter C kümmert sich der Compiler darum. Man kann natürlich auch Variablen davon ausschließen und sie in der .noinit section definieren.
Peter D. schrieb: > Das ist einer der Nachteile von Assembler. Jetzt werde doch bitte nicht albern. Das sind wenige Zeilen Code. Im übrigen möchte der Asm-Programmierer seinen Speicher ja gerade selber unter Kontrolle haben. Wie alles andere auch. Größere zu initialisierende Bereiche kopiert man einfach aus dem Flash um.
:
Bearbeitet durch User
Gerhard H. schrieb: > Im übrigen möchte der Asm-Programmierer > seinen Speicher ja gerade selber unter Kontrolle haben. Und der C-Programmierer ist froh, sich darum nicht mehr kümmern zu müssen. Für ihn sind das alles nur Variablen. Wo der Linker sie hinlegt, ist ihm herzlich egal. Er kann dadurch problemlos in einer Struct nachträglich Variablen einfügen oder entfernen oder Arrays ändern, ohne daß alles wie ein Kartenhaus in sich zusammen fällt. Alle Memberoffsets werden im nächsten Compile wieder richtig berechnet.
Peter D. schrieb: > Und der C-Programmierer ist froh, sich darum nicht mehr kümmern zu > müssen Das sei ihm doch von Herzen gegönnt. Für die Problematik kontrollierten Abschaltens spielt das ja nun hier keine Rolle. Das muß jenseits irgendeiner bestimmten Sprachverwendung gelöst werden- wie so vieles. Im Chaos von komplexeren Notabschaltungen sind dann die wahren "Kartenhäuser" zu finden und zu bewältigen.
:
Bearbeitet durch User
Gerhard H. schrieb: > Richtig und vollständig initialisiert sollte ein solches Display keine > solchen Probleme machen. Das gezeigte Fehlerbild hat mit der Initialisierung des LCDs selber primär nichts zu tun. Auch bei anderen Programmen kann noch etwas im RAM stehenbleiben, wenn wacklige Betriebsspannung vorherrscht und Speicherinhalte nicht völlig gelöscht werden. Deswegen sollte man sich den Luxus gönnen und beim Start die Löschroutine vorsehen. Schaden kann sie nicht. Es sei denn, man kennt die Adressen nicht genau. Peter D. schrieb: > Unter C kümmert sich der > Compiler darum. Man kann natürlich auch Variablen davon ausschließen und > sie in der .noinit section definieren. Wenn C das von sich aus macht, dann ist es ja gut. ciao gustav
Karl B. schrieb: > Das gezeigte Fehlerbild hat mit der Initialisierung des LCDs selber > primär nichts zu tun. Dazu kannst Du gar keine Aussage treffen weil Du weder den genauen Typ noch die Art der Ansteuerung kennst. Bei einer vollständigen Initialisierung wird der Anzeigespeicher gelöscht (ClearDisplay). > Deswegen sollte man sich > den Luxus gönnen und beim Start die Löschroutine vorsehen. Das sollte wie die eigentliche Display-Initalisierung nie Luxus sondern Standard nach jedem Reset sein.
Karl B. schrieb: > Wenn C das von sich aus macht, dann ist es ja gut. C und C++ macht das nur für globale Variablen und lokale Statische. Der Rest vom Speicher bleibt unberührt.
:
Bearbeitet durch User
Gerhard H. schrieb: > Dazu kannst Du gar keine Aussage treffen weil Du weder den genauen Typ > noch die Art der Ansteuerung kennst. Das Bild oben zeigt das Ergebnis des SRAM-Inhalts nach Ausführung des Programms. Du weißt garnicht, wovon Du redest, da Du "mein" Programm nicht kennst. Zur Kontrolle einer korrekten Initialisierung und der Zahlen-Umwandlungsroutinen sind nämlich noch weitere Strings eingebaut. Zum Beispiel Anzeige des Buchstabens A und anschließend die zugeordnete Ascii Dezimalzahl 65. Erscheinen kurz diese beiden Zeichen ganz links oben auf dem Display, ist es richtig initialisiert. Die fehlerhaften Zeichen kommen vom nicht sauber gelöschten SRAM. Dort finden sich Zufallsbits. Gerade, wenn Powercycling gemacht wurde. Der String hat also durchaus seine Berechtigung. Und da es hier um "sauberes" Arbeiten eines µC ging, gehört das IMHO auch hier hinein. ciao gustav
Arduino F. schrieb: > Der Rest vom Speicher bleibt unberührt. Heap und Stack enthalten bei jedem Funktionseintritt zufällige Daten, was eben die vorherigen Benutzer an Müll zurück gelassen haben. Daher bringt es überhaupt nichts, ihn nach einem Reset zu nullen. Wer sich temporär Speicher allokiert, muß ihn jedesmal auch selber initialisieren. In C reicht es, das erste Element zu initialisieren, um das ganze Array/Struct zu nullen.
Karl B. schrieb: > Du weißt garnicht, wovon Du redest Die Feststellung, daß ein Display ordentlich initialisiert keinen Müll anzeigt, langt an dieser Stelle völlig. Was Du darüber hinaus damit anstellst ist Deine Sache. Wenn (und nicht nur wenn) Displayinhalte regelmäßig vom Controller-RAM übertragen werden ist es doch selbstverständlich, daß eine entsprechende Neuinitialisierung desselben dazugehört.
:
Bearbeitet durch User
Beitrag #7643879 wurde vom Autor gelöscht.
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.