Arduino Due: FreeRTOS installieren und mit Platformio übersetzen

[alexander_ro]

Das mit der zu geringen Timer Auflösung ist aber nicht die Schuld des Due oder SAM3X8E sondern liegt an einer doofen Implementierung der Programme. Die Timerauflösung reicht um damit auf kurze Distanz die Laufzeit von Licht zu messen. Ich denke das sollte für alles das mit Alltagsphysik zu tun hat mehr als ausreichen. Für Atomphysiker mag das manchmal ein bisschen langsame sein. Für die gibt es aber dann auch noch Spezial Controller die noch mehr können.

Das man Hardware wie Timer in einer universellen Libraries nicht fest verdrahtet möchte man meinen das das heute jeder Programmierer gelernt hätte ist aber leider nicht so ...
Ob das zurückgeben irgendeines freien Timers gut ist bin ich mir auch nicht sicher. Weil die Controller oft Timer mit verschiedenen Fähigkeiten haben. Aber ist schon mal viel besser als fest verdrahtet. Es wäre aber ein leichtes bei der Initialisierung der Timer den gewünschten mit zu übergeben. Dann hat die Anwendung die Kontrolle darüber welche Hardware für was eingesetzt wird.

Ja irgendwie ist das alles nicht so Toll wie es einem die Fachpresse immer glaubend machen will. Ich dachte über die Jahre gäbe es da schon mal was das problemloses benutzen der Controller Hardware ermöglicht aber das scheint nicht so zu sein. Zumindest wenn man über das Fachpresse übliche blink Beispiel hinaus kommt.

Muss ich mir scheinbar doch wieder alles selber bauen was ich brauche ...

[HaWe]

Das mit der zu geringen Timer Auflösung ist aber nicht die Schuld des Due oder SAM3X8E sondern liegt an einer doofen Implementierung der Programme. Die Timerauflösung reicht um damit auf kurze Distanz die Laufzeit von Licht zu messen. Ich denke das sollte für alles das mit Alltagsphysik zu tun hat mehr als ausreichen. Für Atomphysiker mag das manchmal ein bisschen langsame sein. Für die gibt es aber dann auch noch Spezial Controller die noch mehr können.

Das man Hardware wie Timer in einer universellen Libraries nicht fest verdrahtet möchte man meinen das das heute jeder Programmierer gelernt hätte ist aber leider nicht so ...
Ob das zurückgeben irgendeines freien Timers gut ist bin ich mir auch nicht sicher. Weil die Controller oft Timer mit verschiedenen Fähigkeiten haben. Aber ist schon mal viel besser als fest verdrahtet. Es wäre aber ein leichtes bei der Initialisierung der Timer den gewünschten mit zu übergeben. Dann hat die Anwendung die Kontrolle darüber welche Hardware für was eingesetzt wird.

Ja irgendwie ist das alles nicht so Toll wie es einem die Fachpresse immer glaubend machen will. Ich dachte über die Jahre gäbe es da schon mal was das problemloses benutzen der Controller Hardware ermöglicht aber das scheint nicht so zu sein. Zumindest wenn man über das Fachpresse übliche blink Beispiel hinaus kommt.

Muss ich mir scheinbar doch wieder alles selber bauen was ich brauche ...

du beziehst dich jetzt aber mit "Timer-Auflösung" nicht auf meinen Post, der sich ja auf die recht langsame FreeRTOS-Timeslice-Auflösung bezieht (15ms, im Vergleich zu Timer Interrupts im µs oder ns-Bereich, oder sogar von pthread time slices auf dem Pi, ebenfalls im µs oder ns-Bereich)?

[alexander_ro]

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.

[HaWe]

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.

nein, ich meinte schon die langsame Implementierung der time slices über die FreeRTOS-Software. Selbst DueTimer sind ja schon irre schnell.

[alexander_ro]

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.

[alexander_ro]

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.

[Mxt]

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.)

[Mxt]

Ob das zurückgeben irgendeines freien Timers gut ist bin ich mir auch nicht sicher.

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.