Genaues Timing mit QNX [GELÖST]

Giovanni_R

Hallo,
ich schreibe ein Programm, welches Schrittmotoren über den Parallelport unter QNX steuern soll.
Die Ausgabefrequenz wird mit usleep() eingestellt. Und da ist ach schon das Problem: Da QNX ein Echtzeitbetriebssystem ist, läuft es mit einer festen Zykluszeit. Dachdem usleep() aufgerufen wird, bekommt der Thread erst beim nächsten Zyklus wieder Rechenzeit. Somit ist die Ausgabefrequenz duch die Zykluszeit des Programms beschränkt.

Ich habe schon die Zykluszeit auf 10 Mikrosekunden heruntergesetzt - kürzer geht nicht. Damit ergibt sich eine Frequenz von 50 kHz. Die nächst kleinere Frequenz ist aber 25 kHz, was einen gewaltigen Sprung darstellt. Die Auflösung beträgt also 10 Mikrosekunden. Wenn ich usleep(11) aufrufe schläft der Thread 20 Mikrosekunden.

Gibt es also eine möglichkeit (möglichst POSIX-Kompatibel) einen Thread schlafen zu legen und nach einer vorgegebenen Zeit (Auflösung im Nanosekundenbereich währe ideal) wieder aufzuwecken?

Danke im vorraus.

es gibt in posix die funktion nanosleep. vielleicht klappt es mir damit.

sothis_

ich weiß nicht ob's in QNX funktioniert, aber ggf. einen posix-signal basierten timer mit timer_create() erzeugen, welcher je nach architektur bis zu einer nanosekunde auflösung haben kann und entprechend einen spezifizierten signal-handler aufruft. in diesem kannst du ein flag setzen (in der regel vom typ sig_atomic_t) welches du in dem schlafenden thread prüfst, den thread aufweckst und das flag wieder auf 0 setzt.

Giovanni_R

Hallo Leute,
vielen dank für die Beiträge. Zunächstmal nanosleep() und timer_create() unterliegen ebenfalls dem Systemzyklus, wie ich leider Feststellen musste, daher lässt sich die Auflösung nicht weiter Steigern aber:

Bei meinen Recherchen bin ich auf die funktion nanospin() bzw. nanospin_ns() aus <time.h> gestoßen. Diese Funktionen lassen tatsächlich eine Auflösung von 1 Nanosekunde zu. Hierfür wird eine art do...while Schleife aufgerufen und die vergangene Zeit abgefragt - was natürlich zur vollen Auslastung des Prozessors führt. Da mehrere parallele Threads laufen müssen könnte das Probleme geben, aber bis jetzt, mit zwei Threads, läufts gut.