FT232HL FTDI Verzögerungsproblem bei aufeinanderfolgenden SPI-Bytes

Normalerweise arbeite ich mit dem FT2232H-Chip, aber ich habe einen FT232HQ-Chip ausgegraben, nur um dieses Problem zu überprüfen, das Sie hatten. Es ist derselbe Chip wie der FT232HL-Chip, den Sie haben, nur in einem QFN-Gehäuse anstelle eines QFP.

Ich habe versucht, das von Ihnen beschriebene Problem nachzustellen, aber ich konnte es nicht genau. So sah es auf meinem Logikanalysator aus, wenn ich bei einer Taktrate von 5 MHz 6 Bytes auf einmal ausgab. Es gibt eine kleine Verzögerung zwischen Bytes, aber bei weitem nicht so groß wie 64 us.

Hier sind einige Dinge zu überprüfen.

• Der Latenztimer sollte wirklich keine Rolle spielen, da dies einfach ein Timeout ist, bevor USB ein unvollständiges Paket sendet. Ich habe es auf 255 eingestellt, aber oft für Timing-empfindliche Sachen habe ich es niedriger (2 -10)
• Versuchen Sie zuerst eine langsamere Taktrate, nur um zu testen und sicherzustellen, dass das Gerät korrekt kommuniziert (ich nehme an, Sie haben es getan, ich füge dies nur hinzu, falls jemand anderes das noch nicht versucht hat).
• Die Pin-Richtungen spielen keine Rolle, außer für GPIO, da sie von der SPI-Bibliothek überschrieben werden.
• p_SPI_Write()Verwenden Sie statt SPI_Write(). Wenn Sie einen einzelnen Anruf tätigen, fügen Sie die entsprechenden Chip-Select-Enable- und -Disable-Flags hinzu (siehe unten). Wenn Sie mehrere Anrufe tätigen, stellen Sie sicher, dass Sie die Chipauswahl-Flags zum ersten und letzten Anruf in der Reihe hinzufügen.
• Stellen Sie sicher, dass Sie die Anzahl der zu übertragenden Bytes übergeben, und setzen Sie das SPI_TRANSFER_OPTIONS_SIZE_IN_BYTESFlag.
• Wenn es sich um ein benutzerdefiniertes Platinendesign handelt oder Sie eine reduzierte FT232H-Adapterplatine gekauft haben, stellen Sie sicher, dass sie die richtige Systemtaktfrequenz hat. Diese Verzögerung zwischen Bytes basiert darauf, wie lange der Chip braucht, um das nächste Byte von seinem internen Puffer zu den Ausgangsschieberegistern zu verschieben. Wenn der Chip langsam getaktet wird, zeigt sich dies bei den höheren Frequenzen als eine größere Lücke zwischen den Bytes. Beachten Sie, dass es für SPI keine Rolle spielt, ob der Takt hier und da ein wenig gestreckt wird, da er auf den Flanken des Taktsignals basiert (auf einer Flanke lesen, auf der anderen ausbreiten). Prüfen Sie den Kristall- oder CMOS-Kristallchip und stellen Sie sicher, dass er 12 MHz erhält.

Hier ist ein kurzer Beispielcode zum Senden mehrerer Datenbytes, falls es hilft.

uint32 sizeToTransfer = 0;
uint32 sizeTransfered = -1;
uint8 buffer[256]; //Must be large enough for what you are sending.
FT_STATUS status;

//add data
buffer[sizeToTransfer++] = 0x20; //First data byte (can be what you need)
/*
 * More bytes added....
 */
buffer[sizeToTransfer++] = 0x00; //Last data byte (can be what you need)

status = SPI_Write(*handle, buffer, sizeToTransfer, &sizeTransfered,
    SPI_TRANSFER_OPTIONS_SIZE_IN_BYTES |
    SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE |
    SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE);

//Don't forget to check status. It should equal FT_OK if everything went well

Disclaimer: Ich verwende den FT2232H und bin mir nicht 100% sicher, ob alle Aussagen auf diesen Fall übertragbar sind.

Meines Wissens nach ist ftdi mpsse spi nicht wirklich für hohen Datendurchsatz optimiert. Dies wird deutlich, wenn man sich die Quelle genauer ansieht. In der aktuellen Version (ausgecheckt am 24.04.2019) gibt es einen INFRA_SLEEP(2)-Aufruf innerhalb der SPI_ToggleCS-Funktion, der bei jeder Änderung des Zustands der CS-Leitung zu einer Verzögerung von 2 ms führt. Wenn Sie also CS für jedes einzelne Wort pulsieren müssen, sind Sie dem Untergang geweiht. Selbst ohne den Schlafanruf wird die USB-Latenz die Dinge höchstwahrscheinlich stark verlangsamen. Auch ohne diesen Aufruf bleibt der maximale Durchsatz bei meinen Tests hinter den Erwartungen zurück. Ich vermute, dass der Grund dafür in der Architektur von mpsse selbst liegt. Daher würde ich persönlich empfehlen, wenn möglich bei den nativ unterstützten Protokollen wie UART, Fast Opto oder FIFO für Anwendungen mit hohem Durchsatz zu bleiben.

Aus Neugier (falls dieser Fall noch offen ist): Haben Sie auch nach verschiedenen Treibern gesucht? Können Sie dasselbe Verhalten auch bei einem anderen PC beobachten?

Hinter jedem libMPSSE-Aufruf steht ein Aufruf von FT_Write(), das tatsächlich einen Datenrahmen auf Hochgeschwindigkeits-USB schreibt. Bei der Verwendung der Bibliotheksfunktionen sind Sie daher durch die USB-Kommunikationsschicht eingeschränkt (wie vom FTDI-Support gemeldet).

Die Lösung, um die volle Geschwindigkeit zu erreichen, besteht darin, auf eine niedrigere Ebene zu gehen und Ihre Befehle zusammen in einem großen FT_Write() zu puffern, sodass die Daten in einen USB-Übertragungsrahmen gepackt werden:

{
Add to buffer: GPIO Write for CS lo
Add to buffer: Clock N bytes command
Add to buffer: N bytes of data
Add to buffer: GPIO write for CS hi
Add to buffer: Send immediate command (0x87) – only if you read bytes from the LTC device, not if you only write them
++ Repeat for other commands as much as possible for your use-case …
}
FT_Write of the above buffer

Nur um Sie wissen zu lassen, dass die FT232HL FTDI-Treiber meines Erachtens fehlerhaft sind, da die Fehler je nach verwendetem USB-Hub/Marke verschwinden/auftauchen, wie lang das USB-Kabel ist und wie der Computer "vorbereitet" ist. Am Ende kaufte ich einen bestimmten Computer und blieb für die Massenproduktion dabei.

Einige Helfer:

1. AufrufzeitBeginPeriod(4); Vor dem Laden von FTDI-Treibern hilft es sehr, Sie müssen nur danach überprüfen, ob der Zeitraum festgelegt wurde, da Windows den Zeitraum manchmal nicht aktualisiert (aus welchem ​​Grund auch immer). Sehen Sie sich den folgenden Code an, um zu überprüfen, ob timeBeginPeriod(4) funktioniert hat.

   t1d=Uhr(); BITBANG_usleep(5*1000);//5ms t2d=clock(); tspent=(((float)t2d-(float)t1d) / (CLOCKS_PER_SEC/1000)); if((int)tspent > 8){ fehlgeschlagen, beenden oder erneut versuchen! }

   void BITBANG_usleep (unsigned int usdelay) { clock_t t1,t2; Wenn (usdelay <16 * 1000) // 16 ms {t1 = Uhr (); während (1) {t2 = Uhr (); if(((t2-t1)/ (CLOCKS_PER_SEC/(1000)))>usdelay/1000){break;}}} else {usleep(usdelay);} }

2. Verwenden Sie ein kurzes Kabel und eventuell einen USB-HUB im Weg, verbessert die Stabilität erheblich und kann hunderte von Stunden ohne Probleme direkt arbeiten.

Hoffe das hilft, es ist nicht die beste Lösung, aber es hat für mich funktioniert!