Hallo, wie der Betreff schon sagt: Ich habe eine Applikation in der ich zwischen einem Mikrocontroller und dem PC einen FT2232H einsetze (Brutto-Datenrate 2.25 MBit). Nach ein paar MByte verliere ich relativ reproduzierbar immer mal 4-5 Byte. Muss ich die Handshake-Leitungen zum FT2232H nutzen weil es sein kann, dass dieser sporadisch seinen Puffer via 480 MBit USB (in Richtung PC) nicht leer bekommt? Kann ein kurzer Hänger auf dem PC dazu führen, dass ein solcher Datenstau entsteht? Besten Dank für jegliche zweckdienliche Kommentare, Alex
Definitiv kann es, bei diese Übertragungsrate, zu "Hängern" kommen. Windows und Linux sind keine Echtzeitbetriebssysteme. Normalerweise muss das der Treiber in der ISR diese "Hänger" mit einem Buffer überbrücken. Schau doch mal ob man bei dem USB-Treiber einen grösseren Puffer einstellen kann.
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
Keine Ahnung, ob das hilft: Ich habe bei einer Anwendung mit virtuellem COM-Port FT232R einen Verlust von Zeichem, sobald ich eine sogenannte aktive USB-Verlängeung einschleife. Merkwürdigerweise werden keine Zeichen verfälscht, aber es fehlen eine ganze Menge. Da kann ich mich nur freuen, dass der USB-Hub anscheinend keine Probleme macht. Gruß Einhart
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
Das parallele Interface bietet definiertes Hardwarehandshake, was, wenn "ich" (also nicht ich) recht haben sollte, die serielle Variante nicht können soll.
-Wenn der eine Treiber Handshake ignoriert, könnte es ja mit dem anderen evtl. funktioniern. -Hat Buffer-Vergrößerung etwas verbessert ?
Also dass mit dem FTDI-Chips Daten auf unerklaerliche Weise verschwinden hatte ich auch schon. Ohne Handshake wuerde ich sowieso nichts mehr machen, das kann am Ende nur schief gehen...
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
> dass der Treiber die Handshakeleitungen steuert
Was lässt Dich das annehmen?
Wie interpretierst Du
Fully assisted hardware or X-On / X-Off
software handshaking.
und
RTS / CTS, DSR DTR and X-On X-Off handshaking
options are also supported. Handshaking, where
required, is handled in hardware to ensure fast
response times.
(Quelle: Datenblatt des FT232R)
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 ... ?
Vielleicht läuft auch der Puffer im Betriebssystem bzw. Treiber über. Rufst du die Daten schnell genug am PC ab?
Michael G. schrieb: > Also dass mit dem FTDI-Chips Daten auf unerklaerliche Weise verschwinden > hatte ich auch schon. Ohne Handshake wuerde ich sowieso nichts mehr > machen, das kann am Ende nur schief gehen... Sicher sicher... So Pauschal ist die Aussage einfach Mumpitz.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.