Arduino Due: FreeRTOS installieren und mit Platformio übersetzen

[alexander_ro]

Das mag ja sein das die Register nicht so gleich sind. Aber wenn ich recht sehe unterstützt der ja so nur die Arduino Sachen. Die haben aber jetzt nicht unendlich viele der ARM Controller verbaut. Sollte also einigermaßen übersichtlich bleiben. Wenn die bei dem Arduino Projekt schon einen eigenen Due Scheduler bauen warum man dann nicht den für diesen Zweck vorhandenen Systemtimer benutzt. Der Due hat nun wirklich genug Timer das man da einen benutzen kann um das System Fehlertoleranter zu machen.

Wenn man die Atmel IDE Nutzt kann man das FreeRTOS auch für den SAM3X8E bekommen. Das soll da integriert sein. Aber leider läuft das wieder nur mit dem Dummen Windows ...
Müsste ich erst mal irgendwo installieren. Meine Begeisterung das zu tun ist sehr begrenzt.

Ich nix wissen ich anderes Baustelle ... ... hast ja recht aber ich dachte es ist ARM im allgemeinen gemeint und nicht nur die Cortex-M3.

Mit dem Überblick bist Du schon weiter als ich der fehlt mir noch. Irgendwie fehlt für die Controller so was wie der Linux Kernel bei dem die Entwickler auch viel für den Hardware Support machen.

[Mxt]

Der Due hat nun wirklich genug Timer

Timer für den Due ist auch so ein Thema. Welche Timer die Arduino IDE beim Due wofür benutzt, scheint nirgendwo außer im Quelltext zu stehen.

Einige Dinge wie die tone() Funktion hat man beim Due gleich weggelassen. Andere Libraries benutzen einen festen Timer, obwohl auch andere möglich wären. Wenn dann eine zweite Lib kommt, die den gleichen Timer nehmen will, gibt es Ärger. Das ist beim Teensy besser gelöst, durch die IntervalTimer Lib, der man sagt "gib mir den nächsten freien Timer".
https://www.pjrc.com/teensy/td_timin...rvalTimer.html

Eine Tabelle welcher Timer welchen PWM-Pin steuert, so wie hier (weiter unten unter PWM Frequency)
https://www.pjrc.com/teensy/td_pulse.html
habe ich für den Due auch noch nicht gesehen.

[HaWe]

Timer für den Due ist auch so ein Thema. Welche Timer die Arduino IDE beim Due wofür benutzt, scheint nirgendwo außer im Quelltext zu stehen.

Einige Dinge wie die tone() Funktion hat man beim Due gleich weggelassen. Andere Libraries benutzen einen festen Timer, obwohl auch andere möglich wären. Wenn dann eine zweite Lib kommt, die den gleichen Timer nehmen will, gibt es Ärger. Das ist beim Teensy besser gelöst, durch die IntervalTimer Lib, der man sagt "gib mir den nächsten freien Timer".
https://www.pjrc.com/teensy/td_timin...rvalTimer.html

Eine Tabelle welcher Timer welchen PWM-Pin steuert, so wie hier (weiter unten unter PWM Frequency)
https://www.pjrc.com/teensy/td_pulse.html
habe ich für den Due auch noch nicht gesehen.

das mit dem nächsten freien Timer geht aber immerhin mit der Lib DueTimer.
static DueTimer getAvailable(void);
https://github.com/ivanseidel/DueTim...ter/DueTimer.h

Die Lib verwende ich oft und gern zusammen mit dem Due Scheduler, z.B. für schnelle Timer Interrupts zum Encoder-auslesen (<=200µs, je nach Bedarf)
Ich weiß nicht, wie lang eine time slice beim Scheduler ist, aber beim FreeRTOS sind es ja wohl 15ms (IIRC), also dann viel zu lang.

(OT: Beim Raspi funktionieren mit pthread time slices von 200ns (!), nur der kernel verlängert sie manchmal im User space auf max. 800ns)

ps,
es gibt außer dem Due Scheduler von C. Maglie
https://github.com/arduino-libraries/Scheduler
auch eine neuere Scheduler Lib von M. Patel, die ist besser dokumentiert, funktioniert auf AVR und ARM (SAM, SAMD), ist allerdings etwas konfigurationsbedürftiger:
https://github.com/mikaelpatel/Arduino-Scheduler

[Mxt]

das geht aber immerhin mit der Lib DueTimer.

Ja in eigenen Programmen. Aber die kam erst, nachdem es den Due schon eine Weile gegeben hat. Mit dem Effekt das viele übliche Arduino Libs sie nicht benutzen, z.B. VirtualWire, SoftPWM, ShiftPWM, DMX usw., die Beispiele stehen ja in der Teensy Doku. Auch wenn man selber die DueTimer Lib verwendet, kann eine von denen sie abschiessen.

[HaWe]

stimmt, ist eben ziemlich vermurkst die Arduino API, insbesondere die hoch abstrahierten core libs, und ganz insbesondere die für den Due. Und thread-safe sind sie ebenfalls alle nicht!

[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)?

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