Arduino Due: FreeRTOS installieren und mit Platformio übersetzen

[HaWe]

Nein ich will wie oben steht platformio benutzen. Da steht aber auch noch das ich mir nicht sicher bin ob man es nicht evtl. besser macht ohne die Tools. Sondern nur sich einen einfachen cross Compiler für diese CPU zusammenbaut und dann halt wie gewohnt mit Makefiles das Projekt baut. Ich bin mir auch nicht sicher ob man nicht mit den Sachen von Atmel besser kommt. Die scheinen die CPU sehr viel besser zu unterstützen als Arduino.
Atmel: http://asf.atmel.com/docs/latest/sea...l?device=sam3x

Ich glaub eher das der den Due halt als EOL sehen will weil er nicht den Aufwand betreiben will eine ARM CPU zu unterstützen. Es sind sicher einige der Due verkauft worden und die China Nachbauten wird man sicher auch noch lang bekommen als EOL sieht für mich anders aus. Ohne den Due gibt es halt bei den Arduino Platinchen nicht mehr viel das genug Rechnleistung und Speicher hat das man nicht nur das Problem lösen kann sondern auch noch Fehlertoleranz, Plausibilätsprüfungen und Diagnose einbauen kann.

Der Due Scheduler hat halt ein bisschen Nachteile wenn mal ein Task hängt. Dann tut der nichts mehr und es ist auch keine Kommunikation mehr mit dem Platinchen möglich. Was es ungemein schwer macht dem User Nachrichten über das Problem zu kommen zu lassen. Mir ist schon klar das heutige Systeme wegen notorischem Geiz bei der Industrie nur als Blackbox gebaut werden und es oberstes Ziel ist die User im dunkeln Tappen zu lassen. Ich würde es gerne besser machen.

nein, er will keine ARM Boards supporten wegen der Vielzahl verschiedener existierender System Interrupts für den RTOS Scheduler, alle ARMs haben ja wohl verschiedene eigene - anders als bei den AVRs, denn dort geht es einheitlich über identische Watchdog Routinen.
Wäre jetzt der Due das angesagte Nonplusultra, auf den sich alle stürzen, mitsamt der Arduino-Entwickler und aller freien Mitarbeiter und weltweit unter allen Arduino-Usern, sähe das sicher anders aus.

Das mit Platformino statt Arduino IDE allerdings hatte ich überlesen, sorry. Ich fühlte mich erinnert an meine Suche für die Arduino IDE, es war der Grund, warum ich zum Raspi gewechselt habe (feat. pthread, HID Tastatur/Maus, HDMI, Grafik, Video, Cam) und Arduinos (Due, Mega, Nano, ESP8266, SAMD-shields) höchstens nur noch als Huckepackboards für den Raspi per UART, USB oder I2C benutze.

[alexander_ro]

Ja die ARM Kerne unterscheiden sich schon stärker. Aber die Decken auch einen viel größeren Anwendungsbereich ab als die AVR. Die gehen ja vom Mikrocontroller bis zum Multiprozessor Server.

Der Raspberry ist aber auch ARM. Nur macht da halt der Hersteller die Kernel Anpassungen dafür. Die bei FreeRTOS tun das halt nicht so wie die Linux Macher. Aber wenn man wirklich Zeitkritisch Mechanik oder andere Abläufe steuern möchte ist das nur schwer mit einem Raspberry alleine zu machen. Zumal dem im Vergleich zum Due eine ganze Menge an Ports und AD-Wandler und so Zeug fehlt. Bei mir sollte der Due dann auch Daten über USB an einen PC oder Raspberry liefern. Weil zum Daten Sammeln und Auswerten ist der Due ja nun nicht so geeignet. Nur halt alles was mit dem zu Steuernden Ablauf zu tun hat soll der Due machen, überwachen und wenn es Fehler gibt sagen wo es liegt das Problem.

Vielleicht wäre ja der Due der Lieblings Controller von allen wenn er unterstützt würde ...

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

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