Forum: Mikrocontroller und Digitale Elektronik Wie schaltet man eine Mikrocontrolleranwendung geordnet ab?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank O. (frank_o)


Lesenswert?

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!

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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.

von Daniel F. (df311)


Lesenswert?

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
von Christian M. (christian_m280)


Lesenswert?

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

von Frank K. (fchk)


Lesenswert?

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

von Frank O. (frank_o)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Michael B. (laberkopp)


Lesenswert?

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.

von Thilo R. (harfner)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

Thilo R. schrieb:
> Dein Ironiedetektor funktioniert nicht. Schalte den mal aus und wieder
> ein.

Und nicht die NOPs vergessen!

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

Thilo R. schrieb:
> Dein Ironiedetektor

Ne, aber darauf antworte ich wie erwartet.

von Bauform B. (bauformb)


Lesenswert?

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.

von Rainer W. (rawi)


Lesenswert?

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.

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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).

von Jens M. (schuchkleisser)


Lesenswert?

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!

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

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.

von Rolf (rolf22)


Lesenswert?

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.

von Rolf (rolf22)


Lesenswert?

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.

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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?

von Frank O. (frank_o)


Lesenswert?

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:

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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?"

von Gerhard H. (hauptmann)


Lesenswert?

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
von Lu (oszi45)


Lesenswert?

Logischerweise sollte man beim Atomkraftwerk erst die Brennstäbe in 
Sicherheit bringen, bevor man die Logik abschaltet.

von Norbert (der_norbert)


Lesenswert?

Manche USB Geräte machen anscheinend gar keine Sicherheitsüberprüfung.
Hier, zum Beispiel meine Tasta

von Frank O. (frank_o)


Lesenswert?

Gerhard H. schrieb:
> Das lässt sich durchaus alles im Detail diskutieren. Und sei es aus
> Langeweile.

Hier mit Sicherheit. :-)

von Rainer W. (rawi)


Lesenswert?

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.

von G. K. (zumsel)


Lesenswert?

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.

von Lu (oszi45)


Lesenswert?

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

von Rolf (rolf22)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von ArnoNym (bergler)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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
von Manfred P. (pruckelfred)


Lesenswert?

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.

von Manfred P. (pruckelfred)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

Manfred P. schrieb:
> Pauschal "geordnet Abschalten" gibt es nicht, man muß den individuellen
> Aufbau bewerten.

Stimmt.
Wer abschalten will sollte schon wissen was genau.

von Frank O. (frank_o)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

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.

von Rainer W. (rawi)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Rainer W. (rawi)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Jens G. (jensig)


Lesenswert?

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 ... 
;-)

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Jens G. (jensig)


Lesenswert?

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 ... ;-).

von Gerhard H. (hauptmann)


Lesenswert?

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
von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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
von Rolf (rolf22)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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
von Mark B. (markbrandis)


Lesenswert?

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.

von Mark B. (markbrandis)


Lesenswert?

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?

von Frank O. (frank_o)


Lesenswert?

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.

von Frank E. (ffje)


Lesenswert?

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
von Frank O. (frank_o)


Lesenswert?

Bei unseren Fahrzeugen gibt es einen Überwachungsrechner. Aber auch die 
verschiedenen Rechner haben überwachende Elemente.

von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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
von Karl B. (gustav)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Arduino F. (Firma: Gast) (arduinof)


Lesenswert?

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
von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.
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.