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... Programm .. einmal mit den Interrupts und einmal ohne Schnickschnack .. Programm .. so stark gebremst, dass es nur circa halb so schnell läuft ..
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.
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... Im Hintergrund läuft .. die Servo-Bibliothek, die mit den sechs Servos des Roboter Arms wohl recht beschäftigt ist ..
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).
Zitieren
Lesezeichen