Zitat Zitat von HaWe Beitrag anzeigen
der Nachteil von Timern ist, dass sie üblicherweise nicht multiple langdauernde, ununterbrochene Operationen zulassen. Selbst kooperatives MT funktioniert nicht mehr, wenn einzelne Threads plötzlich in einer langen Berechnung (exemplarisch: fibonacci(43) rekursiv) hängen oder blockieren.
Das verstehe ich nicht. Wenn ich einen Timer verwende, löst der einen Interrupt aus, der selbstverständlich das laufende Programm unterbricht.

Preemptives MT dagegen kann einfach die Zeitscheibe nach Sichern aller Variablen und Register etc unterbrechen und dann die nächste Zeitscheibe ...
Das wird von einem Timer und seinem Interrupt gesteuert. Wie sollte sonst der Scheduler auf die nächste Task umschalten können?

Die hardwarenahen Systeme, die ich so baue, haben alle entweder einen dediziert laufenden Timer mit Interrupt oder hängen an einem für die Hardware notwendigen Timer, z.B. dem PWM Timer eines Motors. Dazu kommen dann noch die Interrupte der übrigen Peripherie. Das gibt mir ausreichend Nebenläufigkeit, daß ich Threads und den dazu gehörenden Scheduler bisher nicht vermisst habe.

Auch würde mir ein preemptives System gar nicht passen. Wenn ich schnell reagieren muß z.B. einen PID Regler vor dem nächsten PWM-Takt fertigrechnen oder ein CRC bevor das Transmit Register leer ist, darf mir kein Scheduler dazwischen funken. Und sollte einer meiner Interrupthandler hängen, hat meine SW einen grundlegenden Bug. Dann wird mein PID Regler nie richtig funktionieren oder das CRC nie richtig berechnet werden.

Der Vergleich zwischen einem PI mit einem Multitasking System wie Linux/Unix (wo man in jeder Task natürlich auch noch mal lightweight Tasks aka Threads haben kann) und einem Teensy mit einerm Arduino Framework hinkt an allen Ecken und Kanten.

MfG Klebwax