schneller zugriff auf serielle schnittstelle

Danke für den Tipp!
Nein, meine vorstellungen sind realistisch da ich mit 2MBaud arbeite und 
ein komplettes Byte entsprechend ca.5µs (incl.Start Stop) braucht.

>Nein, meine vorstellungen sind realistisch da ich mit 2MBaud arbeite und
>ein komplettes Byte entsprechend ca.5µs (incl.Start Stop) braucht.
Wow, was für eine Milchmädchenrechnung
Welche Zeit meinst du, bis das erste Byte gesendet wird zwischen den 
Zeichen
Du beschwerst dich über 20us???
Linux kann auch Taskwechsel JEDERZEIT machen, das gibt dann Zeiten die 
noch größer sind wenn deine Anwendung erstmal kurz weg vom Fenster ist.
Solltest du mit einem USB-Seriellwandler arbeiten, dann ist der Begriff 
Milchmädchenrechnung noch sehr geschönt, siehe:
http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

Es würde mich schon interessieren welches Konzept auf einer normalen? 
seriellen Schnittstelle eine Genauigkeit von <5us benötigt.

Ich arbeite mit einem Embedded ARM System.
Was heißt hier Milchmädchenrechnung?!
Erstens kann ich rechnen und zweitens auch ein Scope bedienen....
Die Anwendung sieht so aus, daß ich einen IO Pin setze (dauert ca.5µsec) 
und dann die Funktion write() aufrufe. Vom setzen des Pins bis Daten 
kommen sind es halt dann 20µsec.Ich schreibe permanent Daten (etwa 5-7 
Bytes) an verschiedene Adressen und lese dann eine ähnliche anzahl 
zurück. Und dann gleich die nächste Adresse und so weiter...
So ein Datentranfer dauert normalerwise dann etwa 50 -70µsec. Da sind 
20µsec doch schon ne ganze menge!

Wer garantiert dir das zwischen dem setzen des IO-Pins(oder eigentlich 
dem was du vorher machst)und dem write von Linux kein Task 
zwischenzeitlich ausgeführt wird?
Wenn das write es erstmal dem Devicetreiber der Schnittstelle übergeben 
hat, dann kann gepuffert im Interruptbetrieb? mit FIFO? übertragen 
werden, das dürfte recht gut gehen und einen sehr geringe 
Interbyte-latenzzeit haben.
Was für Interbytezeiten werden erreicht? Laut deinen Angaben 50-70us für 
5 bis 7 Byte Interbytezeit=0. Also schreibe immer gepuffert. Solange der 
Puffer nicht abreißt gibt es keine 20us verzögerung.
Die Frage bleibt:
Welches Konzept erfordert das <5us losgesendet wird? Diese Anforderung 
an eine serielle Schnittstelle mit Linux als Betriebssystem halte ich 
für unrealistisch.

> daß ich einen IO Pin setze (dauert ca.5µsec)
und dann die Funktion write() aufrufe.

Denk dir ein besseres Protokoll aus...

Na, ich glaub ich muß wirklich den Kernel umschreiben. Die Treiber und 
Interruptroutinen der seriellen Schnittstelle sind ja schon mit den 
ganzen if´s und while´s sehr zeitaufwendig. Sind ja auch so geschrieben, 
daß sie möglichst vielseitig verwendbar sind. Ein weiteres Problem ist 
allerding, daß alle UART´s die selben Treiber und Interrupts benutzen...
Wie ist das eigentlich mit dem realtime LINUX Kernel. Hat der auf dem 
Gebiet irgendwelche Vorteile?

schonmal rtlinux angeschaut

meiner Meinung nach kein Problem. Selbst Windows XP kann man komplett 
gaaaanz hart echtzeitfähig machen.

Habe jetzt RTAI entdeckt. Das scheint ansich ganz brauchbar zu sein.
Wird quasie vor den eigentlichen Kernel gebaut. Allerdings hab ich noch 
keinen arm-patch für den aktuellen Linux Kernel gefunden nur für 386 
bzw. arm für version 2.4.irgendwas! weiß jemand ob es diesen patch als 
"freeware" überhaupt gibt?