Seite 1 von 1
Datenfehler mit FTDI USB/Seriell-Konvertern
Verfasst: 22.01.2011 20:45
von EgonEprom
Ich hab von 'nem Jahr ein Terminal-Programm geschrieben, das wunderbar funktioniert, wenn auf ein "echtes" COM-Port zurückgegriffen wird. Wird ein FTDI-Chip verwendet, kommt es - bei einem PB4.40 Kompilat - zu gelegentlichen Übertragungsfehlern. Grad noch so tolerabel. Wurde der selbe Quelltext mit der V4.50 kompiliert, ist die Fehlerrate unerträglich hoch. (Nur via USB!). Getestet hab ich das unter Win2000, Win7prog und Win7ulti. (auf jeweils verschiedenen Rechnern). Hat sonst jemand schon mal dieses Problem gehabt? (und evtl. dieses gelöst?)
Echte COM-Ports werden ja immer seltener...
Danke vorweg und Grüße von EgonEprom
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
Verfasst: 23.01.2011 08:24
von H.Brill
Arbeite zwar auch gelegentlich mit diesen
Konvertern, habe aber noch nie im Dauerbetrieb
getested.
Wäre ja ziemlich ärgerlich, zumal diese FTDI-Chips
die besten, bzw. die zuverläsigsten sein sollen.
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
Verfasst: 23.01.2011 09:49
von ts-soft
Versuchs doch mal per API. Ist so ähnlich wie in eine Datei schreiben
Beispiele für Windows findest Du im CodeArchiv auf PureArea.net, z.B. von S. Rings.
Gruß
Thomas
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
Verfasst: 23.01.2011 11:53
von HeX0R
Ich kann das nicht bestätigen.
Eine meiner Applikationen arbeitet schon seit Jahren* mit dem FTDI-Chip zusammen (wir haben den in einen Logger verbaut)
und hat in der Zeit verschiedene PB-Updates überstanden, ohne, dass jemals irgendein Bit verschluckt worden wäre.
(mit 115200 Baud im übrigen).
*Seit Jahren:
Angefangen hat das noch, als PB gar keine seriellen Befehle hatte, da musste ich in der Tat die API-Variante benutzen,
aber auch nach der Umstellung auf die hauseigenen COM-Befehle gab es keinen Reibungsverlust.
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
Verfasst: 30.01.2011 15:57
von EgonEprom
HappyEnd!
Den Fehler habe ich zwischenzeitlich selber gefunden: der USB-Treiber bzw. Windows scheint max. 1 Sende-Job ausführen zu können. Wenn man - wie ich bis neulich - die Bytes einzeln absetzt, kann man via USB auf nicht mehr als 1 kB/s kommen.
Dann habe ich die zu sendenen Bytes "intelligent" gesammelt und in 16er Paketen versendet. (ein willkürlich gewählter Wert)
Damit ging alles schon deutlich schneller. Dann habe ich noch alle DELAY()'s rausgeschmissen. Das wars.
(Bei Windows kann man sich - wenn mit DELAY() gearbeitet wird - nicht darauf verlassen, daß die Reihenfolge eingehalten wird ?!?)