Rtai?

[7.e.Q]

Hi Leute,

wer hat hier schonmal mit RTAI gearbeitet? Bräuchte Unterstützung... :confused: Details später. Will erstmal wissen, ob's hier überhaupt jemanden gibt, der sich damit auskennt, bevor ich wieder einen Roman umsonst schreibe. ;)

Gruß,
Hendrik

[7.e.Q]

Also gut, ich stelle mal eine erste Frage:

Ich richte mir einen RT-Timer ein, der Code sieht in etwa so aus:



void dev_schedule_thread_func()
{
rt_printk("REAL TIME TIMER!\n"); // Kommt nur einmal raus
}

void init_ists_dev()
{
int bg, res;
char memvalid;
char hwtype[16];
char fwtype[12];

init_waitqueue_head(&dev_wq_term);

printk("Init ISTS devices\n");

LastMsgCode = 0;
strcpy(LastMsgTxt,"");

if (register_chrdev(IDA_MAJOR, "ists", &DevFops) ==0) {
if(devfs_mk_cdev( MKDEV(IDA_MAJOR,0), S_IFCHR | S_IRUGO | S_IWUGO, "ists"))
{
printk(KERN_ERR "Anlegen von /dev/ists fehlgeschlagen\n");
return;
}
}

rt_printk("INITIALIZING RT_TIMER\n");

rtf_create(DEBUG_FIFO, 16000);
rt_task_init(&dev_schedule_thread,
dev_schedule_thread_func,
0,
3000,
0,
use_fpu,
0
);

rt_set_runnable_on_cpus(
&dev_schedule_thread,
RUN_ON_CPUS
);

rt_set_oneshot_mode(); // MARKE 1

rt_assign_irq_to_cpu(TIMER_8254_IRQ, TIMER_TO_CPU);

int timer_val = 1;
period_counts = start_rt_timer( nano2count(timer_val * 100000000) ); // start_rt_timer( nano2count(timer_val * 1000000000) );
expected = rt_get_time() + (300 * period_counts);

rt_printk("Period Count = %li\n",period_counts);
rt_printk("Expected = %li\n",expected);

rt_task_make_periodic(&dev_schedule_thread, expected, period_counts);
}



vorher deklarierte und initialisierte Variablen:

use_fpu = 0
TIMER_TO_CPU = 3 (#define)
DEBUG_FIFO = 3 (#define)
RUNNABLE_ON_CPUS = 3 (#define)
RUN_ON_CPUS = (num_online_cpus() > 1 ? RUNNABLE_ON_CPUS : 1) (#define)



Merkwürdig an der Sache finde ich, daß egal, was ich an MARKE 1 hinschreibe (rt_set_oneshot_mode oder rt_set_periodic_mode), die Timer-Funktion (der Task, dev_schedule_thread) nur ein einziges Mal aufgerufen wird. Ich möchte, daß dieser Task wiederholt in einem bestimmten Intervall aufgerufen wird, immer und immer wieder, solange der Treiber läuft. Wie geht das?

Gruß,
Hendrik

[7.e.Q]

Ein Testmodul bekommt ihr per svn dort (ist für Kernel 2.6):

svn://7eq.ath.cx/RTAI



Ich brauche eine Funktion, die per RTAI Timer periodisch immer und immer wieder aufgerufen wird. Wie vorgehen? :confused:

[BlauerBlitz]

Hallo Hendrik!

Folgendes ist mir (ohne alles ganz genau durchzusehen) aufgefallen:

Zum periodischen Task: Du darfst den Task nicht beenden, d.h. du darfst die Funktion dev_schedule_thread_func() nicht so stehen lassen, dass sie einfach durchlaufen wird! :cool:



void dev_schedule_thread_func()
{
for( ; ; )
{
rt_printk("REAL TIME TIMER!\n");

rt_task_wait_period( ); // Warten bis zu nächsten Periode
}
}


Auch der ursprüngliche Task sollte nicht verlassen werden, da dies eine Beendigung des Programms zu Folgen hätte.

Programmierst du auf einem normalen PC bzw. x86-Architektur?
Dann solltest Du vielleicht überlegen, die User-Space-Variante von RTAI, nämlich "LXRT" zu verwenden, welche wie gesagt, im User-Space läuft und daher den Rechner nicht bei jedem Programm-Absturz in's Verderben reißt! :rolleyes:

Ciao
Werner

[7.e.Q]

Hmm, okay, also das ist ja schon mal eine gute Antwort. Ja, ich entwickle auf Standard x86 Systemen für kompatible VME Baugruppen.

Es geht letztendlich darum, einen Treiber, den wir entwickeln und warten, insoweit echtzeitfähig zu machen, daß ein auf dem Interface ausgeführter System Call select() auch exakt nach dem gewünschten maximalen Timeout zurück kommt, wenn keine Daten anstehen. Bisher ist das nicht der Fall, da Linux von Haus aus ja nicht echtzeitfähig ist. Es kann also durchaus passieren (und das tut es bei uns auch häufiger), daß der Systemcall select() statt mit den übergebenen 5ms Timeout tatsächlich mal 100ms benötigt. Und da unsere Software-Timer auf diesem select() basieren (was ich leider so ohne weiteres nicht ändern kann), ist es unabdingbar, daß dieses select() möglichst exakt zum gewünschten Zeitpunkt zurück kehrt.

Das Modul, das ich jetzt hier mal eben schnell gecoded hab für den Test, ist auch nur eben dafür gedacht gewesen. Um zu demonstrieren, was ich meine und was ich falsch mache. Der fertige Treiber endet nachher selbstverständlich nicht irgendwo.

Im User-Space programmieren ist aus den genannten Gründen leider nicht machbar.

edit: okay, dein Tipp mit der Schleife hat erstmal geholfen. Ist es nicht möglich, mehrere Timer einzurichten, die in unterschiedlichen Intervallen verschiedene Funktionen aufrufen?

[BlauerBlitz]

Hmm, okay, also das ist ja schon mal eine gute Antwort. Ja, ich entwickle auf Standard x86 Systemen für kompatible VME Baugruppen.



VMEbus ist gut!




[...]

Im User-Space programmieren ist aus den genannten Gründen leider nicht machbar.

edit: okay, dein Tipp mit der Schleife hat erstmal geholfen. Ist es nicht möglich, mehrere Timer einzurichten, die in unterschiedlichen Intervallen verschiedene Funktionen aufrufen?


Du kannst natürlich mehrere Tasks mit unterschiedlicher Frequenz generieren. Über rt_task_make_periodic() kannst du dazu einfach jeweils unterschiedliche Periodendauer vorgeben.

Wenn du Timeoutfunktionen benötigst, so solltest du dir vielleicht das RTAI-Modul "Bits" ansehen. Dies beinhaltet ein Eventhandling, wie man es von anderen Echtzeitbetriebssystemen kennt - Senden und Empfangen von Events (hier Bits genannt), auch mit Timeout-Erkennung. Dazu muss einmal eine Bit(=Event)-Box initialisiert werden, anschließend kann mit den diversen Funktionen auf ein Event gewartet werden, auf Wunsch auch mit Timeout. Von der zeitlichen Auflösung/Genauigkeit hättest du hier sicher keine Probleme ... :rolleyes:

Mit anderen Worten: Wenn keine Daten ankommen wird das erwartete Bit nicht gesetzt => Timeout; wenn Daten ankommen setzt der Empfangs-Task/Interrupt das entsprechende Event => Auswertung der Daten.

MfG
Werner

[7.e.Q]

Okay... Zwischenfrage: was passiert, wenn ich einen Task einrichte, der beispielsweise periodisch auf 10ms eingerichtet ist, dessen Funktion aber länger als 10ms braucht?

edit: gut, stell ich die Frage anders. Ich will ein Polling in meinem Treiber realisieren, der passive VME Baugruppen ständig auf Vorhandensein neuer Daten abfragt, um eine eventuelle select() SystemCall Anfrage eines User-Programms entsprechend bedienen zu können. Diese Polling-Funktion soll geöffnete Baugruppen alle 10ms abfragen. Vorher war das mit einem normalen Kernel-Timer gemacht, der alle 10ms eine Funktion aufrief, die in einer for-Schleife alle verfügbaren Baugruppen-Slots abgefragt hat (ob dort nun eine Baugruppe steckte oder nicht, war egal). Mehrere Fragen habe ich nun:
- Was passiert, wenn ein Polling-Durchlauf mal länger als 10ms braucht?
- Sollte man sowas überhaupt mit RT-Tasks realisieren?
- Gibt es Alternativen?
- Sollte man, wie vorher, alle Baugruppen in einer Schleife in einem Task abfragen, oder jeder Baugruppe einen eigenen Task verpassen?
- darf man wake_up_interruptible() in einem RT-Task machen???


Erstmal... kommen sicherlich noch mehr Fragen.

Danke!

Gruß, Hendrik

[BlauerBlitz]

- Was passiert, wenn ein Polling-Durchlauf mal länger als 10ms braucht?

Dann kommt der Task natürlich erst verzögert zum Laufen; wenn der Polling-Durchlauf länger als 20 ms dauert geht eine "Abtastung" verloren.



- Sollte man sowas überhaupt mit RT-Tasks realisieren?

10 ms sind bei Echtzeitverarbeitungen naürlich schon eine kleine Ewigkeit, aber prinzipiell spricht eigentlich nicht viel dagegen.



- Gibt es Alternativen?

Die Bearbeitung verkürzen; eventuell die Daten schnell übernehmen und dann in einem niederprioren Task weiterbearbeiten (falls diese Bearbeitung länger dauert).



- Sollte man, wie vorher, alle Baugruppen in einer Schleife in einem Task abfragen, oder jeder Baugruppe einen eigenen Task verpassen?

Hängt davon ab, ob zeitlich gesehen Schwankungen bei der "Abtastung" durch unterschiedlich lange/wechselnde Bearbeitungen erlaubt sind oder nicht.



- darf man wake_up_interruptible() in einem RT-Task machen???

Ich denke nicht, Betriebssystemaufrufe sind in RTAI-Kernel-Routinen mit Vorsicht zu genießen. In LXRT sind in Softrealtime-Tasks solche Aufrufe prinzipiell möglich. Kann es für diesen Aufruf nicht sicher sagen.


Mfg
Werner

[7.e.Q]

Hmm... also ich habe mich mal umgesehen nach wake_up_interruptible innerhalb von RT Tasks... es ist definitiv nicht erlaubt. Ärgerlich! Das führt dazu, daß die Änderungen bezüglich RT innerhalb unseres VME Treibers doch sehr gravierend ausfallen würden. Ich werde mich daran machen, wenn einmal Zeit ist.

Um das Problem unserer Software Timer zu beheben, werde ich mich aber jetzt mal mit LXRT beschäftigen. Dazu habe ich dann auch sicher noch einige Fragen. Eine Verständnisfrage wäre zum Beispiel: habe ich das richtig verstanden, daß LXRT (basierend auf RTAI) im Prinzip die gleiche Funktionalität bietet, wie RTAI, nur daß es eben auf User-Level arbeitet, sprich, kann ich damit RT Tasks in ganz normalen Linux-Anwendungen verwenden? Ist das korrekt so?


@BlauerBlitz: ich danke dir recht herzlich für deine Unterstützung, werde sie aber wohl noch weiter brauchen. :)

[7.e.Q]

Hah, eine riesen große Frage hätte ich da... wir übersetzen unsere Software unter Windows mit dem Cygwin (crosscompiler) für die Linux VME-Baugruppen. Ist es überhaupt möglich, damit Software mit RTAI/LXRT Unterstützung zu übersetzen?

[BlauerBlitz]

Um das Problem unserer Software Timer zu beheben, werde ich mich aber jetzt mal mit LXRT beschäftigen. Dazu habe ich dann auch sicher noch einige Fragen. Eine Verständnisfrage wäre zum Beispiel: habe ich das richtig verstanden, daß LXRT (basierend auf RTAI) im Prinzip die gleiche Funktionalität bietet, wie RTAI, nur daß es eben auf User-Level arbeitet, sprich, kann ich damit RT Tasks in ganz normalen Linux-Anwendungen verwenden? Ist das korrekt so?


Jein. Also: Ja es läuft auf User-Level. Aber: Es ist bei LXRT so, dass du zuerst für jeden LXRT-Task einen Posix-Thread erzeugen musst (über "pthread_create()", und in diesem Thread (gleich zu Beginn) über "rt_task_init_schmod()" (sofort einen LXRT-Task daraus machst. Als Rückgabe erhälst du einen Pointer auf eine Task-Struktur, die für weitere Handlungen mit diesem Task notwendig sind. Dieser neu kreierte Task läuft als Soft-Realtime-Task, was für deine Anforderungen genügen müsste. Der Vorteil von Soft-Realtime-Tasks ist, dass du Aufrufe verwenden kannst, die in Hard-Realtime-Tasks nicht erlaubt sind.
Sinnvoll ist es, zwischen den verschiedenen Tasks die diversen Kommunikationsmöglichkeiten von RTAI/LXRT zu verwenden.

Solltest du wirklich Hard-Realtime benötigen, so kanns du dies über den Aufrufr "rt_make_hard_real_time( )" erreichen. Dies ist auch nur für kurze Abschnitte möglich ("rt_make_soft_real_time( )" beendet dies wieder).

Von der Priorität ist es so, dass Hard-Realtime-Tasks die höchste Priorität haben, dann kommen die Soft-Realtime-Tasks, dann die Posix-Threads und die Linux-Prozesse.

Ein kleiner Unterschied bei den Funktionsaufrufen besteht zwischen RTAI und LXRT noch darin, dass bei der Initialisierung von LXRT-Objekten als erster Parameter eine Id (über "nam2num( "NAME" aus einem bis zu 6 Zeichen langen wählbaren Namen gewonnen) übergeben wird. Zurück kommt ein Pointer auf eine (aus dem Userspace nicht direkt zugreifbare Objekt-Struktur), welche bei allen anderen Funktionsaufrufen auf dieses Objekt als erster Parameter übergeben werden muss.



@BlauerBlitz: ich danke dir recht herzlich für deine Unterstützung, werde sie aber wohl noch weiter brauchen. :)

Gern geschehen!
Du kannst übrigens auf der Mailing-Liste von RTAI (auf Englisch) ebenfalls Hilfe bekommen:

https://web.aero.polimi.it/modules.php?name=Content&pa=showpage&pid=3

Du musst dazu diese Liste abonnieren. Bei Fragen solltest du immer angeben, ob sie sich auf LXRT oder (Kernel-)RTAI beziehen.

Unter http://rtai.dk findest du ein Wiki über RTAI/LXRT.
Manche Punkte, wie z.B. http://rtai.dk/cgi-bin/gratiswiki.pl?Start_With_LXRT könnten hilfreich sein.

Auch die Beispiele, die sich irgendwo im "showroom" am RTAI-CVS-Server befinden, wären vielleich nicht uninteressant für dich.

Ciao
Werner

[BlauerBlitz]

Hah, eine riesen große Frage hätte ich da... wir übersetzen unsere Software unter Windows mit dem Cygwin (crosscompiler) für die Linux VME-Baugruppen. Ist es überhaupt möglich, damit Software mit RTAI/LXRT Unterstützung zu übersetzen?

Ich habe damit leider keine Erfahrung, aber prinzipiell glaube ich, dass es funktionieren müsste. Zumindest ist meiner Meinung nach für LXRT gegenüber RTAI (im Kernelmodus) - falls du das hinbekommen hast - kein Unterschied zu erwarten. Von SYSGO z.B. gibt es das Entwicklungspaket ELinOS auch für Windows.

MfG
Werner

[7.e.Q]

Hmm... ich spielte gerade ein bisschen mit LXRT herum... mal messen, was für Timings ein normales select() Timeout so auf die Waage bringt. Aber irgendwie... ich weiß nicht. Also ich hab ja 5 Sekunden eingestellt, mein Zeitgefühl (und meine Stoppuhr) sagen mir auch, es seien 5 Sekunden. Aber das Progrämmchen meint, es seien was bei 7Mrd Nanosekunden (mit rt_get_time_ns()). Und DAS stimmt definitiv NICHT.

Vielleicht schaut sich das Programm mal jemand an:

svn://7eq.ath.cx/LXRT (ab und an mal off, aber ich versuche es online zu halten) (so, mein Subversion is wieder online, jetzt als Dienst, also immer wenn mein Compi @home läuft)

[BlauerBlitz]

Hmm... ich spielte gerade ein bisschen mit LXRT herum... mal messen, was für Timings ein normales select() Timeout so auf die Waage bringt. Aber irgendwie... ich weiß nicht. Also ich hab ja 5 Sekunden eingestellt, mein Zeitgefühl (und meine Stoppuhr) sagen mir auch, es seien 5 Sekunden. Aber das Progrämmchen meint, es seien was bei 7Mrd Nanosekunden (mit rt_get_time_ns()). Und DAS stimmt definitiv NICHT.

Vielleicht schaut sich das Programm mal jemand an:

svn://7eq.ath.cx/LXRT

Hm, ich komm da leider nicht dran (unser Firewall), aber wenn du vorher und nachher rt_get_time_ns() aufrufst, sollte eigentlich die Differenz passen. Eventuell stimmt aber die Kalibirierung nicht.

Zu Sicherheit: Hast du in der LXRT-Initialiserung diese Aufrufe stehen? Das mlockall hat natürlich nichts mit der Timer-Kalibrierung zu tun, aber ohne diesen Aufruf wird vom Linux ausgelagert -> keine Echtzeit möglich!



mlockall(MCL_CURRENT | MCL_FUTURE); /* Paging unterbinden */
rt_set_oneshot_mode(); /* Scheduler initialisieren */
start_rt_timer(0); /* Timer starten */


Falls dies passt: Versuch mal rt_get_time() vorher und nacher aufzurufen => Differenz in CPU-Ticks => rechne sie selbst über die dir bekannte CPU-Frequenz um.

Wenn der Prozessor mindestens ein Pentium ist, kannst du alternativ auch selbst so eine Funktion zum Auslesen der Prozessor-Ticks aus dem TSC-Register basteln. Mit dem normalen GCC funktioniert's so:



static inline unsigned long long TSCRead(void)
{
unsigned long long xHilf;

__asm__ volatile( "rdtsc" : "=A" (xHilf) );
return( xHilf );
}


Damit kannst du den aktuelle Tick-Stand als "unsigned long long" auslesen (vorher/nachher), die Differenz bilden und über die Prozessor-Frequenz in Nano-Sekunden umrechnen.

Es sollte sich aber zu rt_get_time() kein Unterschied ergeben!

Werner

[7.e.Q]

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()?

[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 ... :D


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...