FTDI 232 FTD2XX

[Robert (Gast)]

Hallo Zusammen,

hat jemand bereits eigene Erfahrungen mit der FTD2XX Schnittstelle in
Bezug auf Zuverlässigkeit und Geschwindigkeit?

Hintergrund meiner Frage:

Bei der Verwendung der COM Port Treiber ensteht beim Empfang von
einzelnen Zeichen eine starke Verzögerung, bis die Zeichen tatsächlich
zur Verfügung stehen. Bei den neuen WHQL Treibern habe ich Zeiten
zwischen 10 und 16mS für das Echo eines einzelnes Zeichens gemessen.
(Unabhängig von der Baudrate) Die Zeiten sind für jeden PC den ich
probiert habe, stabil. Einstellbar sollte dieses Verhalten des Treibers
ja über die 'Latency' sein. Die Latenz kann allerdings leider nur
verlängert werden, kürzere Einstellungen zeigen keine Wirkung.

Support Anfrage bei FTDI brachte dazu keine Erkenntnis. Man ist dort
der Meinung dieses Verhalten liege an Windows... den Rest dazu erspare
ich euch - ist nicht zielführend und dokumentiert nur das Unwissen oder
den Unwillen des supports(Level 2).

Letzte Hoffnung wäre jetzt, wenn die D2XX Treiber schneller arbeiten
würden, bzw. wenn man den FTD232 Chip dazu bewegen könnte, eingehende
Daten sofort an den PC zu übertragen.

[Rick Dangerus (Gast)]

Hallo Robert!

Ich vermute die Latenzen entstehen bei den USB-Transfers. Da wird auch
ein anderer Treiber nicht viel dran ändern können (außer er verwendet
einen Transfermodus mit geringeren Latenzen.)

Rick

[Rufus Τ. F. (rufus)]

Was eventuell das Ergebnis beeinflussen kann, ist ein Verändern der
standardmäßig auf 10msec stehenden Timergranularität von Windows. Mit
den "multimedia-Funktionen" kann die auf bis zu 1msec reduziert
werden.

#include <windows.h>
#include <mmsystem.h>

..
..
if (timeBeginPeriod(1) == TIMERR_NOERROR)
{
  // hat geklappt

  ..
  // Aktivität
  ..

  // Timerauflösung zurücksetzen
  timeEndPeriod(1);
}
else
{
  // Fehlerbehandlung
}

Bei den herkömmlichen seriellen Schnittstellen (16550) kann man die
Empfangs- und Sendefifos konfigurieren - wenn wirklich nur einzelne
Zeichen empfangen werden sollen, ist das Empfangsfifo zu deaktivieren,
da sonst ein von der Hardware vorgegebenes Timeout vergeht, bis trotz
nicht erreichten Fifopegels der Empfangsinterrupt ausgelöst wird.

Sieht möglicherweise der FTDI-Treiber auch diesbezügliche
Konfigurationsoptionen vor?

[Robert (Gast)]

Hallo Rick,

Die USB Transfers finden bei Windows genau im Abstand von einer mS
statt. Das kann man ganz gut prüfen, wenn man WriteFile jeweils mit
einem Zeichen (Länge 1) in einer Schleife aufruft und mit dem Oszi die
Tx Leitung ansieht. Dann kommt jede mS ein Zeichen raus.

Die 16mS, die vorzugsweise auf den moderneren PC's mit CPU > 1GHz beim
Empfang von Zeichen auftreten, sind sicher nicht in Windows begründet.
Ich habe hier ein CAN2USB Interface als Vergleich, das schafft ein
8Byte CAN Telegram in 2mS zu echo'n.

[Robert (Gast)]

Hallo Rufus,

tja beim 16550 war die Welt noch in Ordnung, da die Latenzen sich in
einer vernünftigen Größenordnung bewegt haben. Die diesbezügliche
Einstellung für den FTD232BL ist die 'Latency' im Gerätemanager unter
Eigenschaften  Advanced Settings  BM Options.

Was den MM Timer angeht, werde ich bei nächster Gelegenheit mal einen
Test machen.

[Robert (Gast)]

Danke Rufus,

die Idee mit MMsystem zeigt eine gewisse positive Wirkung... Warum man
im FTDI Treiber die time Funktionen aus der Multimedia API nutzen muss
ohne die Folgen für die Applikationen zu dokumentieren, ist mir zwar
schleierhaft, aber damit ist jetzt immerhin klar was passiert.

Der Treiber könnte ja den Call selber absetzen, wie in der MSDN Lib zu
lesen ist: This function sets the minimum timer resolution for an
application or device driver.

Jetzt erreiche ich immerhin 200 Zeichen, was 5mS echo Zeit entspricht.
Nicht toll, aber immerhin 3mal so schnell wie vorher.