Timingprobleme mit virtuellen ComPorts

[messie]

Moin,

ich habe ein Geschwindigkeitsproblem mit der WINAPI beim Schreiben auf eine RS232. Ich benutzte bisher Cport, es gibt aber auch viele andere Komponenten, die auf der WINAPI basieren. Mein Problem liegt in der Wartezeit auf das event (Overlapped.hEvent), was das erfolgreiche Schreiben signalisiert. Bei einem nicht hardwaremäßig vorhandenen (virtuellen) Comport habe ich pro Sendevorgang eine Wartezeit von 1-2 Millisekunden. Wenn man also byteweise sendet, kommt man auf einen Datendurchsatz von ca. 1 kB/s, unabhängig von der Baudrate. Dies betrifft nur virtuelle Comports, mit eingebauten Geräten ist das kein Problem. Ich habe verschiedene USB- wie auch IP-Wandler ausprobiert, es gibt keine Unterschiede. Wen es interessiert, kann man auch schnell selbst ausprobieren: einfach von Hyperterminal eine Textdatei auf die Schnittstelle schreiben lassen, mal mit interner und mit virtueller Schnittstelle.

Hat jemand eine Idee, warum das so ist und ob man mit anderen Lösungen (nicht-API) sowas umgehen kann? Kann mit einer die Funktionsweise der virtuellen ComPorts erklären?

Danke, Ulfert

[hitzi]

Hallo Ulfert,

also ich komme mit eine virtuellen Bluetooth Comport auf 21-23kb/s (wobei das auch noch vom Kommunikationspartner abhängt - in meinem Fall ein Handy) und mit einem virtuellen IrDa Comport auf 7-8kb/s.

Getestet mit einem selbstgeschriebenen Programm und CPort.

[edit]Allerdings überprüfe ich das erfolgreiche Schreiben an den Comport nicht. Ich fange nur eventuelle Fehler mit try except ab.[/edit]

Gruss

[messie]

Hallo Thomas,

sendest Du denn byteweise? Ich hatte den Hyperterminal-Test auch mal mit ZModem gemacht, da paßte die Übertragungsrate auch. Scheint so, daß ZModem die Daten als Gesamtpaket schickt.
Vielleicht kannst Su mir ja mal einen Codeschnipsel von der Senderoutine zeigen.

Danke, Ulfert

[Robert Marquardt]

Das Problem ist das der virtuelle COM-Port ueber einen anderen realen Bus geht.
Wenn nur ein Zeichen geschrieben wird, so entsteht ein erheblicher Overhead an Transaktionen und schnell sind die Millisekunden verbraucht.
Die einfachste Loesung ist eine Pufferung, die nur mehrere Zeichen auf einmal schickt.

[messie]

Hallo Robert,

hast Du denn eine Ahnung, wieso das mit den internen Ports problemlos ist?

Grüße, Ulfert

[Robert Marquardt]

Weil dort der UART fuer Rs232 direkt vom Treiber angesprochen wird.
Bei USB ist das UART im USB-Geraet am anderen Ende vom Kabel.
USB-Transaktionen aka einmal Kommando an UART schreiben und Status zuruecklesen dauert nun mal seine Zeit.
Inbesondere weil USB als polled Bus oft nur einmal pro Millisekunde pollt, also die antwort gerne eine Millisekunde braucht.

[messie]

Wenn der Port wirklich so selten pollt, ist das Problem klar. Dann kann es auch eine ähnliche Ursache haben warum das mit dem IP-Wandler auch nicht hinhaut. Vielleicht gibt es ja auch gute und schlechte Treiber für virtuelle COM-Ports.
Das vereinfacht mein Problem jedenfalls nicht gerade...

Grüße, Ulfert

[Robert Marquardt]

Das ist halt das Problem mit so einem Bus. Bei USB sagt das Geraet an wie oft es gepollt werden will.
Der Datendurchsatz in jeweils eine Richtung ist trotzdem hoeher, aber abwechselnd kommen schnell Verzoegerungen zusammen.

Virtuelle COM-Port-Treiber sind das boeseste im USB-Bereich, besonders wenn der Treiber DOS-Boxen unterstuetzen soll.
Da sind so einige 16-bit-Probleme vorhanden.
Der praktisch einzige spezialist dafuer ist Walter Oney.
Schau mal im Forum von Usbman vorbei (http://www.usbman.com). Dort kann man dir hochwertige RS232-Adapter empfehlen.

[Selecta]

Ich weiss jetzt nicht für was du es brauchst, aber die Lösungen von http://www.ftdichip.com/ sind wirklich gut.
Ich setze selbst den FTBM245 ein.

und das Hyperterminal ist sehr langsam, da es immer nur 1 zeichen schickt.

http://www.sysinternals.com/ntw2k/fr.../portmon.shtml
Mit dem Portmonitor kannst du die seriellen schnittstellen überwachen.

[messie]

>Virtuelle COM-Port-Treiber sind das boeseste im USB-Bereich

Hallo,

sieht so aus, als müßte ich den USB-Treiber als "worst case" zur Basis machen. Ich weiß nicht, mit welchen Schnittstelle die Software später eingesetzt wird (ob intern, USB, IP). Da muß ich wohl mit dem Protokolloverhead sparsam sein...

Danke, Ulfert