Übertragung über virt. COM Port langsam

Welche Sprache/ Bibliothek wird verwendet?

Werden die Befehle zeichenweise gesendet?
Sinnvoll ist blockweise Übertragung (Win32Api: WriteFile(), evtl. 
OVERLAPPED)

Hallo,
Danke für die Antworten erstmal.

Welche Lib genutzt wird kann ich nicht sagen, ich habe die Anwendug 
bereits fertig erhalten und hab auch keinen Quellcode dazu.

Werd mal der Reihe nach eure Vorschläge abarbeiten :-)

Mich wunderts halt nur, dass HTerm das ganze komplett auf einmal raus 
schicken kann, die Anwendung aber nicht...

Viele Grüße,
Karlo

Rumspielen mit den Werten des Buffers oder deaktivieren des Buffers 
ändert leider garnichts am Timing. Es ist kein Unterschied zu erkennen, 
sowohl bei dem Adapter als auch beim USB Dongle.

Hat noch jemand ne Idee wie sich die Anwendung bewegen lässt, sich so 
wie HTerm zu verhalten?

Viele Grüße,
Karlo

Wie bereits vermutet, wird die Anwendung die Befehle als einzelne 
Schreibzugriffe auf dem Port ausgeben.
Ohne Zugriff auf den Entwickler/ Quelltext könntest Du nur eine 
Adapter-Anwendung schreiben, die über einen virtuellen Com-Port (z.B. 
http://com0com.sourceforge.net/) die Daten eines kpl. Befehls einliest 
und dann sinnvoll über den gewünschten Port ausgibt.
Daß es bei sinnvoller Ausgabetechnik funktioniert, hast Du ja mit hterm 
getestet.

Hallo Karlo,

das liegt wohl an Deinem Treiber.

Bei einem virtuellen COM-Port versucht man ja eine möglichst hohe 
Übertragungsrate zu erreichen. Das aber ist nur möglich, wenn volle 
Pakete (entsprechend Deiner Endpunkt-Puffer) versendet werden.

Angenommen Deine Endpunkte sind 64 Byte groß, dann muss der PC Treiber 
immer auf 64 Byte warten, um sicherzustellen, dass er auch alles 
entgegennimmt (ReadFile(a,b,c,64) o.ä.).
Wenn Deine Anwendung also nur 10 Bytes versendet, dann wartet der 
Treiber theoretisch ewig, was aber dadurch vermieden wird, indem nach 
z.B. 10 ms die Daten vom Treiber weitergegeben werden - und zwar egal 
wieviele es sind.

Man könnte den Treiber auch so erstellen, dass er die Daten Byte-weise 
entgegen nimmt (ReadFile(a,b,c,1)). Was aber eher selten passiert, denn 
dann hat man das Problem, dass die ganze Geschichte wesentlich 
verlangsamt wird. Darum nutzen viele Treiber die Lösung mit vollem 
Puffer (64 Byte) und dem Timeout.

Gruß Potter

Das heißt, die Anwendung wird (wahrscheinlich) nicht einen 11 Byte 
langen Frame an den Treiber weiterreichen sondern immer nur 1 Byte, d.h. 
der "Senden" Befehl wird 11 mal ausgeführt?

Dann hab ich wohl wirklich ohne Quelltext keinen Einfluss auf das 
Verhalten...

Die Lösung mit dem com0com hört sich gut an, wär aber ein wenig 
Overkill. So schlimm ist das mit dem Timing auch nicht, sind eher so 
Feinheiten (die sich aber bekanntlich aufsummieren können :-)).

Ich habe mal den Support angeschrieben, falls noch jemanden was 
einfällt, gerne her damit :-)

Viele Grüße,
Karlo