Ein Raspberry Zero soll über seine serielle Schnittstelle mit einem µC (ATtiny o. ä.) verbunden werden. Der µC soll den Raspberry überwachen und im Fehlerfall neu starten. Wie kann der µC sicher erkennen, ob der Raspberry einwandfrei arbeitet?
Ich würde einfach einen GPIO togglen lassen und das mit dem ATtiny detektieren. Fehlen n Signale über ein bestimmten Zeitraum, einfach einen Reset auslösen.
Horstmann schrieb: > Wie kann der µC sicher erkennen, ob der Raspberry einwandfrei arbeitet? Das ist unmöglich. Stell dir vor durch kosmische Strahlung verheddert sich etwas im NEON-Block des Prozessors, wodurch unter einer Millionen Float-Multiplikationen eine ein falsches Ergebnis liefert. Wie soll der ATtiny mit seiner winzigen Rechenleistung eine solche Menge an Daten prüfen? Ähnliches gilt für alle anderen High Performance / Multimedia-Funktionen des Raspberry PI, wie die Grafikkarte, Schnittstellen für HDMI, USB, Ethernet, WLAN und natürlich der große RAM - dort sind solche Datenmengen involviert, die kann kein Mikrocontroller in Echtzeit prüfen.
Udo Neist schrieb: > Ich würde einfach einen GPIO togglen lassen und das mit dem ATtiny > detektieren. Fehlen n Signale über ein bestimmten Zeitraum, einfach > einen Reset auslösen. Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen GPIO triggert. Bei Power_On schaltet der Tiny den Raspberry an (vllt. mit nem kleinen Delay), wartet dann eine gewisse Zeitspanne (3-4min, kann wegen fsck auch mal länger dauern) auf ein Signal am GPIO. Sobald da einmal getriggert wurde (bzw. der initiale Timeout erreicht wurde) wird im Tiny auf Watchdog-Betrieb umgeschaltet, der regelmäßige Impuls resettet den Watchdogtimer. Bleibt der aus geht der Tiny in Reset und damit auch der RPi. Und dann fängt der Zyklus von vorne an...
:
Bearbeitet durch User
Typische Aufgabe für einen Window-Watchdog. Es darf nicht zu häufig getriggert werden und auch nicht zu selten. Ich würde noch einen weiteren GPIO einplanen, damit man den Watchdog erst aktivieren kann, wenn der RPi komplett gestartet ist. Sonst löst du ein Reset aus während der RPi gerade normal bootet. Gruß Daniel Nebenbei, externe Watchdogs werden bei einer Sicherheitsbewertung immer gerne gesehen :-)
Horstmann schrieb: > Wie kann der µC sicher erkennen, ob der Raspberry einwandfrei arbeitet? Und wer überwacht den Tiny? Den Watchdog kannst du auch mit einem retriggerbaren Monoflop umsetzen.
Alexander S. schrieb: > Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen > GPIO triggert. So prüfst du aber nur ob das Python-Skript und der GPIO funktioniert. Es kann aber halt auch alles mögliche andere kaputt sein.
Programmierer schrieb: > So prüfst du aber nur ob das Python-Skript und der GPIO funktioniert. Reicht doch. Das Skript muss halt auf dem RPi schauen ob die gewünschte Funktionalität (zB. das ein Server/Service läuft) gegeben ist. Wie genau das überlass ich mal dem TO.
:
Bearbeitet durch User
Horstmann schrieb: > Ein Raspberry Zero soll über seine serielle Schnittstelle mit einem µC > (ATtiny o. ä.) verbunden werden. Der µC soll den Raspberry überwachen > und im Fehlerfall neu starten. Dann laß doch den ATtiny zyklisch etwas schicken und der RP muß eine Antwort dazu basteln. Stimmt die Antwort nicht -> Reset. 9600 Baud sollte reichen, das schafft ein ATtiny25 mit Bitwackeln (Quarz = 7.3728MHz).
Oder du nimmst einen 2. Raspberry. Ich habe mein smart Home zeug darauf laufen und die beiden prüfen sich in mehreren Faktoren wie Ping, Mqtt und ob die Software noch läuft. Wenn was nicht passt übernimmt der 2. Raspberry und startet den ersten neu welcher dann wieder als Reserve dient. Das musst du aber nach deiner Anwendung individuell prüfen ob das geht und ob sich das lohnt. Stichwort high availability cluster
Programmierer schrieb: > Es kann aber halt auch alles mögliche andere kaputt sein. Es kann auch ein Flugzeug drauf gefallen sein... Programmierer schrieb: > Stell dir vor durch kosmische Strahlung verheddert sich etwas im NEON-Block > des Prozessors In sehr viel mehr als 99,999% aller ko(s)mischen Fehlerfälle hat sich da erfahrungsgemäß einfach deshalb was verheddert, weil der Programmierer einen Fehler in der Software hat.
Lothar M. schrieb: > In sehr viel mehr als 99,999% aller ko(s)mischen Fehlerfälle hat sich da > erfahrungsgemäß einfach deshalb was verheddert, weil der Programmierer > einen Fehler in der Software hat. Umso schlimmer. Dann gibt das Programm fröhlich den Watchdog-Puls aus, aber berechnet aufgrund eines Programmierfehlers irgendeinen Regler falsch und grillt die Regelstrecke...
> alle ko(s)mischen Fehlerfälle Für wirklich sicherheitskritische Aufgaben nimmt man deshalb kein Raspberry, sondern zwei möglichst einfach gestrickte RISC Controller wie 2 ATtinys oder 2 PICs. Das Projekt (der Regler) wird compiliert und alle verwendeten Assemblerbefehle aufgelistet. Der ATtiny stellt sich dann selber eine Aufgabe, welche genau jeden dieser Befehle mindestens ein mal verwendet. Nun kann das Rechenergebnis mit dem erwarteten Ergebnis verglichen werden. Tritt eine Abweichung ein, stellt dieser Controller die Kommunikation ein und geht in Störung. Duch das fehlende Lebenszeichen geht der andere Controller auch in Störung.
Falls es hilft -> jemand hats schon gebaut und verkauft es. https://de.aliexpress.com/wholesale?catId=0&initiative_id=SB_20210824005848&SearchText=Raspberry+Watchdog
Alexander S. schrieb: > Udo Neist schrieb: >> Ich würde einfach einen GPIO togglen lassen und das mit dem ATtiny >> detektieren. Fehlen n Signale über ein bestimmten Zeitraum, einfach >> einen Reset auslösen. > > Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen > GPIO triggert. Das erfüllt aber nicht die Anforderung des TO: Horstmann schrieb: > sicher erkennen, ob der Raspberry einwandfrei arbeitet Es erkennt nur ob das Python Skript noch funktioniert. Und unter Umständen noch nicht mal das (wenn jemand anderes am Pin wackelt). Und damit ist klar, was am Anfang stehen muß: eine möglichst exakte Definition, was "einwandfrei arbeitet" überhaupt bedeuten soll.
Axel S. schrieb: > Horstmann schrieb: >> sicher erkennen, ob der Raspberry einwandfrei arbeitet > Es erkennt nur ob das Python Skript noch funktioniert. Und unter > Umständen noch nicht mal das (wenn jemand anderes am Pin wackelt). Einer unserer Softies hatte mal die gloriose Idee, für das Rücksetzen des externen Watchdogs einen eigenen Timerinterrupt zu verwenden. Und dem hat er dann noch die höchste Priorität gegeben. Der Grund: "Sonst gibt es immer wieder diese Timeout-Fehler und das Ding läuft in einen Reset!" ;-)
Lothar M. schrieb: > Einer unserer Softies hatte mal die gloriose Idee, für das Rücksetzen > des externen Watchdogs einen eigenen Timerinterrupt zu verwenden. Das ist durchaus keine schlechte Idee. Dieser Interrupt enthält dann mehrere Timeouts, die von den jeweiligen Tasks zurück gesetzt werden. Ist einer davon abgelaufen, geht der Handler in eine Endlosschleife. Es gibt auch bessere externe Watchdogs, die ein Zeitfenster überwachen. D.h. der Resetimpuls darf weder zu langsam noch zu schnell erfolgen.
Alexander S. schrieb: > Genau so. Auf dem RPi läuft ein Python-Skript oÄ. das regelmäßig einen > GPIO triggert. Würde ich auch so lösen, aber der Tiny sollte noch ein/zwei Byte des EEPROM nutzen, um einen Zähler einzubauen, den man abfragen kann. So läßt sich erkennen, ob der Watchdog zugeschlagen hat und wie oft.
Gerade unter Linux kommt es äußerst selten vor, dass ein Rechner sich komplett aufhängt. Man kann sich fast immer noch einloggen und analysieren, warum eine bestimmte Funktion oder ein bestimmtes Programm gerade versagt. Insofern sollte man das testen, was funktionieren soll. Also wenn der Sinn des Gerätes z.B. ist, eine Lampe blinken zu lassen, dann testet man ob die Lampe blinkt. Und wenn er Daten in eine DB speichern soll, dann tut man das und testet, ob sie auch wieder zurück gelesen werden können.
Ich habe mich auch für die GPIO Lösung entschieden. Grobes Konzept: Es gibt bei mir auf dem pi ein python script, bei dem sich andere Scripte registrieren können. Sie müssen sich dann jedoch zyklisch melden. Wenn sie das machen, wird ein GPIO Pin getoggelt. Steigt also eins der Skripte aus, hört das Toggeln auf. Der uC prüft, ob der pi den GPIO toggeln lässt. Er resettiert den pi, wenn der pi das Toggeln einstellt. Außerdem zählt der uC die Anzahl der Resets mit. Wenn mehr als 7 Resets in Folge auftreten oder in 30Min mehr als 7x resettiert wird, hält der uC den pi im Reset und stellt eine Art Notbetrieb sicher - er übernimmt dann die I2C-Masterrolle vom pi.
Stefan ⛄ F. schrieb: > Man kann sich fast immer noch einloggen und > analysieren, warum eine bestimmte Funktion oder ein bestimmtes Programm > gerade versagt. Kann der Attiny so natürlich nicht. Aber er kann zyklisch etwas vom RPI verlangen... kann beliebig komplex werden. Vorschläge gab es ja schon. Einfach ausgedrückt realisiert man eine "Tot-Mann/RPI-Sicherung". Und auch die Schlaumeier des ewigen Regress' könnten sich sinnvolle Gedanken zu diesem Szenario machen! Allerdings ist es müßig, das in einer allumfassenden Allgemeinheit aufzudröseln. Also wann muß Alarm kommen und von wem!? Gruß Rainer
Rainer V. schrieb: >> Man kann sich fast immer noch einloggen > Kann der Attiny so natürlich nicht Doch kann er, über einen seriellen Port.
Stefan ⛄ F. schrieb: > Doch kann er, über einen seriellen Port. Ja und dann startest du vom Tiny ein Diagnoseprogramm??? Ich verstehe es wohl nicht. Ich dachte, du meinst die diversen Logfiles, die Python anlegt und die man sich "natürlich" am PC anschaut oder? Vielleicht liege ich aber auch komplett falsch. Gruß Rainer
Rainer V. schrieb: > Ja und dann startest du vom Tiny ein Diagnoseprogramm??? Grins. Das kann der Raspi dann auch selbst starten. Die Frage ist, wie sieht eigentlich eine angemessene Reaktion auf einen Ausfall aus? Nicht immer ist ein simpler Neustart hilfreich. Und nicht immer funktioniert der Neustart ohne vorher die eigentliche Problemursache zu beheben. Ich stelle mir gerade vor, wie der Projektor im Kino alle 40 Minuten einen Reset macht und wieder von vorne beginnt :-)
Programmierer schrieb: > irgendeinen Regler falsch und grillt die Regelstrecke... Oder eher der Pflanzentopf wird übergossen, bzw. geflutet.
Stefan ⛄ F. schrieb: > Man kann sich fast immer noch einloggen und Kannst du das als mein Problem akzeptieren? Mich treibt die Frage um, ob der Attiny das kann! If you see what I mean... Gru0 Rainer
Rainer V. schrieb: > Kannst du das als mein Problem akzeptieren? > Mich treibt die Frage um, ob der Attiny das kann! Ich habe deine Frage bereits beantwortet. Der ATtiny kann sich über eine Serielle Verbindung auf das Linux einloggen. Das geht genau so, wie auf dem Bildschirm in einer Text-Konsole. https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/enabling-serial-console https://www.embeddedpi.com/documentation/serial-console/mypi-industrial-raspberry-pi-raspbian-serial-console Geht sogar ohne Passwort, wenn du willst: https://blog.oddbit.com/post/2020-02-24-a-passwordless-serial-console/
Warum nimmst du nicht den Watchdog den der Raspi schon an Bord hat?
Stefan ⛄ F. schrieb: > Ich habe deine Frage bereits beantwortet. Ja, aber ich kapiers nicht. Ich verstehe ja, dass der Tiny sich da über die ser. Schnittstelle einloggen kann, aber wie soll er denn die System/Errormeldungen von Python auswerten? Da braucht es doch entweder einen Menschen oder einen (mindestens) PC. Verstehst du mein Proble?? Aber wir sollten hier doch nicht in eine Privatdebatte ausarten. Die Vorstellung (meine), dass ein Programm auf einem Tiny das Python-System auf dem RPI analysiert und auch noch entsprechend komplex reaiert, halte ich für schlicht unmöglich... Gru0 Rainer
Rainer V. schrieb: > aber wie soll er denn die > System/Errormeldungen von Python auswerten? Er kann Befehle als String senden und die Ergebnisse als String empfangen. So ein Befehl könnte z.B. lauten: > tail -1000 /var/log/messages In der Antwort kann er auf Schlüsselwörter reagieren, wie "ERROR". Oder man kontrolliert, ob die gewünschten Prozesse noch laufen: > ps -ef Und dann schauen, ob da etwas mit "meinscript.py" vorkommnt. Ich erkläre dir jetzt aber nicht, wie man Strings in C programmiert.
Ok, danke stefanus. Habs kapiert...und bin verblüfft...auch über mich natürlich. Und da ich kein "Hochsprachler" bin, würde ich meine Strings sowieso selbst machen :-) Gruß Rainer
Ein wichtiger Knackpunkt sind die Abfragen, die an das System gestellt werden. Zum Beispiel erkennen von viel zu langer Vollauslastung der CPU, der RAM überläuft, sich die SD-Karte abhängt oder voll ist, wenn das Netzwerk weg ist, usw.
> Warum nimmst du nicht den Watchdog den der Raspi schon an Bord hat?
Weil der dazu gehörende Watchdog Deamon nicht mit der Fake-Hwclock
zusammen arbeitet. (Sobald der NTP die Uhrzeit setzt, gibt es einen
Reset).
Brauchst Der Opa aus der Muppet Show schrieb: >> Warum nimmst du nicht den Watchdog den der Raspi schon an Bord > hat? > > Weil der dazu gehörende Watchdog Deamon nicht mit der Fake-Hwclock > zusammen arbeitet. (Sobald der NTP die Uhrzeit setzt, gibt es einen > Reset). Wofür brauchst du den Watchdog-Daemon? Einfach alle paar Sekunden auf /dev/watchdog schreiben, das wars. Schreibst du für 15sek nichts, gibts nen Hardware-Reset. Mach ich auch so und funktioniert prächtig.
Na ja, die Entwickler des Watchdog-Daemon haben sich schon so einige Gedanken gemacht wie du konfiguriert, was für dich "Raspi läuft einwandfrei" bedeutet. Die ganzen Überprüfungen musst du ohne Daemon halt selbst schreiben. Und die versuchen, ob man noch sauber runter fahren kann, bevor der Hardware Watchdog zuschlägt.
Im Grunde ist es doch die gleiche Frage (zumindest für mich naivem) warum hat mein PC Mist gemacht! Und das durch einen Controller machen zu lassen kommt mir schon blöd vor. Will ich tatsächlich nach einem Chrash noch genau wissen, was das XY-Logfile dazu zu sagen hat??? Ich will wissen, ob es einen Angriff gegeben hat---klar und ich will vielleicht wissen, ob die SC-Karte sich nicht mehr meldet...aber man sieht schon, dass da Einbildungskraft gefordert ist! Anders herum...der RPI muß eine LED blinken lassen und der Controller soll überwachen/kontrollieren, ob das läuft. Wenn's nicht mehr läuft, hängt alles von dem Folgeszenario ab. Im schlimmsten Fall, hätte der Controller nix mehr zu kontrollieren (Ich empfehle Degenhard, "In den guten alten Zeiten") Gruß Rainer
Rainer V. schrieb: > Im Grunde ist es doch die gleiche Frage (zumindest für mich naivem) > warum hat mein PC Mist gemacht! Und das durch einen Controller machen zu > lassen kommt mir schon blöd vor. Will ich tatsächlich nach einem Chrash > noch genau wissen, was das XY-Logfile dazu zu sagen hat? Das ist gar nicht die Aufgabe des Watchdogs. Vollkommen egal, wie der realisiert ist. Der soll nur dafür sorgen, daß dein PC nicht hängen bleibt. Ob das das Resultat einer grottigen Software, ein Hardwarefehler oder ein Angriff war, ist dafür nebensächlich.
Der Attiny wartet alle x Sekunden auf ein "ping" auf der GPIO-Leitung. Am Ende wird als einziges Skript aus dem Raspberry noch das Programm laufen was regelmäßig den GPIO hochzieht. Sollte der Attiny dann doch was mitbekommen und den Raspberry resetten wird dabei die SD-Karte zerschossen. Totmann-Schaltungen zur Überwachung sind komplizierter als man denkt.
Die ARM-CPUs haben den Nachteil, daß man sie mit hoher Interruptlast anhalten kann, d.h. die Mainloop bleibt stehen, bis kein Interrupt mehr pending ist. Z.B. eine floatende Interruptleitung fängt sich eine hochfrequente Störung ein. Im Gegensatz dazu führt z.B. ein 8051 oder AVR nach jedem RETI erst einen Befehl der Mainloop aus, bevor in den nächsten Handler gesprungen wird. Die Mainloop wird zwar langsam, kann aber noch auf Kommandos reagieren und z.B. eine Task mit hoher Interruptrate abschießen.
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.