FT232BM und ähnl. können nicht einmal Half-Duplex richtig?

Nachtrag: Man sieht diesen Bug mit jedem Terminal-Programm (Hyperterm,
minicom, ...), wenn man den Ausgang an den Eingang anschließt (Pin 3 an
Pin 2): Beim seriellen Port wird alles eingegebene geechot, also auf der
Zeile angezeigt, während sich bei einem USB-RS232-Adapter nichts tut;
die Bytes gehen in's Nirvana.

Ich habe das gerade mit HyperTerm, einem CP2102 und auch einem FT232AM
probiert. Da geht absolut nichts verloren. Alles eingetippte kam brav
als Echo zurück.

Anschlusseinstellungen (von oben nach unten): 19200, 8, Keine, 1, Kein

Mit etwas Rumprobieren habe ich nun rausgefunden, woran es größtenteils
liegt: Durch die lahme Datenübertragung werden die Daten eingelesen,
bevor das letzte Byte eingetroffen ist, so daß das Datenpaket nicht
ganz oder überhaupt nicht eingelesen wird.
Das habe ich nun mit einer zusätzlichen Schleife, die die Bytes
abzählt, beseitigt.

Merkwürdig ist aber, daß dies bei der Byte-Folg 0x1010 nicht der Fall
ist, während 0x1111 fast immer verloren ging.
So als ob ein Byte um so langsamer übertragen wird, je mehr Bits
gesetzt sind oder als ob gerade Bytes bevorzugt werden.

Und beim minicom ist das Problem, daß man den gänderten Port
abspeichern und das Programm neu starten muß, damit es wirklich auf dem
eingestellten Port arbeitet ...

Kurzgesagt scheint jetzt alles zu funktionieren.

384 Byte Receive Buffer / 128 Byte Transmit Buffer
beim FT232BM
kann mir nicht vorstellen das die Bytes in der Hardware verloren gehen,
ist das jetzt wirklich so?


>Gibt es irgendeinen Trick mit dem man den Datenverlust beim FT232BM
>vermeiden kann?

RTS/CTS sollte helfen. Warum nutzt das eigentlich selten jemand?

minicom kannst du dir unter Linux auch sparen wenn du nur mit einem MC
Daten austauschen willst.

Die Bytes sind in der PC-Hardware verloren gegangen, wenn der Puffer
dort gelöscht wurde, die Daten aber noch nicht alle versendet wurden.
Im Code hatte ich nämlich

tcflush (fd, TCOFLUSH);

daß aber nicht flusht sondern discharged.
Ich habe es nun umgeändert in

tcdrain (fd); // wait till the output has been transmitted

Zum Leeren der Betriebssystem-Puffer, die den Hardware-Puffern
vor/nachgeschaltet sind, verwende ich einen separaten Thread.

Ein weiteres Problem war, daß die Daten zwar schön portabel mit select
und anschließendem read eingelesen wurden, aber nur einmal und ohne
lange auf die Daten zu warten. Dadurch ist dann das hintere Ende des
Datenpaketes häufig verloren gegangen bzw. dem nachfolgenden Paket
zugeordnet worden.

Mit der seriellen Schnittstelle gab es das Problem nicht, weil die gut
10 mal schneller ist; da war die Hardware schneller als die Software.