Guten Tag,
was sind typische Latenzen für ein Echtzeit-Linux auf, sagen wir einem
ARM ? Kommt man überhaupt in den Bereich weniger Microsekunden? Oder
geht sowas nur mit einem Controller ohne Betriebssystem?
Konkret: Was geht mit z.B. einem Beagle-Board? Das hat ja anscheinend
auch "Realtime-Units", also integrierte MCU. Hat jemand hier schonmal
damit gearbeitet ? Wäre interessant zu hören wie weit man damit kommt.
Ich bin mir sicher hier sind fitte Leute unterwegs die was dazu sagen
können ;) - Dankeschön!
Ist eine Option ein Linuxsystem mit angebundenem Mikrocontroller (und
natürlich unter Verwendung von irqs) zu benutzen. Das Linux mit all
seinen Treibern für Standardaufgaben, und dann den Mikrocontroller als
schnelle "ausführende Einheit", die mit dem Linux spricht?
Braldo schrieb:> Guten Tag,>> was sind typische Latenzen für ein Echtzeit-Linux auf, sagen wir einem> ARM ? Kommt man überhaupt in den Bereich weniger Microsekunden? Oder> geht sowas nur mit einem Controller ohne Betriebssystem?>> Konkret: Was geht mit z.B. einem Beagle-Board? Das hat ja anscheinend> auch "Realtime-Units", also integrierte MCU. Hat jemand hier schonmal> damit gearbeitet ? Wäre interessant zu hören wie weit man damit kommt.>> Ich bin mir sicher hier sind fitte Leute unterwegs die was dazu sagen> können ;) - Dankeschön!
Hi,
in den Bereich von Microsekunden kommt man durchaus. Mit der
Xenomai-Erweiterung und spezifischen Treibern habe ich ein paar
Echtzeit-Bildverarbeitungsgeschichten am Laufen. Da reagiert der Prozess
ansich binnen < 1us auf eintreffende Daten.
Der Jitter ist auch nicht schlecht, aber es hängt eben sehr davon ab,
was sonst noch alles läuft. Man muss aufpassen, dass die Applikation
nicht an kritischen Stellen in die non-RT-Domäne springt.
Bei Xenomai hat man eine sehr gute Kontrolle über Treiber und Ablauf der
Realtime-Prozesse, mit der etwas später dazugekommenen
PREEMPT-Geschichte soll das ganze auch besser mit den klassischen
Treibern funktionieren. Das ist quasi der einzige "Nachteil", dass man
u.U. für gute Echtzeit ein eigenes Xenomai-Interface für den Treiber
schreiben muss.
Für weitere Details müsste man aber deine Anforderungen an "Echtzeit"
kennen..
Erstmal danke für die Hinweise, werde ich mir anschauen!
Anwendungen: mich würde beispielsweise interessieren ob man damit einen
PID-Controller bauen kann, mit vernünftiger Bandbreite (ein paar 10
kHz). Das Fehlersignal kommt dabei aus der Leistung eines RF-Signals,
idealerweise sollte der Controller/DSP das auch samplen und berechnen.
Im moment wird das ganze analog gemacht, mit Mischen und Filter usw.
Wäre Klasse digitale Filter zu benutzen. Weitere Anwendung: Sinus mit
100 kHz tracken und beeinflußen.
Braldo schrieb:> Wäre Klasse digitale Filter zu benutzen.
Dann wäre aber ein DSP angebrachter als ein Universalprozessor mit Real
Time System.
Gruss Reinhard
Ich dachte die Grenzen verschwimmen sowieso, und sowas wie der OMAP auf
dem BEAGLE kann auch schon eine Menge DSP. Aber ich bin für alle Ideen
offen! Und was wäre da ein üblicher Kandidat für einen DSP?
Braldo schrieb:> Und was wäre da ein üblicher Kandidat für einen DSP?
Die Technologie wird hauptsächlich von Texas vorangetrieben. Ein
Kandidat wäre:
http://www.ti.com/tool/tmdsdsk6416
Ist aber nicht ganz so billig wie Atmega und ähnliche. Allerdings muss
man das Ganze betrachten, Softwareunterstützung, Kosten dafür usw.
Gruss Reinhard
Reinhard Kern schrieb:> Die Technologie wird hauptsächlich von Texas vorangetrieben.
Hehehe, die haben ja auch alles aufgekauft, was nicht bei drei auf den
Bäumen war. Der OMAP ist ja schon in ganz schönes Tier, wobei ich den
Eindruck habe, das seine Stärke eher bei Bildverarbeitung liegt.
Andere Kandidaten für deine (fast) NF Anwendungen sind noch der gute
alte Blackfin von AD und die DSP56k Reihe von Freescale.
Matthias Sch. schrieb:>> Die Technologie wird hauptsächlich von Texas vorangetrieben.>> Hehehe, die haben ja auch alles aufgekauft, was nicht bei drei auf den> Bäumen war.
Schöner Witz. Herrje, TI ist in diesem Business vorne dabei, seit es
überhaupt DSPs gibt.
A. K. schrieb:> Schöner Witz - TI kauft mangels Knowhow Firma auf, die DSPs herstellt.
Hättest du weitergelesen, hättest du gesehen, das ich durchaus andere
Hersteller genannt habe. TI hat sich aber mit NatSemi und Fairchild
schon ein paar potentielle Konkurrenten unter den Nagel gerissen.
Arbeite selber gerne mit TI und habe sowohl mit TMS320 als auch mit den
TAS Audio DSPs gute Erfahrungen gemacht.
Auf jeden Fall schonmal vielen Dank für die Tips hier! Läuft auf so
einem DSP dann eigentlich auch ein Betriebssystem oder muss man sich das
eher so wie auf einem ATMega vorstellen? Wird so ein Teil dann in C
programmiert?
Irgendwie ist der Zusammenhang von Linux und 10kHz PID unbefriedigend.
Was soll das? Wenn ich einen DSP haben will, nehm ich einen DSP, wie zB
einen dsPIC. Fuer ein Betriebssystem nehm ich einn Anderen.
Braldo schrieb:> Läuft auf so> einem DSP dann eigentlich auch ein Betriebssystem oder muss man sich das> eher so wie auf einem ATMega vorstellen?
Gibts beides. Die Beagleboards z.B. laufen mit Linux, du könntest aber
auch barebone nur eine Applikation drauf laufen lassen.
http://beagleboard.org/
Mein TMS320 Board z.B. ist ein 'Algorithmen Testboard' und hat als
Zuarbeiter einen Mega32, der dem DSP Programme unterschiebt und ihn
startet.
Den TAS3208 benutze ich als DSP in einem Bassverstärker, der TAS hat
einen 8051 WARP Prozessor untergeordnet, der für I/O und Softwareladen
benutzt wird. Gesteuert wird das ganze von einem Mega328 über I2C.
Die TAS sind für Audio gut, sind aber für dich nicht geeignet.
Matthias Sch. schrieb:> Gibts beides. Die Beagleboards z.B. laufen mit Linux, du könntest aber> auch barebone nur eine Applikation drauf laufen lassen.> http://beagleboard.org/>> Mein TMS320 Board z.B. ist ein 'Algorithmen Testboard' und hat als> Zuarbeiter einen Mega32, der dem DSP Programme unterschiebt und ihn> startet.> Den TAS3208 benutze ich als DSP in einem Bassverstärker, der TAS hat> einen 8051 WARP Prozessor untergeordnet, der für I/O und Softwareladen> benutzt wird. Gesteuert wird das ganze von einem Mega328 über I2C.>> Die TAS sind für Audio gut, sind aber für dich nicht geeignet.
Ok. Das ist sehr interessant. In die Richtung ging meine Frage. Ab einer
gewissen Leistungsklasse haben Controller fast immer ein Betriebssystem
wie es aussieht, was dann wieder Probleme (mit Latenz) mit sich bringt.
Interessant das es das Beagleboard dann auch ohne gibt. Dann hat man
vermutlich gleich deutlich besser Echtzeit. Dafür muss man vermutlich
Kommunikation usw. anders regeln (USB und Netzwerk vertragen sich damit
vermutlich nicht mehr so).
LinuxCNC setzt auf RTLinux auf.
Dort kann man bei einem passenden, ganz normalen PC-Board (z.B. ein
D525MW mit Atom) z.B. Schrittmotorfrequenzen von bis zu 50kHz erreichen,
also 100kHz in der schnellsten Task (bei bis zu 9 Achsen!).
Der Jitter liegt dabei unter 3us.
Auch wenn das HAL dort natürlich für CNC optimiert ist - dort gibt es
auch PID-Regler bzw. man kann sich leicht eigene Erweiterungen
schreiben.
Vielleicht ist das ja was für Dich.
Ansonsten gibt es auch NuttX, ein POSIX-kompatibles RTOS mit USB,
Netzwerk, Grafik usw.
Läuft sogar auf kleinen AVRs
Chris D. schrieb:> LinuxCNC setzt auf RTLinux auf.>> Dort kann man bei einem passenden, ganz normalen PC-Board (z.B. ein> D525MW mit Atom) z.B. Schrittmotorfrequenzen von bis zu 50kHz erreichen,> also 100kHz in der schnellsten Task (bei bis zu 9 Achsen!).> Der Jitter liegt dabei unter 3us.>> Auch wenn das HAL dort natürlich für CNC optimiert ist - dort gibt es> auch PID-Regler bzw. man kann sich leicht eigene Erweiterungen> schreiben.>> Vielleicht ist das ja was für Dich.>> Ansonsten gibt es auch NuttX, ein POSIX-kompatibles RTOS mit USB,> Netzwerk, Grafik usw.
Das ist in jedem Fall interessant, werde ich mir anschauen!
Naiverweise hätte ich ja am liebsten 'gar keinen' Jitter, wie wenn ich
einen analogen PID-Regler benutze. Totzeit ist ok, aber am besten immer
die gleiche. Das bekommt man mit einem Controller und irqs ohne
Betriebssystem doch auch hin, der nix anderes macht. (Oder nicht?).
In vielen Fällen ist ein Jitter schon tolerierbar, aber mich
interessiert wie weit man das Treiben kann.
Also: Kann ich beispielsweise ein Beagleboard ohne Betriebssystem
nutzen, um einen PID-Regler mit 10 oder sagen wir 100 kHz bauen, der
keine Latenz hat? Oder nur eine von ein paar Zyklen? Immerhin läuft das
Ding mit 10^9 Hz, also 4 Größenordnungen über der angestrebten
PID-Bandbreite (!). So ein paar Zyklen kann der dann ruhig vergeigen.
Dann sollten dann aber kein microsekunden rauskommen. Und dann: reicht
die Rechenleistung dann auch noch, um ein wenig zwischendurch zu
rechnen? Sollte doch wohl...
Braldo schrieb:> Das bekommt man mit einem Controller und irqs ohne> Betriebssystem doch auch hin, der nix anderes macht. (Oder nicht?).
Der nix anderes macht ist der entscheidende Punkt. Wenn du deine Aufgabe
mit einem IRQ höchster Priorität löst, der von keinem anderen
unterbrochen werden kann, und keine Abschnitte mit IRQ disabled
vorkommen mit mehr als einer bestimmten Zyklenzahl, hast du die Sache im
Griff. Sobald du 2 IRQs von der Sorte hast nicht mehr - entweder muss
Regler2 (zu lange) warten, bis Regler1 fertig ist, oder Regler1 wird (zu
früh) unterbrochen, in beiden Fällen hast du keine garantierte
Antwortzeit mehr. Der Prozessor ist dann einfach nicht leistungsfähig
genug für beide Aufgaben, und daran ändert auch ein Echtzeit-BS nichts.
Für eine Einzweckmaschine ist ein BS funktionell überflüssig, da haben
DSPs ihre Berechtigung. Ein BS kann dir aber Arbeit abnehmen, z.B.
kannst du mit einem BS Text auf einen Device Console ausgeben, ohne BS
musst du Routinen für Keyboard und Display selber schreiben, aber
solange man keine komplexe Peripherie verwenden muss wie Festplatte oder
Netzwerk fällt das nicht ins Gewicht.
Gruss Reinhard
Ok. Dann wirds ein DSP, der sich ausschließlich um den Regler kümmert.
Und auf dem läuft dann kein BS, sondern der ist 'bare metal'. Kann man
dann trotzdem z B den gcc nehmen? Also auch sinnvoll? Oder sind die
kommerziellen Lösungen deutlich besser? Zum Beispiel für den oben
erwähnten von TI.
In diesem Zusammenhang: Was ist denn von diesem Kombinationen von DSP
(bare metal) und ARM (Linux) auf einem Chip zu halten?
(http://www.ti.com/product/OMAP-L138) . Kann man dann Netzwerk/USB usw.
auf dem ARM laufen haben, und mit dem DSP im obigen Sinne einen
schnellen Regler bauen? Dann kann der ARM Kommunikation und
"Organisation" übernehmen, der DSP regelt.
Wir fragen nochmals : was soll's werden? Der schnellste Regler ist ein
akademischer Furz. Kein Jitter ist ein Furz. Was soll's werden?
Moderne controller haben ein Eventsystem, das erledigt einiges waehrend
eines Interrupts selbst. Und wenn's vieles gleichzeitig sein soll, dann
gibt's auch noch FPGAs.
T. roll schrieb:> Wir fragen nochmals : was soll's werden?
Dito. Wenns ein reiner Regler für die paar kHz sein soll, kann das
selbst ein TMS320C025 Urgestein mit 40Mhz Takt, vorausgesetzt, die I/O
Bausteine sind einigermassen passend gewählt.
Wenn er aber dazu noch mit der Aussenwelt kommunizieren soll, ein
bisschen Netzwerk und TCP/IP Tralala, 10 Knöpfe bedienen und noch ein
LCD ansteuern soll, dann klappt das mit einem DSP nur dann, wenn die
entsprechende Rechenleistung so hoch ist, das er den Hauptjob nicht
vergisst, oder ein Koprozessor das übernimmt.
