Arduino Due: FreeRTOS installieren und mit Platformio übersetzen

[Mxt]

Ja ich habe auch schon bemerkt, dass HaWe die Arduino Integration von FreeRTOS meint.

Platformio ist aber umfangreicher, es kann mit Arduino, mbed, TI Energia usw. umgehen. In gewissen Sinne bündelt es nur einige Python Alternativen zu CMake und Co. Insoweit macht es vom Code her wohl keinen großen Unterschied, ob man mit oder ohne Platformio arbeitet.

Was mbed angeht, würde das einen Hardwarewechsel erfordern. Atmel ist da zwar Mitglied, es werden aber nicht viele Atmel Controller unterstützt. Es gäbe aber z.B. hinreichend viele günstige STM32 Boards, die mehr Pins und mehr Leistung als ein Due haben.
https://os.mbed.com/platforms/
Übrigens kommt da bald ein Board hinzu, das auch den Prozessor hat, den wohl der Teensy 4 bekommt (Cortex M7 bis zu 600 MHz).

Cortex-M auf den Mikrocontrollern aber doch noch eine etwas andere Baustelle als Cortex-A auf Raspi usw.

Ansonsten hat HaWe schon den Nerv getroffen, bei dem Zitat zu den einzelnen SAMD Typen. Die ganzen Prozessorregister, Timer usw. sind sehr unterschiedlich bei den einzelnen Controllern, auch beim gleichen Hersteller. Die werden aber gebraucht für millis(), PWM, Servo usw. Ich bin schon ma froh, das ich mittlerweile halb überblicke wie das bei Teensy im Vergleich zum ATmega aussieht. Beim Experimentieren mit dem Teensy habe ich jedenfalls auch einiges über AVR gelernt, und auch darüber warum das beim Due schlechter läuft. Aber das führt jetzt zu weit ...

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