www.mikrocontroller.net

Forum: PC-Programmierung schneller zugriff auf serielle schnittstelle


Autor: mussa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
weiß hier jemand ob es unter LINUX eine schnellere möglichkeit gibt auf 
die serielle Schnittstelle zu schreiben als die write() Funktion? 
Hierbei braucht mein  Rechner ca. 20µsec vom Befehlsaufruf bis wirklich 
Daten geschrieben werden. Liegt natürlich auch immer an der 
Rechnerperformance, aber ich bräuchte das schneller, so ca.5µsec oder 
weniger.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Umgehe die Dateisystemarchitektur, komuniziere direkt mit dem 
Devicetreiber oder packe Deine Applikation in einen Devicetreiber. 
Verwende ein Echtzeit-OS, kein Linux.

Könnte es sein, daß Deine Timing-Vorstellungen ein bisschen 
realitätsfremd sind? 20µsec sind -bei 9600- gerade mal zwei Bitzeiten.

Autor: mussa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Dann verwendest Du aber nicht die serielle Schnittstelle im PC, 
denn die kann maximal 115200 Baud.

Was für eine Schnittstellenhardware verwendest Du denn? Könnte es sein, 
daß die einen Sende-FIFO aufweist?

Was für eine Anwendung ist das, die einerseits eine sehr hohe Datenrate 
und andererseits extrem kurze Reaktionszeiten benötigt?

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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-...

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

Autor: mussa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: *.* (Gast)
Datum:

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

Denk dir ein besseres Protokoll aus...

Autor: mussa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schonmal rtlinux angeschaut

Autor: Ulrich (Gast)
Datum:

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

Autor: mussa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.