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?
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.