Doch das war damit gemeint. Ich hatte es so verstanden das Dir die Zeiten zu lang sind. Ich wollte nur erwähnt wissen das es an der Software liegt das die so lang sind und nicht an der Hardware.
Druckbare Version
Doch das war damit gemeint. Ich hatte es so verstanden das Dir die Zeiten zu lang sind. Ich wollte nur erwähnt wissen das es an der Software liegt das die so lang sind und nicht an der Hardware.
Zur Info: Das betrifft bei Teensy 3.x ja nur die vier PIT-Timer des Kinetis Controllers. Die werden von Teensyduino für das Auftrufen von Callbackfunktionen verwendet. Diese vier sind funktional identisch, daher austauschbar. So ähnlich ist das auch für die DMA-Kanäle realisiert.
Ansonsten ist dort z.B. der Systick-Timer ausschliesslich für millis() zuständig, wenn benötigt z.B. die FTM-Timer für PWM, PDB für Servo, usw. sonst sind die frei.
Das geht dann natürlich wenn man nur Timer gleicher Art als Gruppe anspricht. Ich hätte es ein bisschen anders gemacht aber wie die Wege nach Rom gibt es auch hier viele.
Ich habe jetzt mal die DueTimer installiert und das funktioniert recht gut. Da der Due so viele Timer hat könnte ich auch alle Funktionen die ich brauche von verschiedenen Timern einfach starten lassen. Dann können einzelne Vorgänge sich nicht gegenseitig blockieren. So richtig gefallen tut mir die Lösung nicht. Der DueScheduler ist halt ein Kooperativer der hängt auch wenn eine Funktion klemmt. Deshalb habe ich mal überlegt einen präemptiven Scheduler zu bauen. Mit dem Timer Interrupt bekomme ich ja wieder die Kontrolle über den Programmablauf. Was mir jetzt nur nicht ganz klar ist wie bekommt man am einfachsten die Rücksprungadresse von der unterbrochenen Funktion. Die muss ich ja mit den Funktionen in einer Tabelle speichern um nach Ablauf der Zeit zu einer anderen unterbrochenen wieder zurück zu springen.
Hallo,
eventuell wäre mal ein Blick ins Buch
"Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors"
für dich hilfreich. Da steht zumindest über die Sachen, die die Cortex-M alle gemeinsam haben, ziemlich viel drin.
Außerdem möchte ich noch auf einen anderen Ansatz als Scheduler oder Timer hinweisen. Wieder zuerst ein Buchhinweis
"Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems"
und ein paar Links
http://playground.arduino.cc/Code/QP
https://en.wikipedia.org/wiki/QP_(framework)
https://www.state-machine.com/
(Ja, ich habe das Buch. Nein, ich arbeite nicht regelmässig mit dem Framework. Allerdings sind meine Programme sicher etwas vom Buch inspiriert.)
Wenn ich das aber richtig gelesen habe unterstützen die bei QP den SAM3X8E auch nicht direkt.
Die Bücher kenne ich zwar (vom Namen) habe die aber nicht. Danke für die Links die habe ich mal angeschaut aber wenn ich das dann erst für die CPU portieren muss wird das auch nicht einfacher.
Man kann die Timer auch als Event verstehen dann ist man davon nicht so weit entfernt. Wenn die aber keine Instanz haben die den Programmfluss unterbrechen und an anderer stelle fortsetzen kann (Task wechsel) sind die genaus weit wie die kooperativen Scheduler. Hängt eine Event Behandlung steht das ganze System das ist extrem Fehleranfällig und auch lästig.
QP gibt es in verschiedenen Ausprägungen. Ein Teil davon muss nicht irgendeine Hardware direkt unterstützen. Die Beispiele im Buch bauen bewusst auf DOS auf, wo es weder Multitasking noch Timer gibt. Beides ist bei QP nur optional.
Das Buch gibt es mittlerweile hier als PDF umsonst, die Lektüre würde ich ganz allgemein zum Thema empfehlen.
https://www.state-machine.com/psicc2/
Die einzige sinnvolle Methode IMO wäre, pthread in abgespeckter Form auf Arduino zu portieren, das ist ja plattformunabhängig.
Oder man wechselt zu Java (*würg*) , da ist preemptives MT ja immerhin mit drin, und die JIT compiler (wenn für Arduino/ARM verfügbar) sind wirklich fast genau so schnell wie C executables.
- - - Aktualisiert - - -
ps,
nicht probiert zwar, aber als Links bei mir archiviert:
preempt. MT für Arduino Due, Zero:
http://forum.arduino.cc/index.php?topic=318084.0
http://francois.pessaux.perso.sfr.fr/arduino.html#Babix edit: expired
Hier noch ein paar tiefere Links, vielleicht hilfts
https://www.state-machine.com/qpcpp/arm-cm.html
https://www.state-machine.com/qpcpp/arm-cm_qk.html
https://www.state-machine.com/qpcpp/arm-cm_qxk.html