Hallo allerseits Ich arbeite zur Zeit an einer grösseren uC-Software mit einem kommerziellen RealTimeOS. (ca. 2000 Sourcedateien, Binary-Executable ca. 3 MByte) Die Software besteht aus zahlreichen Tasks unterschiedlicher Priorität. Einer der Task ist der WatchdogTriggerTask WDT(), welcher den Watchdog alle 250ms triggern soll, der Watchdog-Timeout liegt bei ca. 2.5 Sekunden. Die Software muss beim Kunden über Wochen zuverlässig laufen, ohne Ausfälle oder Restarts. Die Rechenleistung des Prozessors ist ausreichend bemessen, die CPU-Belasung liegt ca. zwischen 10..40% Bisher lief die SW stabil auch mit einer beliebig tiefen WDT()-Prio. Kürzlich ist jedoch ein neuer Task hinzugekommen, welcher in gewissen Situationen den WDT() für >2.5 Sekunden nicht mehr zu Zug kommen lässt, wenn die WDT()-Prio tiefer ist. => Restart Nun wurde bei uns im Geschäft eine Diskussion entfacht, über die Frage, welche Priorität der WatchdogTriggerTask haben soll. Es gibt da unterschiedliche Ansichten: ______________________________________________________ Der WDT() soll die höchste Priorität haben: => Kein Reset solange der Task-Scheduler überhaupt noch läuft. => Keine Kontrolle ob alle Tasks genügend Rechnleistung abkriegen, bzw. ob niedrig priorisierte Task längere Zeit blockiert werden. Der WDT() soll die gleiche Priorität haben, wie der Task mit der niedrigsten Priorität (ausgenommen IdleTask) => Kein Reset, solange auch Tasks mit niedriger Prio regelmässig Rechenzeit abkriegen. => Risiko, dass auch Task mit tiefer Prio bei Überlast den WDT() zu lange blockieren und ein SW-Restart auftritt. Der WDT() soll die niedrigste Priorität haben (ausgenommen IdleTask) => kein Reset, solange auch noch regelässig IdleTime verfügbar ist. => Risiko, dass auch Task mit tiefer Prio bei Überlast den WDT() zu lange blockieren und ein SW-Restart auftritt. Weitere Möglichkeiten...??? ______________________________________________________ Ich bin einfach an verschieden Meinungen und Ansichten interessiert, bzw. möchte wissen, wie ihr dies bei euch so macht. Oder wäre es sogar sinnvoll, die WDT() Priorität für Test und Messungen anders zu wählen, als für die SW die an den Kunden geliefert wird? Bin gespannt auf eure Ansichten. Andy
Andreas wrote: > Der WDT() soll die höchste Priorität haben: > => Kein Reset solange der Task-Scheduler überhaupt noch läuft. > => Keine Kontrolle ob alle Tasks genügend Rechnleistung abkriegen, > bzw. ob niedrig priorisierte Task längere Zeit blockiert werden. Das ist Quatsch. Dann schalte doch den Watchdog gleich aus, kommt auf selbe raus. Der Watchdogtask muß natürlich alle wichtigen Prozesse überwachen, ob sie in einem bestimmten Intervall ausgeführt werden. Dazu hat er entsprechende Timeout-Counter und wenn einer davon abgelaufen ist, bleibt er einfach stehen, bis der Watchdog zuschlägt. Damit kann man dann auch Prozesse überwachen, die z.B. nur alle 1h ausgeführt werden müssen. Er darf nicht die höchste Priorität haben, damit er nicht die eiligen Sachen verzögert. Er muß ne mittlere Priorität haben. Peter
in einem multitasking-system ist ein wdt total sinnlos. im grunde prüfst du nur, ob die task die den wdt antriggert, noch läuft.
Wenn deine Software "beim Kunden über Wochen zuverlässig laufen, ohne Ausfälle oder Restarts" dann bringt dein Watchdog gar nichts denn wenn er zuschlägt ist das Kind schon im Brunnen (deadlock). Dann hast du ja dein Ziel schon verfehlt. Ein Watchdog macht nur Sinn - wenn man erstens ein Sicherheitskritisches System am durchdrehen hindern will/muss (ist vorgeschrieben) - wenn man dem Benutzer das lästige drücken des Reset-Schalters ersparen will Wenn du ein zuverlässiges System brauchst hilft nur eins: Fehlerfreier Code
Danke für die bisherigen Inputs >Er darf nicht die höchste Priorität haben, damit er nicht die eiligen >Sachen verzögert. Der WDT braucht kaum CPU-Zeit, nebst dem RTOS Context-Switching werden bloss zwei drei uC-Register beschrieben. >Wenn du ein zuverlässiges System brauchst hilft nur eins: Fehlerfreier >Code Das wäre auch mein Wunsch, aber nicht ganz realistisch. Wenn Du ein Projekt dieser Grösse (C und C++ gemischt, seit 10 Jahren haben zahlreiche Firmen und Programmierer die ihren Input beigetragen haben) fehlerfrei hinkriegst, wirst Du sofort angestellt. ;o)) >-wenn man dem Benutzer das lästige drücken des Reset-Schalters ersparen >will Ja, das will man. Normalerweise ist kein "Operator" vor Ort, dann ist es immer noch besser das System bootet selbständig mit einem Funktions-Unterbruch von einigen 10 Sekunden
Also wir machen das hier so: 1. Unterscheidung Runtimeüberwachung <-> Watchdog: Die Runtimeüberwachung übernimmt der Scheduler, ist also quasi ein Softwarewatchdog. 2. Die Peripherie/Hardware, die dran hängt hat einen eigenen Hardwarewatchdog der beisst, wenn die CPU für "längere" Zeit nichts tut. Sinnvollerweise wird dieser Peripheriewatchdog in einem Task getriggert, der prüfen kann, ob die IOs noch bedient werden, also im einfachsten Fall er selbst. Mit einer höheren Priorität triggern hat meiner Meinung nach nur einen Sinn, wenn der höher priorisierte Task entsprechende Überprüfungen vornimmt, bevor er triggert.
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.