Hi zusammen, Ich habe letztens einen Beitrag hier gesehen und zwar bin ich im moment an etwas am Basteln um nicht zuweit auszuholen hier mein kurzes fiktives Problem. Ich habe einen µC und an dem Controller hängt ein Relais das eine Lampe schaltet wenn der µC Pin auf High ist. Nun könnte es ja theretisch passieren das der Controller abstürzt und trotzdem den Pin für die Lampe auf High lässt. Ich hatte da eine Schaltung gesehen in dem ich meine ein FET drin vorkam +ein paar Rs und Cs und zum Einschalten der Lampe hat der FET(?) ein Getaktes Signal gebraucht. Wenn der µC in dieser Umgebung abgestürzt ist war es sehr unwahrscheinlich das der PIN weiterhin einen Takt ausgibt und somit wird die Lampe ausgeschaltet. Nur wie nennt man so eine Schaltung ? ich find den Thread nicht mehr :/ Gruß Tom
Hallo dürfte ein Tiefpass mit Schaltstufe gewesen sein. Die Lösung für dein Problem heißt aber Watchdog.
Im Allgemeinen gehen die Pins auf "High Impendance" wenn der µC abstuerzt und koennen per Pull-Down auf definiert low gezogen werden. Mit Rs, Cs (und fuer Perfektionisten einem 555) koenntest Du aber auch eine Schaltung bauen, die nach X ms. ausschaltet, wenn sie vorher nicht erneut getriggert wurde. Von der Funktion her im Prizip wie die altbekannte "Treppenhausbeleuchtung". ;) Volker
...und wenn der 555 dann auch noch abstürzt? Klaus.
mhm nach einem Absturz weiss ich aber nicht wie die Ports vorher waren.
also es geht mir im moment nur theretisch darum. zb Ich habe 2 lampen X1 und X2 diese Dürfen unter keinen umständen zusammen leuchten weil dann keine ahnung die Umgebung zu heiss wird oder so. Und wenn der µC Abtürzt dann sollte halte sicher gestellt werden das kein High mehr auf dem Ausgang liegt um die Lampen anzusteuern
Volker Schulz schrieb: > Im Allgemeinen gehen die Pins auf "High Impendance" wenn der µC > abstuerzt und koennen per Pull-Down auf definiert low gezogen werden. warum sollte das so sein? Ein Abstutz würde ich als ein Software fehler bezeichnen und da ändert sich nur etwas am Status der ausgänge wenn eine passender upcode vorbeikommt. Wenn es aber nur eine schleife ist aus der der µC nicht rauskommt, dann ändert sich auch am Port nichts.
Wenn er abstützt hat das meist eine Softwareseitige Ursache. Also eher Fehler suchen (auch EMV). Wenn es wirklich nicht anders geht, dann den Watchdog verwenden und bei einem Reset die Lampe abschalten.
Tom schrieb: > also es geht mir im moment nur theretisch darum. zb Ich habe 2 lampen X1 > und X2 diese Dürfen unter keinen umständen zusammen leuchten weil dann > keine ahnung die Umgebung zu heiss wird oder so. dann mache es per hardware - ein pin schalter zwischen den lampen um, der andere pin schaltet ein und aus. Damit können NIE beide Lampen leuchten.
Peter schrieb: > Volker Schulz schrieb: >> Im Allgemeinen gehen die Pins auf "High Impendance" wenn der µC >> abstuerzt und koennen per Pull-Down auf definiert low gezogen werden. > > warum sollte das so sein? Ein Abstutz würde ich als ein Software fehler > bezeichnen und da ändert sich nur etwas am Status der ausgänge wenn eine > passender upcode vorbeikommt. > Wenn es aber nur eine schleife ist aus der der µC nicht rauskommt, dann > ändert sich auch am Port nichts. Korrekt, aber eine Endlosschleife wuerde ich nicht als Absturz definieren... Wenn doch, dann bleiben wirklich nur noch Watchdog und/oder retriggerbarer Monoflop. Volker
Volker Schulz schrieb: > Korrekt, aber eine Endlosschleife wuerde ich nicht als Absturz > definieren... Wenn doch, dann bleiben wirklich nur noch Watchdog > und/oder retriggerbarer Monoflop. Eine "unbeabsichtigte" Endlosschleife nenne ich falsches Softwaredesign und "besser machen".
ich schrieb:
> nimm LEDs, die werden nicht so warm :-)
Oder zwei Ports auf je ein Umschaltrelais. Das erste schaltet nur ein
und aus; das zweite schaltet zwischen den Lampen um. Dann kann nur eine
gleichzeitig leuchten.
Klar, bei einem Softwarehänger könnte es sein, dass die Lampe nie
ansgeht. Aber auch da gibt es voll mechanische Thermostate. Die Schalten
aus, wenn es wirklich zu warm wird.
Christian H. schrieb: > Volker Schulz schrieb: >> Korrekt, aber eine Endlosschleife wuerde ich nicht als Absturz >> definieren... Wenn doch, dann bleiben wirklich nur noch Watchdog >> und/oder retriggerbarer Monoflop. > > Eine "unbeabsichtigte" Endlosschleife nenne ich falsches Softwaredesign > und "besser machen". Darauf koennen wir uns einigen! Ganz uebel wird's natuerlich wenn man den Watchdog ausgerechnet in dieser Schleife zuruecksetzt... ;) Volker
Mhm ich glaub wir reden grade an einander vorbei?! Klar kann man es Software technisch lösen aber ich ginge eigentlich von dem fall aus das der µC an den Port Pins ein High oder Low ausgibt und diese Dürfen in einem Statischen zustand NICHTS schalten könnten. Nur wenn der Pin mit einer Frequenz toggelt dann darf das Objekt an dem Pin geschaltet werden. Und wenn der Controller dann Abstürzt/Restettet/Durchbrennt/Kurzschluss auf Signal Leitung macht oder die Versorgungspannung abgetrennt bekommt dann wird das Objekt NIE geschaltet weil das toggeln fehlt. Und da hatte ich halte eine Schaltung gesehn die sowas realisiert hatte aber ich find sie nimmer :/
>>Korrekt, aber eine Endlosschleife wuerde ich nicht als Absturz definieren
Was ist denn euer Meinung nach ein Absturz?? Wenn die Platine mit dem yC
runterfällt? Natürlich kommt es durch einen Softwarefehler zum Absturz,
wodurch sonst? Durch Unterspannung? Dann ist es auch ein Softwarefehler,
das hätte man mit der brown out detection erkennen und korrekt behandeln
können.
Was ist dann ein Microsoft Bluescreen? Kein Absturz, kein Softwarefehler
sondern höhere Gewalt?
Ein Absturz ist ein Rechner bzw. das Programm das nicht mehr (richtig)
arbeitet und reagiert und das kommt seltenst von kosmischer Strahlung,
vieleicht manchmal von EMV und meistens durch die Software und damit vom
DAP (= dümmsten anzumehmenden Programmierer, davon mehr ich mich auch
nicht aus :-))
Fact ist daß der Zustand der Ports bei einem Absturz der Software
undefiniert ist. Alles weitere wurde ja schon gesagt, Watchdog oder bei
kritischen Dingen hardwareseitig verriegeln.
um der sinnlosen Diskussion ein Ende zu bereiten, das müsste die gesuchte Schaltung sein: http://www.hanneslux.de/avr/zuenduhr/lapu.html Gruss Ronny
Udo R. S. schrieb: >>>Korrekt, aber eine Endlosschleife wuerde ich nicht als Absturz definieren > > Was ist denn euer Meinung nach ein Absturz?? Wenn die Platine mit dem yC > runterfällt? Natürlich kommt es durch einen Softwarefehler zum Absturz, > wodurch sonst? Durch Unterspannung? Dann ist es auch ein Softwarefehler, > das hätte man mit der brown out detection erkennen und korrekt behandeln > können. > > Was ist dann ein Microsoft Bluescreen? Kein Absturz, kein Softwarefehler > sondern höhere Gewalt? > > Ein Absturz ist ein Rechner bzw. das Programm das nicht mehr (richtig) > arbeitet und reagiert und das kommt seltenst von kosmischer Strahlung, > vieleicht manchmal von EMV und meistens durch die Software und damit vom > DAP (= dümmsten anzumehmenden Programmierer, davon mehr ich mich auch > nicht aus :-)) > > Fact ist daß der Zustand der Ports bei einem Absturz der Software > undefiniert ist. Alles weitere wurde ja schon gesagt, Watchdog oder bei > kritischen Dingen hardwareseitig verriegeln. Wenn Microsoft Word in einer Endlosschleife haengt, wird Dein Rechner nicht abstuerzen und Du wirst auch keinen Bluescreen sehen... Kann ich Dir garantieren! Der Bluescreen ist uebrigens eine Art "Watchdog", der den Computer resettet wenn z.B. ein potentiell gefaehrlicher Hardwareaufruf geschieht. Er re-bootet um den Computer wieder in einen definierten Zustand zu bringen. Ich denke aber auch, dass die urspruengliche Frage im Kern beantwortet wurde. ;) Volker
Ja Genau Ronny das war die seite !! Danke :D
Der Vollstaendigkeit halber noch die allgemeine Beschreibung eines (retriggerbaren) Monoflops: http://de.wikipedia.org/wiki/Monostabile_Kippstufe
Hallo, rekordverdächtig: eine einzige sinnvolle Antwort, ca. 20 Antworten total daneben. (Alles ausser dynamischer Kopplung, also Takt mit Kondensator, ist keine brauchbare Lösung - ein Monflop-IC ist auch schon wieder was, das ausfallen kann. Also so wenig komplex wie möglich!) Vielleicht habe ich nachts auch einfach nicht mehr die Nerven für solches hohles Geschwätz. Gruss Reinhard
Nun, schon die erste Antwort war gleich die richtige. Der Watchdog ist genau für diesen Zweck gemacht worden. Alles andere ist sinnloser Overkill.
Ich kenne das auch als "Charge Pump". Google mal nach Ostermann Schrittmotoren, 3D Step oder wie das heisst. Dort gibt es im Download-Bereich den Schaltplan für ein Breakout-Board, da wird genau soetwas eingesetzt. Der PC muss ständig einen Takt rausschieben, sonst wird von diesem Board der Notaus ausgelöst.
Hi Zitat aus dem Ursprungspost: >Nun könnte es ja theretisch passieren das der Controller abstürzt und >trotzdem den Pin für die Lampe auf High lässt. Bevor man hypothetische Symptome bekämpft, sollte man theoretische Ursachen suchen und beseitigen. MfG Spess
Tom schrieb:
> mhm nach einem Absturz weiss ich aber nicht wie die Ports vorher waren.
Tja, wenn er abstuerzt, dann weiss man auch nicht ob der Zustand in dem
er war nicht ein sehr unerwuenschter Zustand war, deshlab ist er ja
abgestuerzt.
Nach einem Absturz heisst die logische Fortsetzung der Geschichte RESET.
Robert
Ja. Wenn man die Kontrolle verloren hat, kann man neu booten. dann hat man die Kontolle wieder. Zumindest was den Contoller betrifft. Aber nicht was den externen Prozess betrifft. Wichtiger als neu zu booten ist neu auf den externen Prozess aufsetzen zu koennen. Das bedeuet, man darf die Kontrolle wegen Software nicht verlieren, denn in irgend einem Zustand wird er dauernd neu booten, was ja nicht als Kontolle bezeichnet werden kann. Ein erster Beginn ist keinen Code zu verwenden, den man nicht kennt. Also keine Libraries, die irgend was Tolles zu machen vorgeben, aber gewisse Parameter dann unerwarteterweise nicht akzeptieren.
> diese Dürfen unter keinen umständen zusammen leuchten
ich würde ein xor-gatter zusätzlich zum yC in betracht ziehen.
>rekordverdächtig: eine einzige sinnvolle Antwort, ca. 20 Antworten total >daneben. >(Alles ausser dynamischer Kopplung, also Takt mit Kondensator, ist keine >brauchbare Lösung - ein Monflop-IC ist auch schon wieder was, das >ausfallen kann. Also so wenig komplex wie möglich!) >Vielleicht habe ich nachts auch einfach nicht mehr die Nerven für >solches hohles Geschwätz. Eine kalte Lötstelle kann auch einen Ausfall verursachen, also 21. hohle Antwort! MfG
Hi Um ein einigermaßen sicheres Schalten der Ausgänge zu erreichen und dein Programm zu prügen, wäre folgendes auch denkbar: der Timer. In der Timer ISR prüfst du z.B. alle paar ms eine Variable, sagen wir auf 255 ( alle Bits 1). Ist dem so, kannst du davon ausgehe, das dein Programm alles abgearbeitet hat und setzt die Ausänge entsprechend einem zwischengespeichertem Ergebnis. danach schreibst du in dein Prüfbyte eine 0. Ist ein Bit nicht gesetzt, kannst du sogar auswerten, welche Routine noch gearbeitet hat und was nicht erledigt wird. Die Bits setzt du im Hauptprogramm entsprechend ein. Vielleicht ist's auch möglich, die Timer-ISR mittels Watchdog zu prüfen. Dann sollte es möglich sein, den Wachhund die Lichter ausblasen zu lassen..... Gruß oldmax
Kann man denn erkennen, dass der µC soeben durch den Watchdog resetet wurde und es kein externer Reset/Neustart war? Das würde ja zum Wiederaufsetzen helfen. Gruß Tom
Absolute Sicherheit wirds wohl nie geben. ALLES kann kaputt gehen. Je nach dem wie schwerwiegend die Folgen sein könnten, muss man mehr oder weniger Aufwand betreiben um die Gefahr zu minimieren. Aber ausschließen ist nicht möglich.
wenn das Ding ''abstuerzt'' soll eine Quecksilberschalterampulle zerbrechen und jeglichen Stromfluss unterbrechen. Das ist die praktische Loesung fuer deine Hypothese. Du brauchst aber einen Quicksilver Besen !
Thomas Burkhart schrieb: > Kann man denn erkennen, dass der µC soeben durch den Watchdog resetet > wurde und es kein externer Reset/Neustart war? Wenn es ein AVR ist, gibt's dafür ein Bit. Das Codefragment
1 | // check where reset came from
|
2 | if (MCUCSR & (1 << WDRF)) { |
3 | prs("### reset by watchdog ###\n"); |
4 | }
|
5 | MCUCSR = 0; // reset for next reset |
sollte bei der Suche im Datenblatt helfen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.