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

[Willa]

Hallo,
ich bin momentan dabei meinen "Shrediquette" Multicopter Code etwas aufzuräumen. Ich möchte gerne meinen Main Loop mit der Hardware PWM synchronisieren. Ich erkläre mal wie mein Code momentan noch aufgebaut ist, und was ich daran ändern möchte:

• Im Moment habe ich einen main loop der frei läuft (mit ca. 800-900Hz). Dieser Loop fragt z.B. die Sensoren und die Fernsteuerung ab, macht ein paar PID Berechnungen und am Ende kommen immer neue Sollwerte für die Motoren heraus
• Im Hintergrund läuft die ganze Zeit das Hardware PWM mit 500 Hz. Dieses benutzt die letzten Werte aus dem Main Loop und sendet sie per PWM die Motoren. Die Motorregler (zugekauft) haben eine Firmware die einen High Puls zwischen 125 und 250 µs verarbeiten, das nennt sich "OneShot125")

Das ist natürlich nicht optimal... Am besten wäre wohl, wenn alles mit 500 Hz laufen würde: Die ganzen Berechnungen aus dem Main Loop werden ausgeführt, und sofort danach gehen die Pins für die Motorregler auf High und bleiben dort (je nach Sollwert) für 125 bis 250 µs. Am allerbesten wäre es natürlich wenn die Pins schon 125 µs vor dem Ende der Berechnungen auf High gehen.

Hat jemand von euch vielleicht eine Idee wie so etwas normalerweise realisiert wird...? Ich habe noch einen 16bit Timer über... Könnte ich den mit 500 Hz laufen lassen und damit die Berechnungen im Main Loop starten? Dann am Ende der Berechnungen das PWM "resetten" (geht das überhaupt?), welches dann den entsprechen Puls erzeugt...?

Ich würde mich über eure Anregungen und Denkanstöße freuen!

[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