Rtai?

[BlauerBlitz]

Versuch es mal über http://7eq.ath.cx/repos

Mit rt_get_time() und count2nano() funktioniert es. Aber warum denn nicht mit rt_get_time_ns()?

So kann ich auf die Dateien zugreifen!

Schaut prinzipiell nicht so schlecht aus. Dass die Zeit nicht stimmt muss an der vom Betriebssystem gemessenen CPU-Frequenz liegen.

Wenn das "select", das du aufrufst, das normale Linux-Select ist, so dürfte der vorhergehende "rt_make_hard_real_time()"-Aufruf sinnlos sein, da das LXRT in den Soft-Realtime-Modus zurückwechselt, wenn ein Linux-Betriebssystem-Aufruf auftritt. Auch glaube ich, dass man prinzipiell diesen Aufruf erst nach "rt_task_init_schmod()" einbauen sollte.

Im Moment fällt mir leider sonst nicht viel ein ...

Werner

[7.e.Q]

Ist es, das Linux-select(). Gibt es da eventuell von LXRT irgendeine gleichwertige Alternative, die ein hartes Timeout bietet? Oder müsste ich sowas noch selbst implementieren? Geht halt darum, daß wir select() für unsere Software Timer nutzen und der Umbau-Aufwand natürlich möglichst gering sein sollte.

[BlauerBlitz]

Ist es, das Linux-select(). Gibt es da eventuell von LXRT irgendeine gleichwertige Alternative, die ein hartes Timeout bietet? Oder müsste ich sowas noch selbst implementieren? Geht halt darum, daß wir select() für unsere Software Timer nutzen und der Umbau-Aufwand natürlich möglichst gering sein sollte.

Hast du meinen Beitrag vom 13-10-2005, 08:01gelesen?
Wie dort geschrieben, würden sich meiner Meinung nach z.B. Bits anbieten.
Aber auch andere LXRT-Objekte haben eine Timeout-Überwachung, die natürlich eine um Klassen bessere Genauigkeit hat. Vielleicht noch besser als Bits sind evetuell Mailboxes geeignet. Hier hättest du die Möglichkeit, auch die Daten damit gleich mit zu übertragen. Sollte eine Verbindung zwischen einem Standard-Linux-Prozess und einem Echtzeit-Task notwendig sein, so wäre auch die Verwendung eines RTAI/LXRT-FIFOs eine gute Lösung. Auch dieses bietet eine Timeout-Funktion und kann zur Nutzdaten-Übertragung verwendet werden.

Zu rt_get_time_ns():
Könntest du mal kontrollieren, was in /proc/rtai/scheduler deines Zielsystems steht? Hier gibt es einen Eintrag "Calibrated CPU Frequency". Vergleich mal diesen Wert mit deiner tatsächlichen CPU-Frequenz. Im Normalfall sollten sie übereinstimmen; durch z.B. irgendwelche Throttle-Aktionen der CPU (sofern diese so etwas unterstützt) wäre ein Fehler möglich. Welche CPU verwendest du eigentlich?

Ciao
Werner

[7.e.Q]

Irgendwie scheint RTAI unseren Kernel vermurkst zu haben. Seitdem der Patch da drin ist, funktioniert unser DPN (der VME Netz-Interface Treiber) nicht mehr. Stürzt andauernd ab...

Eventuell hat ja jemand Bock, sich den DPN mal anzuschauen. Achtung! Kaum Dokumentation und wirklich grauenhaft programmiert. Stammt nicht aus meiner Feder!

Zur Erklärung: Die Hardware dahinter ist ein Dual Port RAM, also ein Shared Memory unter verschiedenen Baugruppen am VME Bus (Tundra Universe II Chipsatz). Jede Baugruppe hat ihren eigenen Speicherbereich und malt fröhlich im Speicher der anderen Baugruppen rum. Desweiteren gibt es zwei Typen von Baugruppen: aktive und passive. Aktive Baugruppen arbeiten mit Hardware Interrupts, um der jeweils anderen anstehende Daten zu signalisieren, also das Auslesen anzustoßen. Passive Baugruppen werden von den aktiven regelmäßig gepollt, weil sie selbst keinen Interrupt auslösen können. Die Datenpuffer sind Ringpuffer. Es wird also beim Pollen immer der Lese- mit dem Schreibzeiger verglichen. Sind diese ungleich, stehen Daten an.

Diesem Treiber gilt es im Laufe der Weiterentwicklung Echtzeitfähigkeit zu geben. Also dafür zu sorgen, daß das Polling immer im exakt gleichen Takt aufgerufen wird und bei jedem Aufruf eine exakt festgelegte Zeit in Anspruch nimmt.

@BlauerBlitz: deinen Beitrag zum Thema Bits habe ich gelesen, werde mir das mal anschauen. Aber momentan hab ich leider wieder andere Sachen auf den Schreibtisch gepackt bekommen, welche meine Prioritäten wieder durcheinanderwürfeln. Vielleicht hast du ja Lust, mal über den Treiber zu schauen und eventuell ein paar Tips zur Verbesserung zu geben... Danke!

[BlauerBlitz]

Irgendwie scheint RTAI unseren Kernel vermurkst zu haben. Seitdem der Patch da drin ist, funktioniert unser DPN (der VME Netz-Interface Treiber) nicht mehr. Stürzt andauernd ab...

Eventuell hat ja jemand Bock, sich den DPN mal anzuschauen. Achtung! Kaum Dokumentation und wirklich grauenhaft programmiert. Stammt nicht aus meiner Feder!

Zur Erklärung: Die Hardware dahinter ist ein Dual Port RAM, also ein Shared Memory unter verschiedenen Baugruppen am VME Bus (Tundra Universe II Chipsatz). Jede Baugruppe hat ihren eigenen Speicherbereich und malt fröhlich im Speicher der anderen Baugruppen rum. Desweiteren gibt es zwei Typen von Baugruppen: aktive und passive. Aktive Baugruppen arbeiten mit Hardware Interrupts, um der jeweils anderen anstehende Daten zu signalisieren, also das Auslesen anzustoßen. Passive Baugruppen werden von den aktiven regelmäßig gepollt, weil sie selbst keinen Interrupt auslösen können. Die Datenpuffer sind Ringpuffer. Es wird also beim Pollen immer der Lese- mit dem Schreibzeiger verglichen. Sind diese ungleich, stehen Daten an.

Diesem Treiber gilt es im Laufe der Weiterentwicklung Echtzeitfähigkeit zu geben. Also dafür zu sorgen, daß das Polling immer im exakt gleichen Takt aufgerufen wird und bei jedem Aufruf eine exakt festgelegte Zeit in Anspruch nimmt.

Dass das Polling immer im exakt gleichen Tak vorgenommen wird, kannst du ja schon durch einen periodischen Task (hoher Priorität) erreichen. Was ich nicht ganz verstehe, ist die "festgelegte Zeit", die jeder Aufruf in Anspruch nehmen sollte. Die Abfrage der beiden Pointer auf Gleichheit geht ja recht rasch vor sich. Wenn jetzt die zeitliche Verschiebung (durch eine notwendige Daten-Behandlungs-Aktion benötigte Zeit) stört, wäre vielleicht ein höherfrequenter Task sinnvoll (bei jedem Task-Aufruf wird ein anderes Pointerpaar getestet).

@BlauerBlitz: deinen Beitrag zum Thema Bits habe ich gelesen, werde mir das mal anschauen. Aber momentan hab ich leider wieder andere Sachen auf den Schreibtisch gepackt bekommen, welche meine Prioritäten wieder durcheinanderwürfeln.

Komisch, so etwas kenne ich überhaupt nicht ...

Vielleicht hast du ja Lust, mal über den Treiber zu schauen und eventuell ein paar Tips zur Verbesserung zu geben... Danke!

Ich kann nichts versprechen - vielleicht einen kurzen Blick ... Finde ich den Code oder Ausschnitte davon irgendwo?
Bitte vergiss aber nicht zu überlegen, ob dein Chef so eine Veröffentlichung schätzt!

Werner

[7.e.Q]

Achso sorry, hab den Link vergessen: http://7eq.ath.cx/repos/DPN

Mein Chef hat nix dagegen zu haben, da der Treiber unter der GPL veröffentlicht wird. Hat er auch nicht, hab da schon mit ihm drüber gesprochen. Mit dem Treiber allein kann wohl eh niemand wirklich was anfangen. Für Leute, die ebenfalls VME Baugruppen einsetzen mit einem Linux 2.6 drauf wäre das eventuell was, weil's eben ein Netzwerk-Interface auf den VME Bus abbildet (allerdings beschränkt auf den IP Bereich 10.1.1.100 - 10.1.1.116).

Naja, also wichtig ist halt erstmal, daß der Treiber mal "Entkinderkrankheitet" wird. Und da bin ich momentan noch ein bisschen mit überfordert. Vielleicht sind da ja ein paar Hinkefüße im Code, die du oder jemand anderes von vornherein anmerken kann. Ohne jetzt gleich auf RTAI-Kompatibilität zu schielen, sondern erstmal pauschal. Frei nach dem Motto, das hättest so und so besser machen können...