Main loop mit Hardware PWM "synchronisieren" (atxmega32a4) - oder anderer Ansatz...?

[damfino]

Hi,
Ich steuere die Berechnungen/Tasks in der Main über einen Timer:
Im Timer wird festgelegt zu welcher Zeit welcher Taskflag gesetzt wird.
zB
if (tasktimer==TASKPID1) {taskflag=PID1_flag;}
if (tasktimer==TASKPID2) {taskflag=PID2_flag;}

in der Main gibt es dann folgende if Anweisungen:
if (taskflag== PID1_flag) {taskflag=taskflagclear;....
if (taskflag== PID2_flag) {taskflag=taskflagclear;....

Sensoren werden laufend in der Main loop abgefragt.

Wobei die PID Regler bei mir mittlerweile im Timer Interrupt laufen, aber zu genauen Zeiten und zeitlich versetzt wie gezeigt mit tasktimer geregelt, hat sich für die Drehzahlregelung als beste Lösung erwiesen. Und das bei nur 4 und 8hz...
Positionsberechnung oder Datentransfer über Bluetooth bleibt im Main.

Ich verwende das um einen zeitlich genauen Ablauf zu erhalten. Zuvor konnte es passieren dass zufällig mehrere lange Berechnungen gleichzeitig anfielen und dann langsamer/nicht auf die Sensoren reagiert wurde. Jetzt gibt es genaue Zeitfenster, die Laufzeit der einzelnen Berechnungen hatte ich zuvor im Simulator ermittelt, und so wurde das ganze System leistungsfähiger.

Vielleicht ist die Hardware PWM nicht sinnvoll und steuerst den Pin gleich über den PID Timer mit?

LG!

[Che Guevara]

Hi Willla,

den Mainloop würde ich nem Flag laufen lassen, welches in ner 500Hz Timer-Routine gesetzt und dann direkt im Mainloop wieder zurückgesetzt wird.
Deine zweite Aufgabe stelle ich mir nicht so easy vor, aber ne erste Idee hätte ich:
Die einzelnen Motorwerte der Größe nach sortieren und dann die Differenzen untereinander bestimmen, mit diesen Werten dann den Timer vorladen und in der Routine den entsprechenden Pin wieder auf Low setzen.
Müsste man mal probieren, wieviel Overhead das wirklich erzeugt, aber es gibt sicher noch bessere Lösungen

Gruß
Chris

[Klebwax]

@Willa

Ich würde da nichts synchronisieren sondern alles im Interrupt erledigen. Wenn ich dich richtig verstanden habe, werden deine PWM Signale mit 500 Hz (alle 2ms) in Hardware erzeugt. Da wird sich doch wohl ein Interrupt erzeugen lassen, entweder mit dem Überlauf des PWM-Timers oder mit einem der Matches. In diesem Interrupt wird alles erledigt, was mit der Motorsteuerung zu tun hat. Es ist damit immer synchron zu den Motoren. In deiner Main-Loop kannst du dann machen, was du willst. Das kann dann auch beliebig lange dauern.

Wobei die PID Regler bei mir mittlerweile im Timer Interrupt laufen, aber zu genauen Zeiten und zeitlich versetzt wie gezeigt mit tasktimer geregelt, hat sich für die Drehzahlregelung als beste Lösung erwiesen. Und das bei nur 4 und 8hz...
Positionsberechnung oder Datentransfer über Bluetooth bleibt im Main.

Ich verwende das um einen zeitlich genauen Ablauf zu erhalten. Zuvor konnte es passieren dass zufällig mehrere lange Berechnungen gleichzeitig anfielen und dann langsamer/nicht auf die Sensoren reagiert wurde. Jetzt gibt es genaue Zeitfenster, die Laufzeit der einzelnen Berechnungen hatte ich zuvor im Simulator ermittelt, und so wurde das ganze System leistungsfähiger.

Ich mach das nicht im Simulator, ich setze einen Pin für die Dauer des Interrupthandlers und messe mit Scope oder LA die Zeit. Da kann man dann auch ganz schnell sehen, was einzelne Operationen für Zeit kosten.

Alles, was nicht ganz so schnell aber trotzdem synchron sein muß, verteile ich auf mehrere Interrupte. Dazu zähle ich im Interrupt eine Variable hoch. Bei jedem Zählerstand wird eine bestimmte Funktion ausgeführt, sind alle durch, wird der Zähler auf Null gesetzt.

Bei einem solchen System kann es sein, daß mehr Zeit im Interrupthandler als in der Mainloop verbracht wird. Das ist auch OK, dort wird ja auch die meiste Arbeit geleistet. Insgesamt braucht man in einem solchen System nur einen Timer, der wird bei dir durch die HW-PWM schon da sein, und einen Interrupthandler. Das macht alles recht übersichtlich, konkurierende Interrupte kommen nicht vor. Man muß in der Mainloop auch nicht aufpassen, daß man irgendein gesetztes Flag verpasst, weil man mal zu langsam ist.

MfG Klebwax

[Besserwessi]

So schlimm ist das mit dem Synchronisieren der Main loop mit dem Interrupt nicht. Man warte halt in der Main loop einmal auf das Flag und löscht es dann gleich wider - da muss schon viel dazwischen kommen (mehr als doppelte Laufzeit für die Schleife) dass man da was verpasst. Wenn man mal etwas länger braucht wird das auch wieder aufgeholt - bei Interrupts bekommt man da schon eher Probleme, weil ggf. der 2. Interrupt ausgeführt wird bevor der 1. fertig ist. Den Nachteil den man mit viel Code in der ISR hat, ist dass man dann mit anderen ISRs eingeschränkt ist. Man kann zwar im Prinzip geschachtelte Interrupts zulassen, aber bei Bascom verbraucht das recht viel Speicher (RAM).

Einen einmaligen Puls mit definierter Länge erzeugt man am besten per PWM Signal - nach dem Puls kann dann im Interrupt das PWM Signal wieder deaktiviert werden. Zumindest mit einem 16 Bit timer hat man da relativ viel Zeit für.

[Klebwax]

So schlimm ist das mit dem Synchronisieren der Main loop mit dem Interrupt nicht. Man warte halt in der Main loop einmal auf das Flag und löscht es dann gleich wider - da muss schon viel dazwischen kommen (mehr als doppelte Laufzeit für die Schleife) dass man da was verpasst. Wenn man mal etwas länger braucht wird das auch wieder aufgeholt

Das gilt natürlich genauso für die ISR. Nur wartet die nicht auf das Flag, das Interrupt-Flag startet sie direkt.

- bei Interrupts bekommt man da schon eher Probleme, weil ggf. der 2. Interrupt ausgeführt wird bevor der 1. fertig ist

Solange man geschachtelte Interrupts nicht zuläßt, wird das nicht passieren.

Die Restriktion, daß die Berechnung der Regelung (im Mittel) schneller sein muß, als der Regler tickt, gilt immer. Sonst ist der Prozessor zu langsam.

Den Nachteil den man mit viel Code in der ISR hat, ist dass man dann mit anderen ISRs eingeschränkt ist.

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.

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

[Besserwessi]

Eine ISR nur zum setzen einen Flags ist überflüssig - das ist schon mal richtig. Mit der Synchronisation der Hauptschleife hat man worst case schon mehr als 2 ms Zeit - man hat in Prinzip bis zu 2 ms Zeit, um die man mit der Ausführung auch mal hinterher hinken kann. Das darf nicht aber natürlich nicht aufsummieren, und die Regelung kommt dann ggf. auch eine Periode zu spät. Bei der ISR Lösung mit verschachtelten Interrupts wird es bereits nach einmal mehr als 2 ms kritisch.

Den ganzen Code der in der Hauptschleife rund 1ms braucht allerdings in eine ISR zu schieben ist keine so gute Idee, vor allem wenn man nicht erlaubt den Interrupt noch unterbrachen zu lassen. Die Antwortzeit für andere Interrupts leidet dann doch schon erheblich und macht die fast unbrauchbar.

Wenn es geht würde ich auch eher die Regelung und alles das Synchron mit dem PWM Signal laufen muss in ISRs legen. Normal sollte das auch nicht so lange dauern, wenn man es effektiv programmiert. Die Hauptschleife muss dann ggf. nicht mehr auf das PWM Signal warten und kann langsame Dinge machen. Eine Display-ausgabe wird man im Flug eher nicht brauchen.

Wenn es zeitkritisch wird, hätte man ggf. noch die Möglichkeit von Bascom auf GCC umzusteigen - das wird oft einiges schneller.

[Klebwax]

Wenn es geht würde ich auch eher die Regelung und alles das Synchron mit dem PWM Signal laufen muss in ISRs legen. Normal sollte das auch nicht so lange dauern, wenn man es effektiv programmiert. Die Hauptschleife muss dann ggf. nicht mehr auf das PWM Signal warten und kann langsame Dinge machen. Eine Display-ausgabe wird man im Flug eher nicht brauchen.

Ich denke es geht darum, sich einen Freiraum zu schaffen. Alles zeitkritische in die ISR, und man hat volle Freiheit in der Mainloop. Wenn die ISR erstmal fertig debugged ist, hat man ein stabiles System und kann experimentieren.

Ein Display könnte auch an Bluetooth oder WLAN hängen, und das braucht nicht schneller zu sein, als ein Mensch es ablesen kann (egal, wie schnell der Regler läuft).

MfG Klebwax