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!
Ich denke, dass Echtzeit und Linux nicht zusammen passen. Dafür braucht man andere Betriebsysteme. http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/6.linuxrt/LinuxRT2.htm
Eine Mikrosekunden Latenz erreicht man mit Interrupts. Abhaengig wieviele Interrupts gleichzeitg anstehen sollen, baruch man etwas Clockfrequenz mehr.
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?
RTLinux ist eine Erweiterung für vorhersehbare Latenzen unter Linux: http://de.wikipedia.org/wiki/RTLinux Im Artikel stehen noch einige Alternativen.
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?
Der Preis darf ruhig etwas höher sein, dass das ein andere Liga als ein 8-Bit ATMega ist ist mir bewußt.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.