Verschiedene Taktraten im Atmega?

[Don Simon]

.. Codebeispiel (wie es bei mir auf praktisch allen Controllern läuft) ..

Nun hab ich ein ähnliches Programm erstellt, einmal mit den Interrupts und einmal ohne Schnickschnack.

Ergebnis: Das Programm wird doch tatsächlich so stark gebremst, dass es nur circa halb so schnell läuft! Erstaunlich!
Ohne die Hintergrund-Routinen stimmen dann die "Wait"-Zeiten ziemlich gut.


--> Im Hintergrund läuft im normalen Programm die Servo-Bibliothek, die mit den sechs Servos des Roboter Arms wohl recht beschäftigt ist.

.. Hinterher allenfalls ärgern, nicht heulen. (hmmm - hoffentlich musste nicht auf mich schimpfen . . .) ..

Alles gut

Vielen Dank für eure Hilfe.
Offtopic: Wo passen denn zukünftige Beiträge rein, die den Roboterarm betreffen? Es gibt viele Unterforen zu "Asuro" usw., allerdings finde ich hierfür nichts.

[Ceos]

Die Servo Lib benutzt meines Wissens nach Software PWM, schaltet die Pins also "manuell" an und aus

Du könntest dich evtl. mal mit den Timern für Atmegas beschäftigen, die haben i.d.R. mind 2 Timer mit jeweils 2 PWM Ausgängen, die deine Servos, ohne auch nur ein einziges Stück Code (ausgenommen Initialisierung und bei Änderung der Position), ansteuern können.

Der Timer zählt dabei einfach nur hoch und wenn der Timer dabei den WErt des Compare REgister des Ausgangs erreicht schaltet er den zugehörigen Pin an oder aus, je nachdem wie der Timer und die PWM konfigurtiert ist.

Du musst dann praktisch nur das Compare Register mit 2-3 Prozessorzyklen ändern um den Servo passend zu verstellen (ausgenommen die Berechnung deiner Zielposition)

PS leider ist das Pin Mapping limitiert und du musst vermutlich einige Pins umplanen und die Progammierung wird dann auch schwer in Richtung "Bare Metal" kippen, also andere Librarys verwenden wird dann evtl. Probleamtischer ... oder du findest heraus mit welcher anderen SErvo Lib oder wie du mit der bestehenden Servo Lib die Hardware PWM nutzen kannt um das Problem zu minimieren.

[oberallgeier]

.. Programm .. einmal mit den Interrupts und einmal ohne Schnickschnack .. Programm .. so stark gebremst, dass es nur circa halb so schnell läuft ..

Na ja, pingelig gesagt läuft "das Programm" immer gleichschnell, nur wird der Ablauf durch die Interruptroutinen zu einem guten Teil belegt, der Rest muss sich mit der von den Interruptroutinen übrig gelassenen Zeit begnügen. Und daher ist - sorry dass ich das so ausdrücke - Deine Interpretation, dass Dein Programm ".. nur circa halb so schnell läuft.. " falsch. Ohne Interrupt läuft Dein Programm sozusagen alleine, hat alle Zeit NUR für sich - und sieht daher schnelllaufend aus. Mi[ISRläuft]t Inte[ISRläuft]rrupt b[ISRläuft]leibt [ISRläuft]halt ni[ISRläuft]cht me[ISRläuft]hr all[ISRläuft]e Zei[ISRläuft]t für d[ISRläuft]en Re[ISRläuft]st ü[ISRläuft]rig. Anmerkung: die Interruptserviceroutinen sind üblicherweise nie gleich lang! Die Länge kann aus der "meinfile.lls"-Datei abgeleitet werden.

Hauptsatz: der Controller kann vom üblichen Programmablauf nur jeweils einen Schritt abarbeiten, nie zwei Schritte gleichzeitig. Ausnahmen bilden hardwareimplantierte Dinge wie einige Zähler, Timer etc.

.. Im Hintergrund läuft .. die Servo-Bibliothek, die mit den sechs Servos des Roboter Arms wohl recht beschäftigt ist ..

Ach ja, soo schlimm ist es nicht - aber ich kenne leider Deine Bibliothek nicht. Ich habe bei den Armen (und im Kopf) von meinem archie jeweils einen Kontroller der maximal zehn Servos bedient. Zu diesen - interruptgetriebenen Servoroutinen - kommen noch andere Dienste. Mit Interrupt z.B. Boardtimer, UART, I²C und solcher Spass. Beim Motorcontroller ists ähnlich, aber ohne Servoroutinen, dort läuft durch ein Flag (von einem Timer-Interrupt gesetzt) im "normalen" Programmablauf z.B. die Regelroutine für die beiden Motoren. Das wird alles einigermassen gut verschachtelt.

Verschachtelt? Beispiel Servos. Meine analogen wollen ja alle 20 ms einen Puls von beliebiger Länge 0,5 bis 2 ms. Also läuft der "Servotimer" - nennen wir ihn ST0 so, dass alle 2 (!!!) ms EIN einziger Servo mit der ID "Servopointer" eingeschaltet wird <=> Puls wird high gesetzt, dazu ein Timer ST1, der die Länge des Pulses begrenzt. Wenn ST1 abgelaufen ist, schaltet der den Puls ab UND setzt den Servopointer eins rauf. Wenn der Servopointer auf 11 ist, wird er auf 1 gesetzt. Nach dem Ablauf der 2 (!!!) ms von ST0 wird also der nächste Servo . . . usw. Diese 2 ms sind bei meinen 20Mhz-getakteten Controllern eine kleine Ewigkeit, da kann man vielerlei andere Ding zwischendurch erledigen. Und nach dem zehnten Servo sind 20 ms vorbei und der erste kommt wieder dran.

Du siehst oben, dass Deine Interruptserviceroutinen dem Ablauf z.B. Deiner waitms-Schleife etliche Zeit wegnehmen, dadurch kann die nicht glatt, ungestört, durchlaufen. Übrigens sind diese waitms- oder delayxx-Routinen böse Bremsen, weil die ausser interruptgetriebenen Abläufen keine weiteren Aktionen zulassen. Daher erledige ich so etwas üblicherweise mit einem Flag, das im Boardtimer gesetzt wird. Dieser Boardtimer ist bei mir eine Interruptroutine, die alle 50 µs die boardinterne Zeit eins höher setzt. Also kann ich z.B. nen tmrxy1 machen, der in der ISR fallweise runtergetickert wird.

Fallweise? Klar, dort heißt es dann
....if ( tmrxy1 ) tmrxy1 --; // einfach tickern bis Null; Allzwecktimer s. ~com~
und bedeutet dass, solagen tmrxy1 ungleich null (bedeutet true ! *gg*) ist, wird er runtergezählt. Und ich kann ihn in der Zwischenzeit auf Null prüfen und ne Aktion machen sobald er wieder auf Null ist. Manche Abläufe laufen ähnlich, aber mit hochgetickerten Timer.

Ende, viel zu viel - TL;DR. Aber vielleicht wird Dir damit der Programmablauf im Controller klar(er).

[Don Simon]

Die Servo Lib benutzt meines Wissens nach Software PWM, schaltet die Pins also "manuell" an und aus ..

Davon gehe ich auch aus.

.. Du könntest dich evtl. mal mit den Timern für Atmegas beschäftigen ..

Hatte noch nicht die Zeit, die Servo-Bibliothek mit eigener Timer-Interrupt Steuerung zu ersetzen, hab das aber noch vor, da mir die Lib. sowieso zu ungenau unterteilt.

.. PS leider ist das Pin Mapping limitiert und du musst vermutlich einige Pins umplanen ..

Das hatte ich schon befürchtet.

Na ja, pingelig gesagt läuft "das Programm" immer gleichschnell ..

Klar, das "gesamte" Programm.

.. Deine Interpretation, dass Dein Programm ".. nur circa halb so schnell läuft.. " [ist] falsch.

Ja. Ich denke, wir können uns darauf einigen, dass durch die Unterbrechungen der ISR die Befehle in der Hauptschleife (bzw. "Main") weniger oft ausgeführt werden (können).

.. Die Länge [der ISR] kann aus der "meinfile.lls"-Datei abgeleitet werden. ..

Das wusste ich nicht. Wo finde ich die Datei?

.. der Controller kann vom üblichen Programmablauf nur jeweils einen Schritt abarbeiten ..

Klar, Multithreading muss mit nur einem Prozessorkern hintereinander ablaufen.

.. einen Kontroller der maximal zehn Servos bedient ..

Sollte auch kein Problem darstellen, wenn man bedenkt, dass die ISR hier nur jeweils einen Pin setzt oder rücksetzt. Es sollten sogar mehr als zehn Servos möglich sein, da die 50 Hz normalerweise nicht so kritisch sind.

.. "Servotimer" - nennen wir ihn ST0 [...] dazu ein Timer ST1, der die Länge des Pulses begrenzt. ..

Es sollte auch möglich sein, beides mit einem Timer abzuarbeiten, also Pulse und Pausen - ich hab mir das für meine zukünftige Ansteuerung überlegt. Das System ist ansonsten gleich:
Puls1, Pause1 (ausrechnen), Puls2, Pause2 (ausrechnen),... die Pause muss so berechnet werden, dass (Puls+Pause)*6=20 ms ergibt, da ich momentan maximal sechs Servos verwende.

Man könnte die Restzeit alternativ auch hinten dran hängen, dann sollte Puls+Pause jeweils 2 ms lang sein, wobei - wie schon angemerkt - die angestrebte Frequenz nicht so wichtig ist.
Interessant wäre daher auch noch folgender Versuch (ebenfalls mit einem Timer):
Puls1, Puls2, ...Puls6, 11 ms Pause.
Nach meiner Rechnung schwankt die Frequenz dann zwischen 43,5 und 58,8 Hz. Ich denke, das sollte noch problemlos funktionieren. Hat sowas schon einmal jemand versucht?

.. Übrigens sind diese waitms- oder delayxx-Routinen böse Bremsen ..

Das ist richtig. Die Routinen nutze ich normalerweise nur für unwichtige Sachen in der Hauptschleife. Für zeitkritische Anwendungen nutze ich auch gerne Timer, die Variablen hochzählen, um genauso eine Art Boardtimer zu erhalten, mit dem man wiederum durch Flags Teile im Hauptprogramm starten kann, um die ISR möglichst kurz zu halten.


Nebenbei, Archie sieht nach einem sehr interessanten Projekt aus!