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

**Klebwax** · 05.05.2015, 00:52

Zitat von Besserwessi

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

**Willa** · 07.05.2015, 00:10

Hi,
danke für eure zahlreichen Beiträge & Vorschläge! Da werde ich mich gleich mal durcharbeiten. Bei meiner Regelung ist das Hauptziel nicht die Synchronität, sondern der minimale Zeitversatz zwischen Sensoren auslesen / Rechnen / PWM ausgeben. Wobei das natürlich auch zusammenhängt. Ich versuche mich mal einfach heranzutasten das Ganze überhaupt richtig zu verstehen... Denn im Moment verstehe ich noch alles maximal halb. Ist folgendes richtig?

Mein PWM Timer ist so konfiguriert:

Code:

Config Tcd0 = Pwm , Prescale = 1 , Comparea = Enabled , Compareb = Enabled , Comparec = Enabled , Compared = Enabled , Event_source = Off , Event_action = Off , Event_delay = Disabled , Resolution = 16

Der µC läuft mit dem internen 32 MHz Takt.

TcD0_cnt ist der aktuelle Wert vom PWM Timer. Dieser läuft immer wieder von 0 auf 65535. Wenn TcD0_cnt den Wert null erreicht gehen alle PWM Pins auf High. Sobald TcD0_cnt einen bestimmten Wert erreicht (eingestellt per Tcd0_cca, Tcd0_ccb, Tcd0_ccc und Tcd0_ccd) geht der entsprechende Pin auf Low.

Ich muss die Berechnungen der Regelung starten kurz bevor TcD0_cnt sein Maximum erreicht. Angenommen die Berechnungen dauern 1 ms, dann muss ich die Berechnungen bei TcD0_cnt = 33535 starten. Wenn TcD0_cnt den Wert 65535 erreicht hat sind meine Berechnungen fertig (32000 Ticks bzw. 1 ms später). Bei TcD0_cnt = 65535 bzw. 0 gehen die PWM Pins hoch und bleiben dort bis die errechneten Werte (Tcd0_cca bis Tcd0_ccd sind immer zwischen 4000 und 8000 = 125 bis 250 µs) erreicht wurden.

Mir wurde immer gepredigt, dass man so wenig Code wie möglich im IRQ laufen lassen soll... Es gibt ja auch noch einen zweiten Interrupt vom RC Empfänger der sehr präzise sein muss. Für mich klingt es am einfachsten in der Main Loop den Wert von TcD0_cnt abzufragen und die Berechnungen zu starten sobald dieser größer als 33535 ist.
z.B. so:

Code:

if TcD0_cnt < 33535 then
   RechnenDarfGestartetWerden = 1
end if
if TcD0_cnt > 33535 AND RechnenDarfGestartetWerden = 1 then
   RechnenDarfGestartetWerden = 0
   RechneAllesAus
end if

Lasst mich raten: So geht es nicht. Wäre ja auch zu schön. Ich probiere es jetzt trotzdem aus und berichte was passiert.

- - - Aktualisiert - - -

Lasst mich raten: So geht es nicht. Wäre ja auch zu schön. Ich probiere es jetzt trotzdem aus und berichte was passiert.

Hmmm... Also ich habe das so mal eingebaut, und Schwuuupps, mein Code läuft mit genau 500 Hz. Ich habe kein Oszi hier, deswegen kann ich nicht gucken ob der Code wirklich das tut was er soll (außerdem weiß ich auch nicht wie lange meine Berechnungen denn wirklich brauchen). Aber ich denke mal rein theoretisch sollte das doch gehen... Ist dieser Ansatz programmiertechnisch sehr schlimm, oder kann ich das so machen?

- - - Aktualisiert - - -

Noch ein kurzer (evtl. schwachsinniger) Gedanke: Angenommen, ich verwende den Code so wie vorgeschlagen. Dann wäre es cool, wenn der Zeitpunkt zu dem die Berechnungen gestartet werden sich automatisch optimal einstellt. Ich kann mit einer groben Schätzung starten, und dann verschiebt sich der Start (z.B. um 0.1 ms) nach vorne falls eine Berechnung mal nicht fertig wurde. Ansonsten wird der Start Zeitpunkt immer ganz langsam nach hinten verschoben (z.B. jeden Durchgang um 0.001 ms). So pendelt der Startzeitpunkt um den optimalen Wert herum, egal was ich noch alles so an Berechnungen einbaue.

**Klebwax** · 07.05.2015, 01:32

Zitat von Willa

Hi,
danke für eure zahlreichen Beiträge & Vorschläge! Da werde ich mich gleich mal durcharbeiten. Bei meiner Regelung ist das Hauptziel nicht die Synchronität, sondern der minimale Zeitversatz zwischen Sensoren auslesen / Rechnen / PWM ausgeben.

Der minimale Zeitversatz ist erreicht, wenn die Berechnung synchron zur PWM ist. Ich spring jetzt mal

Dann wäre es cool, wenn der Zeitpunkt zu dem die Berechnungen gestartet werden sich automatisch optimal einstellt.

Der Zeitpunkt ist unerheblich, der Wert nachdem sich der Motor richtet, kann nur alle 2ms geändert werden. Feiner löst dein System nicht auf. Und wann du die Berechnung startest ist auch egal, sie muß nur zum nächsten 2ms Takt fertig sein.

Mir wurde immer gepredigt, dass man so wenig Code wie möglich im IRQ laufen lassen soll... Es gibt ja auch noch einen zweiten Interrupt vom RC Empfänger der sehr präzise sein muss. Für mich klingt es am einfachsten in der Main Loop den Wert von TcD0_cnt abzufragen und die Berechnungen zu starten sobald dieser größer als 33535 ist.

Mit Predigten ist das so eine Sache. Da wird versucht, einen komplexen Sachverhalt in einen möglichst kurzen Satz zu quetschen. Ich würd das mal so sagen: man sollte nicht mehr Code als nötig im Interrupthandler laufen lassen. Ich kenne Systeme und hab auch schon welche gebaut, die nur im Interrupthandler laufen. Auch das passt zu "nicht mehr als nötig", mehr war eben nicht nötig. Solche Systeme sind leichter deterministisch hinzubekommen und bewegen sich in Richtung Echtzeitsystem. Und ein Regler (z.B. Drehzahl, Geschwindigkeit, Lage etc) ist ein Echtzeitsystem.

Hmmm... Also ich habe das so mal eingebaut, und Schwuuupps, mein Code läuft mit genau 500 Hz. Ich habe kein Oszi hier, deswegen kann ich nicht gucken ob der Code wirklich das tut was er soll (außerdem weiß ich auch nicht wie lange meine Berechnungen denn wirklich brauchen). Aber ich denke mal rein theoretisch sollte das doch gehen... Ist dieser Ansatz programmiertechnisch sehr schlimm, oder kann ich das so machen?

Wenn es um Predigten geht, kann etwas "schlimm" sein. In der Technik gibt es nur unklug oder ungeschickt. Wenn man weiß, was man tut, kann man alles machen.

Dein Regler, deine Mainloop lief bisher mit 900Hz, wenn ich das recht in Erinnerung habe. Ihn auf 500Hz runterzubremsen ist leicht, wie du siehst. (Ich wechsel jetzt mal in die Zeitebene) Deine Rechnung dauert etwa 1ms, Ergebnisse werden alle 2ms benötigt, also alles im grünen Bereich. Machst du jetzt in der Mainloop etwas, das möglicherweise nichts mit dem Regler zu tun hat, aber länger als 1ms dauert, ist dein System geplatzt, und du verpasst die nächste PWM Phase.(@Besserwessi: einmal gehts noch gut)

Das sind meine Bedenken zu deinem Ansatz, ich hab oben schon einiges dazu gesagt. Aber laß dich von mir nicht irre machen, ein oder zwei mal hab ich auch schon Mist programmiert

.

MfG Klebwax

**Willa** · 07.05.2015, 14:47

Der minimale Zeitversatz ist erreicht, wenn die Berechnung synchron zur PWM ist. Ich spring jetzt mal. Der Zeitpunkt ist unerheblich, der Wert nachdem sich der Motor richtet, kann nur alle 2ms geändert werden. Feiner löst dein System nicht auf. Und wann du die Berechnung startest ist auch egal, sie muß nur zum nächsten 2ms Takt fertig sein.

Hi, danke für deine Antwort. Ich glaube wir reden bei der "Frage nach der Synchronität" aneinander vorbei - oder ich verstehe nicht richtig was du meinst. Es ist ja so: Mein Motortreiber stellt eine neue Motordrehzahl ein nachdem er erfasst hat wie lange der PWM Pin auf High war (125 bis 250 µs). Die aktuelle Drehgeschwindigkeit des Copters (erfasst mit einem Gyroskop) soll dabei so kurz wie möglich vor der Reaktion des Motortreibers gemessen werden. Bei vielen Regelungen ist ja nicht die Regelfrequenz an sich ein kritischer Faktor, sondern die Zeitspanne zwischen "Fehler messen" und "etwas gegen den Fehler unternehmen". So können Copter auch mit 50 Hz Regelfrequenz fliegen, aber nur zufriedenstellend wenn der Fehler direkt vor der Ausgabe des PWM High Pulses erfasst wird. Ansonsten ergibt sich eine zu große Verzögerung. Ich habe nun extra Motortreiber herausgesucht die nur einen sehr kurzen PWM High Puls brauchen. Denn je länger dieser Puls ist, desto älter sind die Sensorinformationen bevor darauf reagiert wird (denn der Motortreiber kann ja erst reagieren nachdem die komplette Länge des High Pulses vermessen wurde).

Machst du jetzt in der Mainloop etwas, das möglicherweise nichts mit dem Regler zu tun hat, aber länger als 1ms dauert, ist dein System geplatzt, und du verpasst die nächste PWM Phase.(@Besserwessi: einmal gehts noch gut)

Ja, das stimmt. Ich werde aber nichts machen. Ich würde es ja gerne auch mal nur im Interrupt probieren, weiß aber nicht so recht wie und wo ich so einen Interrupt erzeugen / auswerten / ansprechen kann.

**Klebwax** · 07.05.2015, 21:11

Zitat von Willa

[COLOR=#333333]Hi, danke für deine Antwort. Ich glaube wir reden bei der "Frage nach der Synchronität" aneinander vorbei - oder ich verstehe nicht richtig was du meinst.

Es ist auch möglich, daß ich dein System nicht richtig verstehe. Ich versuche mal, dein 50Hz Beispiel nachzuvollziehen:
alle 20ms wird die Drehzahl korrigiert. Der Servopuls fängt, sagen wir mal, bei ms 0 an, endet bei ms 2, dann ist bis ms 20 Ruhe. Du sagst, wichtig ist nur der Fehler bei ms 2 oder möglichst kurz davor. Der Fehler in der übrigen Zeit ist unerheblich?

Ich würde es ja gerne auch mal nur im Interrupt probieren, weiß aber nicht so recht wie und wo ich so einen Interrupt erzeugen / auswerten / ansprechen kann.

Ich bin davon ausgegangen, daß du deine Pulse mit HW, z.B. einem Timer erzeugst. Der kann doch sicher auch einen Interrupt erzeugen.

MfG Klebwax