www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kann ein FTDI-Chip Daten verlieren?


Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Einhart Pape (einhart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das parallele Interface bietet definiertes Hardwarehandshake, was, wenn 
"ich" (also nicht ich) recht haben sollte, die serielle Variante nicht 
können soll.

Autor: oszi40 (Gast)
Datum:

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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ... ?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht läuft auch der Puffer im Betriebssystem bzw. Treiber über. 
Rufst du die Daten schnell genug am PC ab?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.