Kann ein FTDI-Chip Daten verlieren?

Also, zwischen PC und FTDI ist der Treiber für die Kommunikation 
verantwortlich und sollte dafür sorgen, dass nix verloren geht. Jetzt 
kommts drauf an, wo die Daten hops gehen, vom FTDI zu deiner Schaltung, 
oder zum FTDI hin?
Aus deinem Beitrag lese ich, dass es vom µC zum FTDI hin ist. Wie 
schnell sendet dein µC denn? Über UART oder anderes Interface?

Ralf

Die Handshakeleitungen nützen nicht wirklich viel. Diese werden leider 
durch den Treiber und nicht durch die FTDI Hardware gesteuert. Deswegen 
wird dieser Weg nichts nützen. Das Problem hatte ich mal bei einem 
FT232.
Ich kann nur das parallele Interface empfehlen (FT245, bzw FT2232H kann 
das auch), da sollte dann auch bei höheren Datenraten nichts verloren 
gehen

Hallo,


der Daten werden via UART zwischen FTDI-Chip und Mikrocontroller 
ausgetauscht. Die Netto-Datenrate ist nahe an den 2.25 MBit dran. 
USB-Verlängerungen/Hubs verwende ich nicht. Was ein Wechsel auf das 
parallele Interface bringen soll erschließt sich mir nicht. An der 
Netto-Datenrate würde sich dabei nichts ändern, ich hätte nur einige 
mehr Drähte zu ziehen :)


Gruß,
Alex

-Wenn der eine Treiber Handshake ignoriert, könnte es ja mit dem anderen 
evtl. funktioniern.
-Hat Buffer-Vergrößerung etwas verbessert ?

Was "ich", also ich meinte, ist dass der Treiber die Handshakeleitungen 
steuert, es kann also sein dass der PC Steuerleitungen setzt dass er 
nicht mehr empfangsbereit ist. Diese werden aber erst mit dem nächsten 
USB Paket, was bis zu 16ms später gesendet werden kann, gesetzt. Sendest 
du in dieser Zeit daten, könnten diese verloren gehen.
Das parallele Interface generiert die Steuerleitung direkt in Hardware, 
also ohne nennenswerten Verzug

Kann das auch bestätigen, dass FTDI-Converter Daten verlieren. Einer 
direkter Replace mit einem CP2102 von SiLabs brachte sofortige Besserung 
bei ansonsten unveränderter Hardware

Hallo,


danke für euren Beistand :-)

@Oszi40

Auf dem PC nutze ich den von FTDI bereitgestellten VCP-Treiber mit einer 
Puffergröße von 1MByte.
Warum der Chip in der Lage sein soll, bei parallelen Zugriffen ein 
HOLD-Signal zu setzen, bei seriellen Zugriffen aber nicht, ist mir nicht 
ganz verständlich. Leider finden sich im Datenblatt diesbezüglich keine 
erhellenden Angaben.

Die 4 kByte Puffer sollten bei 2.25 MBit im worst-case immer noch 18 ms 
reichen.

@ich
Kannst du mir Dokumente nennen, die deine Angaben untermauern? :)

Ich denke ich werde testweise auch einmal direkt auf die D2XX-API gehen 
und schauen, ob bei Verwendung dieser das Problem immer noch auftritt.

Der Wechsel auf das parallele Interface erscheint mir eher umständlich, 
ein UART ist halt einfacher zu handhaben und um die Zugriff kümmert sich 
der DMA-Controller.


Gruß,
Alex

http://www.core.co.kr/down/AN232B-04_DataLatflow.pdf

Wenn diese AN auch für die neueren Devices gilt (und Rufus recht hat) 
sollte das Verwenden von RTS/CTS etwas Abhilfe schaffen.

Dumm ist nur, dass ich eigentlich nicht viel RAM im Controller übrig 
habe um sendeseitig nochmal x kByte zu Puffern. Interessant wäre auch zu 
wissen, wie lange der USB-Bus im worst-case überhaupt hängen kann. Was 
hilft jetzt einen SW-Puffer vor den HW-Puffer zu bauen, bloß um die 
Problemwahrscheinlichkeit zu senken ohne das eigentliche Problem zu 
lösen ... ?

Das konfigurierte MByte (diese Angabe hatte ich bis jetzt wohl 
unterschlagen) sollte eigentlich reichen.

(1024  1024  10 Bit) / 2.25 MBit/s = 4.7 s

Den kuriosen Fall, daß der Buffer zu groß ist und gewartet wird ===>bis 
er voll ist hatte ich auch schon mal (bei Druckern).

Da man die einzelnen Unterprogramme nicht persönlich kennt, sind da noch 
einige lustige Varianten durchaus möglich.