Forum: Mikrocontroller und Digitale Elektronik FT232BM und ähnl. können nicht einmal Half-Duplex richtig?


von Rolf F. (Gast)


Lesenswert?

Beim FT232BM, den ich auch in zwei USB-RS232-Adaptern verwende, mußte
ich leider feststellen, daß der nicht fullduplex-fähig ist und häufig
nicht einmal halfduplex kann: Wenn ich beim IC, oder auch einem
USB-RS232-Adapter den Ausgang an den Eingang anschließe und nur
nacheinander sende und empfange (d. h. halfduplex), dann gehen die
meisten Daten verloren!
Dasselbe Problem gibt es bei einem USB-RS232-Adapter mit einem
PL-2303.
Mit einer seriellen Schnittstelle gibt es das Problem nicht; dort geht
nichts verloren.

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

von Rolf F. (Gast)


Lesenswert?

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.

von René König (Gast)


Lesenswert?

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

von Rolf F. (Gast)


Lesenswert?

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.

von Lanius (Gast)


Lesenswert?

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.

von Rolf F. (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.