Arduino Due: FreeRTOS installieren und mit Platformio übersetzen

Hallo Mädels ... Jungs ... :)

Ich versuche gerade FreeRTOS auf einem Arduino Due zum laufen zu bekommen. Bei mir Läuft die Entwicklungsumgebung auf einem Gentoo Linux. Bisher habe ich noch nie was mit FreeRTOS zu tun gehabt. Ich bin mir auch nicht sicher ob das Sinn macht dafür platformio zu benutzen oder ob man sich besser mit dem gcc selbst einen Cross Compiler baut.

Bei Atmel habe ich das gefunden: http://ww1.microchip.com/downloads/e...te_AT04056.pdf

Die Beschreiben aber nur (oh Wunder ;) ) die Installation für Ihre eigenen Tools. Mir ist momentan irgendwie nicht klar wie man das am besten in so ein Platformio Projekt einbaut. Vielleicht kann mir da ja einer einen Tipp geben. Ich habe hier aber nur die Kommandozeilen Tools von Platformio installiert und nicht die IDE von denen.

Viele Grüße
Alexander

<Edit>
Man kann aber leider nur für die AVR Controller FreeRTOS so installiern: "platformio lib --storage-dir <Pfad_wo_FreeRTOS_gespeichert_werden_soll> install 507"
Man muss dann nur aus dem Verzeichnis examples eins der Beispiel *.ino in das src Verzeichnis kopieren. Probeweises compilieren für den UNO hat funktioniert. Ich habe es aber nicht installiert und ausprobiert.
</Edit>

Hallo,

soweit ich weiß verwendet Platformio nur ein g++ Paket für alle Cortex M Targets. Ich komme zwar kaum noch dazu was damit zu machen, aber ich kann bestätigen, dass für die Zielsysteme Arduino Due, mbed und Teensy nur einmal das gleiche g++ Paket installiert wird.

Das führt zu gewissen Problemen mit dem Teensy, weil der in seinem eigenen Paket in der Arduino IDE den g++ 5.4 mit -std=gnu++14 verwendet. Als ich zuletzt was mit Platformio gemacht habe, war das noch auf g++ 4.9, der hatte so seine Probleme mit C++14.

Deswegen würde ich mal vermuten, dass das mit FreeRTOS in Platformio für den Due so ähnlich gehen müsste, wie für die AVR. Es muss nur die 32 Bit Toolchain aufgerufen werden und der Quellcode muss kompatibel sein.

Eventuell geht es aber auch ohne Platformio als normales Makefileprojekt. Wenn ich z.B. ein mbed RTOS Programm in der Online IDE erstelle, muss muss ich da nur einen Rechtsklick aufs Projekt machen und Export nach GCC anwählen. Dann bekomme ich ein zip-File zum Download, dass sich unter Debian mit dem dortigen g++-arm-none genauso übersetzen lässt, wie unter Windows mit installiertem ARM GCC, einfach make auf der Kommandozeile in dem entpackten zip aufrufen.

Dass man da für FreeRTOS einen speziellen Compiler bauen muss glaube ich daher eher nicht, auch wenn ich nicht viel über FreeRTOS weiß.

Zitat:

---

Zitat von alexander_ro

Hallo Mädels ... Jungs ... :)

Ich versuche gerade FreeRTOS auf einem Arduino Due zum laufen zu bekommen. Bei mir Läuft die Entwicklungsumgebung auf einem Gentoo Linux. Bisher habe ich noch nie was mit FreeRTOS zu tun gehabt. Ich bin mir auch nicht sicher ob das Sinn macht dafür platformio zu benutzen oder ob man sich besser mit dem gcc selbst einen Cross Compiler baut.

Bei Atmel habe ich das gefunden: http://ww1.microchip.com/downloads/e...te_AT04056.pdf

Die Beschreiben aber nur (oh Wunder ;) ) die Installation für Ihre eigenen Tools. Mir ist momentan irgendwie nicht klar wie man das am besten in so ein Platformio Projekt einbaut. Vielleicht kann mir da ja einer einen Tipp geben. Ich habe hier aber nur die Kommandozeilen Tools von Platformio installiert und nicht die IDE von denen.

Viele Grüße
Alexander

<Edit>
Man kann aber leider nur für die AVR Controller FreeRTOS so installiern: "platformio lib --storage-dir <Pfad_wo_FreeRTOS_gespeichert_werden_soll> install 507"
Man muss dann nur aus dem Verzeichnis examples eins der Beispiel *.ino in das src Verzeichnis kopieren. Probeweises compilieren für den UNO hat funktioniert. Ich habe es aber nicht installiert und ausprobiert.
</Edit>

---

ich hatte vor einem 3/4 Jahr mal was für meinen Due gesucht, aber da gab es noch kein FreeRTOS für ARMs:

Zitat:

---

Phillip Stevens
Phillip Stevens
a year ago

Kurt,

there are ports for FreeRTOS to ARM processors used in DUE and Teensy. But, it is unlikely that I will be able to support them.

The DUE is pretty much EOL, and the specification for a replacement Arduino board is under consideration. Arduino seems to be heading down the Intel path, so that is an option which they are considering.

The Teensy boards use Freescale K20 Cortex M4 devices.
I haven't used any of these devices, but there is an interesting reference point from a Freescale developer.

My next project is getting FreeRTOS running on the Z180 (Zilog Z80) architecture, with some ancient and modern peripheral interfaces.

---

(https://create.arduino.cc/projecthub...arduino-ebc3cc)

Ich konnte daher nur den Scheduler von C. Maglie nutzen, und die Arduino Entwickler verweigern sich neuer MT Libs, weil die bestehenden Cores und Libs nicht Thread-safe sind. Der Due wird eh nur extrem stiefmütterlich unterstützt und nicht weiter supportet, wie es aussieht (war ne Zeitlang ganz raus aus .cc, dann nur noch erwähnt in .org, jetzt nach der Fusion von .cc und .org wieder da, aber wohl nur aus "Vintage"-Gründen.

Zitat:

---

Zitat von HaWe

und die Arduino Entwickler verweigern sich neuer MT Libs,

---

Leicht OT, aber um das Thema geht es auch hier
https://forum.pjrc.com/threads/44723-Arduino-Events
Das ganze ist mittlerweile in Teensyduino angekommen, eine richtige Doku gibt es aber noch nicht. Werde ich mir demnächst mal ansehen.

Den Eindruck das der Due bei seinen Erfindern nicht so recht gewollt ist hatte ich auch schon mal. Ich hatte den damals ausgewählt nach Speicher und Rechenleistung und dachte weil ja ein Arduino der auch so gut unterstützt wird wie die anderen. Ist aber leider nicht der Fall ... :( Von der Unterstützung her wäre der Mega denke ich die besser Entscheidung gewesen.

@Mxt: Ich meinte jetzt nicht unbedingt einen spezielle Compiler sondern nur ob nun mit Platformio oder ohne?
Bei meinem Gentoo ist es halt so das ich alles was ich installiere bauen muss weil es eine Sourcecode Distribution ist die halt nur minimale binär Pakete hat. Es gibt da aber ein Tool das heißt crossdev und macht fast die ganze Arbeit automatisch um die Cross Compiler Tools zu erstellen.

Vielleicht versuche ich es mal mit der mbed Version. Ich muss sagen das habe ich mir noch nie angeschaut weil es mir unsympathisch ist auf fremden Rechnern zu Entwickeln. Versuchen kann man es aber immer mal. Bei dem Orginal Sourcecode ist mir nicht ganz klar wie man das Konfigurieren muss für den SAM3x8E der auf dem Due ja verbaut ist. Dort gibt es ja auch einige Beispiel Projekte aber eins das zu dem SAM3x8E richtig passt habe ich da nicht gefunden.

Zitat:

---

Zitat von alexander_ro

@Mxt: Ich meinte jetzt nicht unbedingt einen spezielle Compiler sondern nur ob nun mit Platformio oder ohne?

---

Ok, meine Antwort bezog sich da auf das "Compiler bauen" in deiner Frage. Dann ist das "bauen" also nur das Gegenstück zum installieren auf dem anderen Systemen.

Man müsste sich halt anschauen, wie das FreeRTOS für die AVR in Platformio gemacht ist. Ob es auch die Sourcen für andere Platformen enthält. Dann besteht da vielleicht eine Chance.

Ansonsten steht ja hier unter supported Tools für Atmel auch GCC
http://www.freertos.org/RTOS_ports.html
Also sollte das auch irgendwo beschrieben sein.

Zitat:

---

Zitat von alexander_ro

Vielleicht versuche ich es mal mit der mbed Version. Ich muss sagen das habe ich mir noch nie angeschaut weil es mir unsympathisch ist auf fremden Rechnern zu Entwickeln.

---

Muss man doch gar nicht. Platformio ist die eine Variante lokal zu übersetzen, aber mbed hat auch sowas selbst, auch in Python
https://os.mbed.com/docs/v5.6/tools/mbed-cli.html

mbed abstrahiert die Hardware auch ziemlich stark. Das hat auch so seine Nachteile. Dafür hat es Multithreading, Ethernet usw.

Es gibt halt z.B. hier ein Board im Uno Format
https://os.mbed.com/platforms/FRDM-K64F/
das einen Controller verwendet, der sehr eng mit dem auf dem Teensy 3.5 verwandt ist (mbed hat MK64FN..., Teensy MK64FX..., unterscheiden sich hauptsächlich bei RAM und Flash). Wenn man da tiefer eintauchen will, hat man in mbed und Arduino immerhin die gleichen Prozessorregister als Basis ...

Zitat:

---

Zitat von Mxt

Ok, meine Antwort bezog sich da auf das "Compiler bauen" in deiner Frage. Dann ist das "bauen" also nur das Gegenstück zum installieren auf dem anderen Systemen.

Man müsste sich halt anschauen, wie das FreeRTOS für die AVR in Platformio gemacht ist. Ob es auch die Sourcen für andere Platformen enthält. Dann besteht da vielleicht eine Chance.

Ansonsten steht ja hier unter supported Tools für Atmel auch GCC
http://www.freertos.org/RTOS_ports.html
Also sollte das auch irgendwo beschrieben sein.



Muss man doch gar nicht. Platformio ist die eine Variante lokal zu übersetzen, aber mbed hat auch sowas selbst, auch in Python
https://os.mbed.com/docs/v5.6/tools/mbed-cli.html

mbed abstrahiert die Hardware auch ziemlich stark. Das hat auch so seine Nachteile. Dafür hat es Multithreading, Ethernet usw.

Es gibt halt z.B. hier ein Board im Uno Format
https://os.mbed.com/platforms/FRDM-K64F/
das einen Controller verwendet, der sehr eng mit dem auf dem Teensy 3.5 verwandt ist (mbed hat MK64FN..., Teensy MK64FX..., unterscheiden sich hauptsächlich bei RAM und Flash). Wenn man da tiefer eintauchen will, hat man in mbed und Arduino immerhin die gleichen Prozessorregister als Basis ...

---

nicht dass ich euch entmutigen will, aber was mich damals schon frustriert hatte, war
a) ein SAM3X8E ist in http://www.freertos.org/a00090.html#ATMEL nicht gelistet, nur andere SAM3 Typen:

Zitat:

---

AT91SAM3 ARM Cortex-M3 based microcontrollers

Atmel SAM3S-EK2 and Atmel SAM3X-EK demo using Atmel Studio
This page presents two projects that both run the same demo application. The first targets the SAM3S microcontroller on the SAM3S-EK2 evaluation board, and the second the SAM3X microcontroller on the SAM3X-EK evaluation board. Both are built and debugged using the free Atmel Studio IDE.

Atmel SAM3U-EK demo using IAR
The demo application presented on this page is pre-configured to execute on the official SAM3U-EK evaluation kit from Atmel. The demo uses the FreeRTOS IAR ARM Cortex-M3 port and can be compiled and debugged directly from the IAR Embedded Workbench for ARM.

---

und
b) die Hinweise auf einer anderen Seite https://create.arduino.cc/projecthub...arduino-ebc3cc, dass noch nicht einmal sehr ähnlich klingende ARM SAM Boards RTOS-kompatibel sind:

Zitat:

---

Let's discuss why it won't work in this particular library. Because the Arduino IDE preconfigures all the hardware resources (Timers, Serial Ports, etc) in a MCU "under the covers" to make it easy for new programmers, there are few resources available to drive a RTOS without generating conflicts with Arduino Libraries, or causing important features to cease working. Luckily with AVR ATmega devices the Watchdog Timer was unused by the Arduino IDE, so I could use that to drive the RTOS System Tick, and the Watchdog Timer is configured identically across all ATmega devices.

Also because no resources were re-purposed (borrowed from the Arduino IDE), there was no need to generate a separate core for the AVR version FreeRTOS library. It works with the standard Arduino core.

To support other hardware within FreeRTOS it is necessary to have both a specific configuration for a hardware timer to generate System Tick interrupts, and a specific efficient Scheduler Interrupt to drive task switching. These two items depend strongly on the hardware, and mean that the implementation will be different for each implementation of the Cortex M0+ core. The Arduino Zero uses the SAMD21 but the Arduino MKR1000 uses the SAMW25. Whilst these are both Cortex M0+, the implementation for each one is different, because of the different features they provide.

Cortex M0+ is a VLSI "library" which can be licenced from ARM. There is no requirement from vendors to implement it in exactly the same way for each device they produce. Unlike ATmega which is a proprietary implementation from one vendor (AVR), each vendor usually changes the implementation of the Cortex line of processors to suit their exact business requirements, which generally change from vendor to vendor, and even across the range provided by one vendor.

So whilst someone might find it useful to support all of these different ARM based boards with an implementation of FreeRTOS, I find that most of my needs are covered by ONE AVR implementation which supports all of these Arduino boards; UNO, LEONARDO, YUN, PRO MINI, MICRO, ESPLORA, all of the Arduino Wearables lke LilyPad, MEGA 2560, Adafruit Feather, and all of the options that third parties produce for inexpensive clones.

There are other timing solutions already available, that provide Threading (quite different from a RTOS in capabilities and features) which may suit simple requirements. These have been mentioned.

Perhaps not the desired answer, but in reality the AVR ATmega based range of Arduino hardware essentially covers all the requirements of those interested in using the Arduino IDE. Beyond these basic projects, the limitations inherent in using the Arduino IDE outweigh the advantages.

---

Trotzdem - oder gerade deswegen - interessiert mich sehr, ob die ARM-Portierungen nutzbar sind für den Due oder eben doch bzw. immer noch nicht.

@Mxt: Das mit mbed habe ich jetzt mal versucht. Die haben da verschiedene FreeRTOS Versionen im Angebot. Diese "freertos-cm3" habe ich jetzt mal als lib installiert. Allerdings habe die keine Beispiele mehr mit dabei. Also muss ich erst mal weiter lesen wie man da zumindest mal einen Task zum laufen bekommt damit ich das dann compilieren kann und schauen ob es läuft.

@HaWe: Ob der Due nun weiter gebaut wird oder nicht ist sicher interessant aber ich habe zwei davon und will die so lange sie ausreichen für das was ich brauche auch verwenden.
Sonst beschweren sich die doch nur das FreeRTOS nicht so recht mit den Arduino lib zusammen passen will. Das wäre mir jetzt eigentlich gleich weil die viel Hardware die der Due mitbringt nicht unterstützt. Wegen der auch erwähnten Atmel lib ist mir unklar. Wenn ich es richtig verstanden habe kann und darf man die auch außerhalb der Atmel IDE benutzen und auch mit eigenen Produkten weiter geben. Was einleuchtet Atmel verdient Geld mit den Prozessoren nicht mit der IDE. Also ich sehe so nicht wirklich einen Grund warum das nun nicht gehen soll.

Ich bin mir aber trotzdem nicht mehr sicher ob sich der Aufwand lohnt nur um einige Tasks parallel auszuführen.

Zitat:

---

Zitat von alexander_ro

@Mxt: Das mit mbed habe ich jetzt mal versucht. Die haben da verschiedene FreeRTOS Versionen im Angebot. Diese "freertos-cm3" habe ich jetzt mal als lib installiert. Allerdings habe die keine Beispiele mehr mit dabei. Also muss ich erst mal weiter lesen wie man da zumindest mal einen Task zum laufen bekommt damit ich das dann compilieren kann und schauen ob es läuft.

@HaWe: Ob der Due nun weiter gebaut wird oder nicht ist sicher interessant aber ich habe zwei davon und will die so lange sie ausreichen für das was ich brauche auch verwenden.
Sonst beschweren sich die doch nur das FreeRTOS nicht so recht mit den Arduino lib zusammen passen will. Das wäre mir jetzt eigentlich gleich weil die viel Hardware die der Due mitbringt nicht unterstützt. Wegen der auch erwähnten Atmel lib ist mir unklar. Wenn ich es richtig verstanden habe kann und darf man die auch außerhalb der Atmel IDE benutzen und auch mit eigenen Produkten weiter geben. Was einleuchtet Atmel verdient Geld mit den Prozessoren nicht mit der IDE. Also ich sehe so nicht wirklich einen Grund warum das nun nicht gehen soll.

Ich bin mir aber trotzdem nicht mehr sicher ob sich der Aufwand lohnt nur um einige Tasks parallel auszuführen.

---

verstehe ich jetzt nicht recht - du willst doch den Arduino Due mit der Arduino IDE und FreeRTOS zusammen benutzen, oder etwa nicht? Oder willst du etwa den Arduino Due ohne Arduino IDE nutzen, also auch ohne die ganzen sonstigen Arduino device und core driver libs?
Immerhin schreibt ja der Autor der Arduino-RTOS Implementierung, dass er gerade nicht auch den Due supporten will, weil er ja wohl EOL ist (und auch noch nicht einmal andere SAM und SAMD cores) und das mit dem Due gilt sicher auch nicht für ihn allein.

ps,
und nur um mal ein paar Threads parallel auszuführen, brauchst du auch kein FreeRTOS, das geht mit dem Due Scheduler auch. Darf nur nicht so anspruchsvoll werden (müssen) wie bei POSIX pthread.

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.

Zitat:

---

Zitat von alexander_ro

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.

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

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

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.

Zitat:

---

Zitat von alexander_ro

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.

Zitat:

---

Zitat von Mxt

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

Zitat:

---

Zitat von HaWe

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.

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!

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 ... :(

Zitat:

---

Zitat von 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 ... :(

---

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

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.

Zitat:

---

Zitat von alexander_ro

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.

Zitat:

---

Zitat von 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.

---

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

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/

Zitat:

---

Zitat von alexander_ro

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.

---

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

Hier gibts das noch: http://perso.ensta-paristech.fr/~pes...s/arduino.html
(Ganz unten ist das Babix und da kann man Doku und Sourcecode herunterladen.)

Sieht auf den ersten Blick interessant aus muss ich aber noch genauer ansehen. Vielleicht finde ich da wie man das macht mit dem Speichern der Prozessdaten und dem wieder zurückspringen.

Nein Java wollen wir hier nicht ist ja gruselig ...
pthread muss man dazu nicht erst mal Prozesse haben. Ich dachte immer ein Thread ist ein Teil eines Prozesses. Vermutlich gibt es die beim Arduino nicht weil man da die Unterstützung des Betriebssystems braucht und die gibts ja hier nicht.

Zitat:

---

Zitat von alexander_ro

Hier gibts das noch: http://perso.ensta-paristech.fr/~pes...s/arduino.html
Nein Java wollen wir hier nicht ist ja gruselig ...

---

Hurra, wir sind uns einig. ;)

Zitat:

---

Zitat von alexander_ro

pthread muss man dazu nicht erst mal Prozesse haben. Ich dachte immer ein Thread ist ein Teil eines Prozesses. Vermutlich gibt es die beim Arduino nicht weil man da die Unterstützung des Betriebssystems braucht und die gibts ja hier nicht.

---

Das sehe ich auch so, lasse mich aber gern vom Gegenteil überzeugen.

Was es gibt ist std::thread Unterstützung für C++, wie hier, noch etwas experimentell, für den Teensy
https://github.com/ftrias/TeensyThreads

Ich habe mir jetzt mal das Babix näher angeschaut ist aber nicht so einfach das was ich davon brauche heraus zu lesen.

Man kann vermutlich schon so tun als ob das Programm das auf dem Controller läuft ein Prozess ist und lässt dann innerhalb von diesem die Threads laufen.

Damit ich schon mal unabhängig von dem was mit dem Babix herauskommt an meiner Anwendung ein bisschen weiter Programmieren kann habe ich da mal den Due Scheduler benutzt. Der verteilt ja nur Rechenzeit an andere Funktionen wenn man in der Hauptschleife (loop) die Funktion delay aufruft. Das war mit zuerst entgangen und daher hat er nicht funktionieren wollen.

Hat von euch eigentlich jemand Erfahrung damit den Linux Kernel auf so Controllern zu verwenden. Der soll ja eigentlich auf deutlich kleinerem als so Raspi oder Gnublin auch noch laufen können?

Zitat:

---

Zitat von alexander_ro

Ich habe mir jetzt mal das Babix näher angeschaut ist aber nicht so einfach das was ich davon brauche heraus zu lesen.

Man kann vermutlich schon so tun als ob das Programm das auf dem Controller läuft ein Prozess ist und lässt dann innerhalb von diesem die Threads laufen.

Damit ich schon mal unabhängig von dem was mit dem Babix herauskommt an meiner Anwendung ein bisschen weiter Programmieren kann habe ich da mal den Due Scheduler benutzt. Der verteilt ja nur Rechenzeit an andere Funktionen wenn man in der Hauptschleife (loop) die Funktion delay aufruft. Das war mit zuerst entgangen und daher hat er nicht funktionieren wollen.

Hat von euch eigentlich jemand Erfahrung damit den Linux Kernel auf so Controllern zu verwenden. Der soll ja eigentlich auf deutlich kleinerem als so Raspi oder Gnublin auch noch laufen können?

---

also das verstehe ich ja nun nicht, um ehrlich zu sein.
Der Vorteil von Arduinos ist ja gerade, dass sie echtzeitfähig sind, im Gegensatz zum Userspace von Linux-Rechnern. Wenn dir aber Linux-Rechner schnell genug sind und du vor allem pthread brauchst, dann nimm doch gleich nen Raspi oder Beaglebone plus i2c-, USB- oder SPI-Portexpander, statt jetzt embedded Linux in einen Due reinzupressen.

Es ist ja jetzt nicht so das Linux generell nicht Echtzeitfähig wäre.
<Edit>
https://www.elektronikpraxis.vogel.d...y-pi-a-630497/
</Edit>

Echtzeitfähig zu sein hat jetzt nur wenig mit der Schnelligkeit zu tun.

Es war auch nur mal so eine Idee ob die gut ist weiß ich nicht. Die mit FreeRTOS war es ja schon mal nicht.