3.27. Watchdog-Timer¶

Ein Watchdog-Timer ist ein Stück Hardware, das den Mikrocontroller zurücksetzt, wenn das laufende Skript ihn jemals nicht mehr regelmäßig anstößt. Das Skript „füttert“ den Watchdog von einer Stelle aus, von der es weiß, dass dort gesunder Code läuft; wenn ein Bug, ein Hänger oder eine unerwartete Ausnahme die Kamera jemals daran hindert, den Watchdog innerhalb eines konfigurierten Timeouts zu füttern, setzt sich der Chip selbst zurück und das Skript startet neu.

Auf einem im Feld eingesetzten Gerät, bei dem kein Mensch in der Nähe ist, um es aus- und wieder einzuschalten, ist dies der Unterschied zwischen einem vorübergehenden Bug, der sich in Sekunden erholt, und einem Totalausfall, der einen Serviceeinsatz erfordert.

Der Watchdog-Zähler zählt von seinem Timeout herunter. Jedes feed() lädt ihn neu; wenn er null erreicht, setzt sich der Chip zurück.¶

3.27.1. Die Klasse machine.WDT¶

machine.WDT aktiviert den Watchdog und stellt eine einzige Methode bereit, feed(). Einmal gestartet, kann der Watchdog nicht mehr gestoppt werden – die einzigen Auswege sind, ihn planmäßig zu füttern oder ihn den Chip zurücksetzen zu lassen:

from machine import WDT

wdt = WDT(timeout=2000)    # reset if not fed within 2 seconds

while True:
    do_work()
    wdt.feed()

Der timeout ist in Millisekunden angegeben. Der richtige Wert hängt davon ab, wie lange die längste legitime Iteration der Hauptschleife dauert, mit komfortablem Spielraum – eine 100-ms-Schleife mit einem 2-s-Timeout hat reichlich Reserve für eine langsame Iteration, ohne lästige Resets.

3.27.2. Wo feed() aufgerufen wird¶

Wo feed() steht, ist die kritische Designentscheidung; der Watchdog fängt nur Bugs in den Teilen des Codes ab, die nicht zwischen den Fütterungen laufen.

Von der Hauptschleife aus aufrufen, am Anfang oder Ende. Das häufigste Muster. Der Watchdog fängt alles ab, was die Hauptschleife zum Hängen bringt – einen Deadlock, ein endloses while, ein Peripheriegerät, das nie zurückkehrt – und setzt den Chip zurück in die Schleife.
Nicht aus einem Interrupt-Handler heraus aufrufen. Der Sinn des Watchdogs ist es, Hänger im normalen Codepfad abzufangen. Eine ISR, die unabhängig davon auslöst, ob die Hauptschleife feststeckt, würde einen Watchdog weiterfüttern, der eigentlich auslösen sollte.
Nicht innerhalb einer langen blockierenden Operation aufrufen. Eine Netzwerkanfrage oder ein Sensorauslesen, das zehn Sekunden dauert, ist genau die Art von Hänger, die der Watchdog abfangen soll. feed() darin zu platzieren, untergräbt den Schutz.

Eine Richtlinie, die für die meisten Programme funktioniert: einmal pro Hauptschleifen-Iteration füttern, wobei der Timeout auf ein Vielfaches der erwarteten Schleifendauer gesetzt wird. Wenn eine einzelne Iteration legitim länger als der Timeout benötigt – etwa eine bewusste Kalibrierphase – gliedern Sie diese Phase als eine Reihe kleinerer Abschnitte mit feed() dazwischen, oder ändern Sie den Timeout mit timeout_ms() (sofern unterstützt), bevor Sie sie betreten.

3.27.3. Verfügbarkeit¶

Der Watchdog ist auf den meisten OpenMV-Kameras verfügbar, aber nicht auf allen – die Hardware ist auf jedem Bauteil vorhanden, aber die Python-API ist noch nicht überall angebunden. Prüfen Sie die OpenMV-Boards oder versuchen Sie, eine WDT zu konstruieren, und fangen Sie den AttributeError ab, falls sie nicht unterstützt wird.

Selbst auf Kameras, bei denen WDT nicht verfügbar ist, kann ein im Feld eingesetztes Gerät ein Software-Äquivalent verwenden – eine separate Aufgabe oder einen Hauptschleifenschritt, der den Fortschritt überwacht und machine.reset() auslöst, wenn etwas festzustecken scheint. Es ist weniger robust als ein Hardware-Watchdog (ein festgefahrener Interrupt-Handler kann auch den Software-Monitor lahmlegen), deckt aber dieselben Fälle auf Anwendungsebene ab.