Zykluszeiten bei RT-Linux oder RTAI?

"Thorsten Ostermann" schrieb im Newsbeitrag news: snipped-for-privacy@news.dfncis.de...

Naja, da sollte man sich vielleicht fragen, ob es nicht beser ein uC oder DSP sein soll. Das Rumgeeiere mit den PCs bei solchen Sachen . . .

MfG Falk

Hallo Falk!

Wenn ich das System von Grund auf aufgebnaut hätte, hätte ich vermutlich einen 32-bit uC genommen. Oder gleich dSpace ;-) Aber das steht hier leider nicht zur Debatte. Es ist einiges an PCI-Messkarten vorhanden, die ich weiter nutzen will/muß. Insofern geht am PC kein Weg vorbei. Denkbar ist höchstens die Trennung von GUI (zwingend Win) und Echtzeitteil (daher die Frage nach RT-Linux oder RTAI).

Gruß Thorsten

Thorsten Ostermann schrieb

oder

Hallo auch,

Trennung von GUI und Echtzeit physikalisch: Split-Backplane, Eine CPU-Karte für DOS (oder RT-DOS), eine fuer die GUI. Messdaten in RAM-Disk schreiben und beide "Rechner" z.B. mit Novell-Lite verbinden. Handshake über Status-Dateien. Gibt schoene CPU Karten mit Prozessoren AMD, 300MHz, 5W Verlustleistung.

Gruss, Georg (der das damals mit separaten 386/40 und mit DOS -> Windoze 3.11 so praktiziert hat)

Hallo Georg!

OK. Backplace hört sich für mich aber nach IPC bzw. cPCI an. Ich habe "normale" PCI-Karten und einen kompletten Windoof-Rechner. Da der RT-Teil auf die PCI-Karten zugreifen muß, könnte man den Rechner für den RT-Teil nehmen, und eine CPU-Karte für die GUI einstecken.

Damit weis ich aber immernoch nicht, welches OS für mich geeignet (=schnell genug) ist. Was ist denn eigentlich RT-DOS?

Gruß Thorsten

" snipped-for-privacy@Ostermann-net.de" schrieb:

Da das offenbar ein kommerzielles Produkt ist, warum ziehst Du nicht QNX in Betracht?

Hallo Joerg!

Ist 'ne Preisfrage. Geld ist an der Uni Mangelware ;-) Kannst du bei QNY was zu den Leistungsdaten sagen?

Gruß Thorsten

Thorsten Ostermann schrieb:

Meines Wissens kannst Du Dir ein QNX zum Testen irgendwo kostenlos besorgen. Zumindest haben sie lange Zeit es sogar kostenlos an Privatpersonen abgegeben. Frag' doch einfach mal dort, nein, persönlich habe ich auch keine Erfahrungen damit, aber von mehr als einer Ecke gehört, dass es recht gut ist. Da sie mittlerweile so weit Posix-kompatibel sind, dass man vielen Internet-Sourcecode dort aus der Kiste raus compiliert bekommt, sollte man sich auch einigermaßen schnell wohlfühlen können.

Thorsten Ostermann schrieb:

RTAI).

CPU-Karte

schreiben

Das wird wohl ohne Geld nix, eine PCISA-Backplane passt (leider) nicht in ein Standard-PC-Gehäuse. Meines Wissen kannst Du auch keine ISA-CPU-Karte in ein MoBo stecken, lasse mich aber gerne aufklären.

Kann auch RTX-DOS geheissen haben, ist ewig her. Auf 386/40 und aufwärts bist Du mit DOS6.22 eigentlich immer schneller als Messkarten (erzähl mal welche?), erst recht wenn Du nichts grafisch visualisieren musst (das macht doch die GUI auf einem zweiten PC). Also zwei PC nehmen, der olle fürs DOS müsste doch für ne Uni kein Beschaffungsproblem darstellen. Den für PCI hast Du ja schon. Zur Statuskommunikation Druckerport-Pins zweckentfremden wenn auf Deinen Karten kein I/O mehr frei ist. Die billigste "Eingangskarte" ist eine Game-Port-Karte: 4 x Digital In statt Feuertasten.

Realtime-sparender Trick für Messwert-Textdarstellung: Immer den alten String aufbewahren und nur bei Vergleich "ist ungleich neuem" ausgeben, und dann auch nur so häufig dass diese auch human abgelesen werden können.

Für unsere (meist komplexen) Prüfstände war DOS immer "realtimig" genug, auch auf 286ern. Einschliesslich bis zu 256 Ein- und Ausgängen die über einen 8255 adressiert wurden.

Gruss, Georg

Hallo Georg!

Das hatte ich auch nicht vor. Außerdem bracuhe ich PCI, kein ISA.

Ok, dann hat sich das eh' erledigt.

Adlink PCI-6208 (DA), PCI-7224 (Dig. I/O), PCI-8133 (Encoder/Zähler) und PCI-9118 (AD). Letztere läuft zur Zeit im Burst-DMA Mode und generiert so mehr als 100.000 samples/sec.

Der PCI-Rechner ist der Echtzeit-Teil...

Die I/Os sind das geringste Problem und der LPT ist vermutlich zu langsam (außer für einfache Schaltfunktionen).

Auch die Rechenzeit ist nicht das Problem.

Genau HIER liegt das Problem. Der normale PC-Timer ist eben nicht genau genug. Die meisten RT-Betriebssysteme haben Zeitscheiben bis minimal

Gruß Thorsten

Hallo Thorsten,

| > Zur Statuskommunikation Druckerport-Pins zweckentfremden wenn auf Deinen | > Karten kein I/O mehr frei ist. | | Die I/Os sind das geringste Problem und der LPT ist vermutlich zu | langsam (außer für einfache Schaltfunktionen).

Das vermute ich eher weniger. Ein Bit dort zu verändern ist eine Sache von wenigen µs

| Genau HIER liegt das Problem. Der normale PC-Timer ist eben nicht genau | genug. Die meisten RT-Betriebssysteme haben Zeitscheiben bis minimal | 100µS. Damit schafft man eben nur 5 kHz, falls noch andere Tasks rechnen | müssen. Und 5 kHz sind zuwenig.

zu wenig für was? ich gebe zu, ich habe bisher nicht den ganzen Baum gelesen, aber hier scheint mir ein Irrtum vorzuliegen.

| 20 kHz sollten schon möglich sein.

Nimm z.B. mal ganz banale Soundkarten. Die halten ihr Timing von 48 kSps ziemlich gut, auch fernab von irgendwelchen RT-Betriebssystemen. Das ist eher eine Frage der lokalen Pufferung. Der ganz ordinäre Timer im orginal-PC läuft mit 1,1931182 MHz. Dieser Timer ist mehr oder weniger frei programmierbar.

| Neuere PCs haben offenbar einen zusätzlichen Timer, mit dem deutlich | mehr zu holen ist. Aber ich finde nirgends Infos darüber, welches OS | diese Möglichkeiten auch nutzt :-( Notfalls könnte man auch die Timer | auf den Messkarten als Systemtimer zweckentfremden. Eine hat zwei | kaskadierte 16bit Timer frei, mit denen man einen 2 MHz takt | runterteilen kann. Damit sollte man schon was tun können?!

Es sollen also wohl Synchronitäten zwischen den Karten hergestellt werden. Das würde ich z.B. mit Markern einer gemeinsamen Quelle versuchen, die in einen Kanal/ Messkarte eingespeist wird. Das kann ein einfacher externer Oszillator sein, oder ein LPT-Pin, der getoggelt wird. Mit dem aufgenommenen Signal kann man dann die lokalen Timer retrospektiv synchronisieren.

Im Moment würde ich mich mal umsehen, was die Karten intern bereits für Funktionen vorhalten, um das fehlende RT zu kompensieren und mir dann Gedanken über eine geeignete Synchronisierung derselben machen. In der Regel haben die Karten ihre eigene CPU, dort bereits eine Art RT-System incl. Timer. Das sollte im Normalfall schon ausreichen.

MArtin

mit

Den APIC?

MaRTE. ;-)

Du brauchst einen Interrupt, keinen Scheduler.

Vinzent.

Vielleicht hilft Dir das hier zum Testen:

In der RTAI-Anleitung[0] findet man (Seite 19):

------------------------------------------------------------------------ RTAI's performance is very competitive with the best commercial Real Time Operating Systems (such as VxWorks, QNX etc), offering typical context switch times of 4 uSec, 20 uSec interrupt response, 100 KHz periodic tasks, and 30 KHz one-shot task rates. The main limitation being imposed by the system hardware, rather than the real-time software itself.

------------------------------------------------------------------------

An sonsten kann Dir in der RTAI Mailingliste weitergeholfen werden.

hth, Nils

Thorsten Ostermann schrieb:

Wenn du noch bis nächstes Jahr Zeit hast, werde ich das mal austesten. Interessiert mich nämlich persönlich auch. Wir testen RTAI gerade intensiv. Wenn du es eilig hast, kannst du dich auch auf der rtai Webseite in den Newsletter eintragen und dort fragen. Die Leute dort sind erfahrungsgemäß sehr kooperativ.

Hajü

Hallo Martin!

Das würde ich als langsam bezeichnen, wenn man größere Datenmengen übertrage will und der ganze Zyklus nur 50-100µS (incl. der Rechnerei vorher und nachher) dauern darf.

Nein. Lies bitte die Ausgangsfrage nochmal. Es geht um Regelung in Echtzeit.

...

Siehe oben. Das hilft mir nichts, weil ich mir mit diesen zusätzlichen Totzeiten das System versaue.

In der Regel? Auf meinen Karten ist keine CPU, nur ein ASIC zu Buskopplung.

Gruß Thorsten

Hallo Vinzent!

Genau.

Was ist MaRTE?

Den könnte ich über die Timer ja erzeugen. Das nützt nur nichts, wenn der Scheduler die ISR erst Stunden später anspringt, weil noch eine andere "wichtige" Task rechnet?!

Gruß Thorsten

Hallo Nils!

Das schau ich mir nächste Woche mal an.

Das ist doch zumindest mal ein Statement ;-)

Danke erstmal! Thorsten

Hallo Nils!

Das schau ich mir nächste Woche mal an.

Das ist doch zumindest mal ein Statement ;-)

Danke erstmal! Thorsten

Hallo Hans-J.!

Ja, sicher. Auf ein paar Tage kommt es nicht an. Bitte folgende E-Mailadresse verwenden: T.Ostermann(at)wzl.rwth-aachen.de

Gruß Thorsten

Ein minimales Open-Source RTOS.

Ja.

Normalerweise hat selbst der wichtigste Task nicht die Prioritaet eines=

Interrupts, insofern kann das eigentlich nicht passieren. Typischerweis= e sieht das ja so aus:

|subtype Any_Priority is Integer range 0 .. 31; |subtype Priority is Any_Priority range 0 .. 30; |subtype Interrupt_Priority is Any_Priority range 31 .. 31;

Aber trotzdem: Gerade bei hohen Interrupt-Raten wuerde ich auch eher dafuer stimmen ;-), den Interrupt ohne Umweg ueber den Scheduler direkt=

zu bearbeiten, das koennte einigen Jitter reduzieren. Aber ich bin auch=

etwas altmodisch.

Momentan ist mir nichts ueber die Interrupt-Latenzzeiten "moderner" x86=

(ab Generation Pentium(tm)) bekannt (falls da jemand Daten hat, her damit). Aber das werde ich irgendwann ab Maerz wohl am konkreten Beispiel eines AMD =C9lan SC520 selbst erfahren. Das momentane System basiert auf einem NEC V30 @ 8 MHz ohne OS (den Bootloader kann man schwerlich als solches bezeichnen) und kommt mit Interrupt-Raten im Bereich 30 bis 40 kHz noch klar (die Handler sind relativ komplex, da das gesamte System interruptgesteuert arbeitet). Insofern bin ich guter=

Hoffnung, dass ein 133 MHz-Prozessor das auch mit dem "Overhead" eines echten RTOS noch schafft.

Vinzent.