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!
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 ...
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)?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 ...
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.
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.
Berechtigungen
Zitieren
Lesezeichen