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
Datenfehler mit FTDI USB/Seriell-Konvertern
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
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.
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.
PB 6.10
-
ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
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
Beispiele für Windows findest Du im CodeArchiv auf PureArea.net, z.B. von S. Rings.
Gruß
Thomas
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
-
HeX0R
- Beiträge: 3040
- Registriert: 10.09.2004 09:59
- Computerausstattung: AMD Ryzen 7 5800X
96Gig Ram
NVIDIA GEFORCE RTX 3060TI/8Gig
Win11 64Bit
G19 Tastatur
2x 24" + 1x27" Monitore
Glorious O Wireless Maus
PB 3.x-PB 6.x
Oculus Quest 2 + 3 - Kontaktdaten:
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
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.
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.
{Home}.:|:.{Codes}.:|:.{Downloads}.:|:.{History Viewer Online}.:|:.{Bier spendieren}
-
EgonEprom
- Beiträge: 24
- Registriert: 15.02.2010 18:18
- Computerausstattung: Windows2000-XP-Vista-7
- Wohnort: Saarwellingen
Re: Datenfehler mit FTDI USB/Seriell-Konvertern
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 ?!?)
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 ?!?)