Das gilt natürlich genauso für die ISR. Nur wartet die nicht auf das Flag, das Interrupt-Flag startet sie direkt.
Solange man geschachtelte Interrupts nicht zuläßt, wird das nicht passieren.- bei Interrupts bekommt man da schon eher Probleme, weil ggf. der 2. Interrupt ausgeführt wird bevor der 1. fertig ist
Die Restriktion, daß die Berechnung der Regelung (im Mittel) schneller sein muß, als der Regler tickt, gilt immer. Sonst ist der Prozessor zu langsam.
Das ist keine Einschränkung, die anderen ISRs müssen in Summe grundsätzlich so kurz sein, daß der Regler immer noch schnell genug ist, sonst s.o. Und sind sie das, ist in den Pausen zwischen dem Regler-Interrupt genug Zeit für sie. Wobei ich bevorzuge, wenn der Hauptinterrupt wie hier schnell (edit: hier gemeint häufig) läuft, die Interruptflags direkt aus dem ISR-Kontext abzufragen und die Abarbeitung gleich mit zu erledigen. Da hat man dann das Timing komplett unter Kontrolle und spart sich den Interrupthandler Overhead.Den Nachteil den man mit viel Code in der ISR hat, ist dass man dann mit anderen ISRs eingeschränkt ist.
Die Nachteile, in der Mainloop ein in der ISR gesetztes Flag zu pollen, überwiegen denk ich. Wenn man schon pollt, sollte man das Hardwareflagbit direkt pollen und sich die ganze ISR, die das Flag setzt, mit ihrem Overhead sparen. Der generelle Nachteil ist, daß ich beim Programmieren nicht nur die Regelung, sondern auch die Mainloop timen muß. Im Fall des TO darf sie auf keinen Fall länger als 2ms sein. Ein print, eine Displayausgabe oder ähnliches ist da nicht drin. Oder ich muß anfangen das nachzuprogrammieren, was mir die Interruptlösung umsonst liefert: das Aufteilen der Mainloop in kleine Stücken, zwischen denen ich immer wieder das Flag polle.
MfG Klebwax
Lesezeichen