Jetzt mal eine ganz ernsthafte Frage. Wozu soll denn so ein Overhead bei den Winzig-Programmen, die normal in der Arduino-IDE verfasst werden, gut sein?
Was versuchst Du denn da, mit tausend Blinkern?
MfG
Jetzt mal eine ganz ernsthafte Frage. Wozu soll denn so ein Overhead bei den Winzig-Programmen, die normal in der Arduino-IDE verfasst werden, gut sein?
Was versuchst Du denn da, mit tausend Blinkern?
MfG
ein Test-Setup zum Simulieren von preemptivem Multithreading mit plötzlich hängenden Einzel-Threads.
Bisher hat der Scheduler nicht preemptiv gearbeitet, weil bei nicht angepassten prios der RTOS watchdog blockiert und resetted wird, dadurch kommt es zum Programmabsturz und Neustart.
Jetzt können die Threads, wenn einer von ihnen blockiert, ungestört weiterlaufen, unter Beobachtung und mit Notfall-Maßnahmen.
Beispiel:
Autonomer Robot, fährt momentan geradeaus. Plötzlich blockiert der Thread, der die i2c-Distanzsensoren ausgelesen hat (oder irgendein anderer wichtiger Kontroll- oder Mess-Thread).
Folge: Robot fährt weiter und crasht, weil der Fehler nicht rechtzeitig erkannt wird.
Jetzt kann per Timestamp-Watcher jeder Thread kontrolliert werden, und wenn einer hängt, kann das System geregelt zum Stoppen gebracht werden, evtl. sogar autonome Reparaturversuche - vorher ging noch nicht mal mehr eine Kontrolle.
Wir hatten dieses Problem auch schon für die Raspi-Plattform in C mit pthread diskutiert.
Ich habe schon eine grafische, kooperative Multitasking-Oberfläche in der Vergangenheit in Assembler umgesetzt. Für PC. Daher kenne ich die Probleme.
Die Idee, die Du ansprichst ist daher nicht neu, sondern tauchte damals auch auf. Ich habe dann genau so etwas umgesetzt. Nämlich eine Kontrolle der Bibliotheken im Speicher mit Reparaturfunktion, indem Bibliotheken, deren Prüfsumme nicht mehr stimmte, nachgeladen wurden. Das Ende der Sache war mehr Overhead (also verlorene Rechenleistung) und der Nutzen dummerweise = Null. Das resultierte daraus, dass die Idee zwar gut, aber es nie zu diesen angenommenen Ausnahmen kam. Wenn, dann waren es Einzelfälle, wo ein Programmier- oder Denkfehler zugrunde lag. Ähnlich war es mit der implementierten Stapelüberwachung. Das brachte zumindest was, weil sich bei manchen Programmen nicht gut abschätzen lies, wieviel Stapelspeicher tatsächlich benötigt wird. Nach ein wenig Erfahrung hatte sich dieses Thema aber auch wieder erledigt. So war diese Funktion auch nur während der Entwicklungsphase von Applikationen gut, damit zumindest zwischendurch nicht dauernd das gesamte System hängen blieb.
Fehler beheben ist bsesser, als sich auf solche Funktionen zu verlassen, die dann die Rechenleistung stehlen.
MfG
natürlich ist die Idee nicht neu, ich habe preemptives MT sogar schon seit fast 20 Jahren bei Lego RCX, NXT und EV3 benutzt.
Aber bei Arduinos gibt es üblicherweise weder pthread noch std::thread - alles andere ist entweder Murks oder man muss freeRTOS selber implementieren, konfigurieren und compilieren, was extrem kompliziert ist.
Für ESP32 aber ist jetzt std::thread auch in der Arduino IDE verfügbar, und jetzt funktioniert es ja auch!
Berechtigungen
Zitieren
Lesezeichen