Forum: Linux-Unix Programmierung

Hallo zusammen,

ich habe folgendes Problem. Zur Ansteuerung eines Bussystems benutze ich einen Softwaremaster.
Auf diesen kann über eine Applikation zugegriffen werden. Die passende Schnittstelle dazu, sowie Beispielcode wurde schon mitgeliefert.
( Alles für Linux und in C, User und-Kernel-Spaceprogramme ).

So, ich habe den Beispielcode genommen und stark modifiziert. Wie z.B. Anlegen und Auslesen von Konfigurationsdaten, dynamisches Anlegen von Speicher etc. Also Funktionen aus stdio.h, stdlib.h und string.h.

Die genaue Auflistung: FILE *open, fgets, strstr(), fclose, malloc(), realloc(), strtol(), system(), printf().

Natürlich habe ich alles zuerst im User-Space programmiert. Das läuft nun recht stabil.
Leider ist die Performance der Applikation im User-Space auf lange Sicht nicht ausreichend. Um die Performance des Busses zu steigern,
muss die Applikation als (z.B. RTAI-)Kernelmodul laufen.

Nun die große Frage, ist eine Portierung überhaupt möglich, wie stark muss mein Quellcode verändert/angepasst werden.
Leider ist mein Wissen über Kernelmodule sehr nah bei 0. Meine bisherigen Recherchen ergaben, dass die ganzen Bibliotheken stdlib.h etc. nicht
verfügbar sind. Stattdessen stehen die Funktionen von module.h bereit. Zudem sollen Kernelmodule recht "dumm und einfach" sein und Funktionen wie aus Daten lesen, sollten vermieden werden.

Ich kann also momentan nicht abschätzen, ob die Portierung möglich ist. Gibt es noch wichtige Dinge die ich bedenken muss.
Bin für jeden Tipp und Ratschlag dankbar.

Gruß
Juri

 

Hallo Juri,

Zitat:

Leider ist die Performance der Applikation im User-Space auf lange Sicht nicht ausreichend.

Warum nicht?

Gruss,
Philip

--
The C Programming Quiz - bitte Fragen einreichen :)

 

Hallo Philip,

mit Performance meine ich die Zykluszeit des Busses. Leider ist im User-Space bei ca. 1kHz die Grenze.

Die genau Antwort kann ich dir zitieren, da ich damals die selbe Frage gestellt habe.

Zitat:


Hello Juri,

Please note, the user space example is only a user space example. Let me
explain. you have no realtime deterministic on a rtai system for an user
space example. The programm is schedulded by the normal linux system. A
normal debian kernel has a cycle freuency of 1000 Hz. If your process freq is
equal or higher you will get problems.

For RTAI examples, please have a look at the rtai kernel example.

If you use a rt-preempt kernel, you will get a proper system behavior for the
userspace example.

Greatings

Andreas

Ich hoffe das hilft dir weiter.

Gruß
Juri

 

Hallo Juri,

Zitat:
mit Performance meine ich die Zykluszeit des Busses.

Bei solchen Begriffen sollte man immer möglichst genau angeben, was gemeint ist. Sonst versteht jeder etwas anderes.
Was ist das für ein Bus? Und ist für dich die duchschnittliche "Performance" (Average-Case ) oder die schlechtest mögliche "Performance" (Soft/Hard-Realtime) interessant?

Zitat:
Leider ist im User-Space bei ca. 1kHz die Grenze.

Solange du nur die Standard-Installation einer normalen Desktop-Distribution verwendest ist, und dein Programm als normaler Task läuft, kannst du dich auf gar nichts verlassen, auch nicht auf die 1kHz.

Was passiert wenn dein System stärker belastet wird (CPU-Last, mehr Tasks, viele PCI/USB/Network/...-Transfers, ...)?

Wenn du garantierte Zykluszeiten brauchst, gilt allgemein (nicht nur unter Linux, sondern überall):

*) Du brauchst irgendeine Art von Echtzeit-Scheduler, der dir diese Zeiten garantiert. Vorher ist es unwichtig, ob dein Task im User- oder Kernelspace läuft.
*) Wenn auf externe Ereignisse reagiert werden muss (mit geringer Latenz), darf sich das System nicht beliebig lang in "nicht unterbrechbaren" Zuständen befinden.

Was ist damit:

Zitat:
If you use a rt-preempt kernel, you will get a proper system behavior for the
userspace example.

Ich kenn RTAI und RT Preempt zu wenig, aber sollte RT Preempt nicht genau diese Probleme lösen?

mfg, Wolfgang

PS: Und bitte beschreib das "Rundherum" genauer. Warum RTAI? Was soll das Ganze am Ende machen?

--
Hex, Bugs and Rock 'n Roll

 

Hallo Wolfgang,

Zitat:
Was ist das für ein Bus? Und ist für dich die duchschnittliche "Performance" (Average-Case ) oder die schlechtest mögliche "Performance" (Soft/Hard-Realtime) interessant?

Dieser "Bus" heißt EtherCAT. Das System soll am Ende hart-echtzeit-fähig sein.

Zitat:

*) Du brauchst irgendeine Art von Echtzeit-Scheduler, der dir diese Zeiten garantiert. Vorher ist es unwichtig, ob dein Task im User- oder Kernelspace läuft.
*) Wenn auf externe Ereignisse reagiert werden muss (mit geringer Latenz), darf sich das System nicht beliebig lang in "nicht unterbrechbaren" Zuständen befinden.

Ja das kommt ja auch noch hinzu. Daran habe ich beim ersten Post nicht gedacht. Um es genauer zu machen.
Ich verwende den EtherLab Master von der Ingenieurgemeinschaft IgH. Für den Echtzeit-Scheduler hatte ich zu Beginn des Projekts auf dem System
RTAI installiert. Zunächst war das Ziel, das Ganze überhaupt zum Laufen zu bekommen.

Zitat:
Ich kenn RTAI und RT Preempt zu wenig, aber sollte RT Preempt nicht genau diese Probleme lösen?

Dieses RT Preempt ist ja sozusagen, harte-Echtzeit im UserSpace auf Kosten der maximal erreichbaren Zykluszeit.
RTAI bietet ebenfalls solch eine Lösung. Diese ist aber nicht mit dem Master kompatibel.
Damit habe ich noch keine Erfahrung gesammelt. Aber andere Nutzer des Etherlab Masters berichteten in Mailinglisten, dass sie mit
RT Preempt Zykluszeiten von bis zu 140 µs erreicht haben. Ich kann noch nicht sagen, ob dies für das System ausreicht, da neben dem regulären Busverkehr auf der Leitung noch Daten von einer Ifrarotkamera gesendet werden sollen.

Es ist also abzuschätzen, wie das Verhältnis von Aufwand des Programmierens und Aneignung der benötigten Kenntnisse zur kürzeren Zykluszeit ist.

Zitat:
Und bitte beschreib das "Rundherum" genauer. Warum RTAI? Was soll das Ganze am Ende machen?

RTAI deswegen, weil es vom Etherlab Master unterstützt und Beispielcode bereitgestellt wird.
Das ist alles bei etherlab.org frei verfügbar. Der Master läuft auf einem Linuxsystem und soll die gesammelten Daten der angeschlossenen Hardware an ein Regelsystem weitergeben. Und neu erhaltene Daten wiederum an die Hardware zurücksenden.

Und je schneller die Daten vom Regelsystem zur Hardware und zurück gelangen, desto besser.


Gruß
Juri