Zitat Zitat von Mxt Beitrag anzeigen
Im Prinzip ist es schon richtig, dass die Zeit in der Loop nur das ist "was übrig bleibt". Aber, wie HaWe schon sagte, ist das bei einem schnellen Controller sehr viel.
Nun, alle Embeded-Programme haben die "Mainloop". Wenn man aber das Timing fürs Tastenentprellen oder die Mikroschritte in die Mainloop zieht, sind brauchbare Systeme kaum möglich. Ich versuche mir gerade vorzustellen, wie ich einen G-Code Interpreter aufbaue, der immer kürzer als ein Mikroschritt des Steppers läuft. Ansonsten würde der Motor schon bei der Ansteuerung Schritte verlieren. Man kann natürlich immer einen schnelleren Prozessor nehmen muß sich aber fragen, warum es andere mit einem langsameren auch schaffen.

Die Arm sind schon mächtig, in einem Hoverboard steuert einer das Timing von 2 BLDC und das Balancieren, aber sicher nicht mit einem Arduino Framework.

Außerdem ist die Arbeit mit der loop nun mal der "Arduino Way" und die Programme bleiben portabel zu anderen Typen. Außerdem bekommt man bei loop Programmen besser ein Gefühl für die vorhandene Rechenleistung. Wenn man alles in Timer Interrupts packt, sieht man das nicht so gut.
Richtig, ein System, programmieren zu lernen und die Komplexität von Interrupten und Dingen wie DMA vor dem Anwender zu kapseln. Zum Üben, wie man etwas macht ohne die CPU mit delays zu blockieren mag das angehen.

Ich versuche meine Systeme so aufzubauen, daß die Mainloop möglichst leer ist. Eigentlich will ich da nur ein sleep() sehen. Der ganze Rest läuft in Interrupt Handlern. Nested Interrupts können einem dabei helfen, es geht häufig aber auch so. Bei alten 386 SBCs konnte man das direkt fühlen. Wenn der im DOS-Prompt stand, wurde die CPU richtig heiß, stand er im Linux-Prompt blieb sie kalt. Da war wohl ein sleep() in der Mainloop.

MfG Klebwax