Erfahrungen mit USB Chips von FTDI, FT245BM USB FIFO

Ob das IC 128kb/s macht oder nicht macht wirst du sicher im Datenblatt nachlesen koennen. Die alles entscheidende Frage ist aber das Protokoll deines Plotters. Wenn du da einfach nur Daten reinblasen musst dann sollte das gehen. Solltest du aber oefter eine Rueckmeldung abwarten muessen dann ist USB leider langsam.

Olaf

Der FT245 ist kein High-Speed Device. Wenn man ihn direkt an den PC-USB Port haengt, dann finden Transaktion nur im 1 ms Raster statt. Am High-Speed Hub oder als FT2232H High-Speed Device ist das Raster 1/8 ms.

Wenn es nur um den Transfer von grossen Bloecken, dann sollte der FT245 aber gut gehen.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Wenn man ihn in der Emulation als serielles Gerät betreibt: Vermutlich ja. Ansonsten kann man aus dem Ding auch erheblich mehr rausholen (man muss sich dann nur mit der USB-Direktprogrammierung rumschlagen).

jbe

Dann muss man mindestens zwei Transaktionen (je 64 Byte) pro 1ms über den Bus erzwingen. Der Baustein kann das locker (=der ist nicht der limitierende Faktor).

Du kannst normalerweise nur Bulk-Transfers benutzten: Dafür gibt Dir die USB-Spezifikation aber keine Garantie, dass die in gewünschter Zeit mit einer gewünschten Datenrate abgearbeitet werden.

Mittels externem EEPROM kann man den FT245BM aber auf Isochrone Transfers umstellen. Ob das dann aber wieder die von Dir unten zitierten Treiber können, weiß ich nicht. Dann aber hättest Du eine garantierte Bandbreite und Latenz am Bus.

"up to" dürfte da irgendwo stehen. Also keine Garantie. Und eben auch unbestimmte Latenzen, wenn es Bulk-Transfers sind.

Auch hier unbestimmte Latenzen.

Wie zieht denn Dein Endgerät die Daten weg? Durch die unbestimmten Latenzen auf dem USB ist es auch möglich, dass "kurzfristig" mal nichts im FIFO liegt. Kann das Endgerät das verkraften?

jbe

Definiere "öfter" und "langsam". ;-)

jbe

Juergen Beisert schrieb:

Hallo,

wenn erstmal angefangen wurde braucht das Endgerät alle 640 kByte hintereinander weg, ohne jede Lücke oder Leerlauf im FIFO. Alle 250 µs werden die nächsten 32 Byte gebraucht. Ich kann auch ein externes FIFO zur Pufferung dazuschalten, z.B. ein IDT7208 mit 65,636 Bytes. Nur möchte ich nicht gleich externe 640 kByte an FIFO vorsehen. Bei Transaktionen von 64 Byte kann der interne FIFO mit 128 Byte nicht mehr viel retten, externe 64 kByte schon eher.

Bye

Hm..ich kenne z.B Messgeraete die senden auf jedes verschickte Byte auch ein Byte ans Antwort zurueck um das man sich kuemmern muss. Das ist dann langsam.

Olaf

Dann erzaehl uns mal wie du das machst. 1ms ist doch der Basistakt von USB fuer den Paketversandt.

Olaf

Hallo Olaf,

Olaf Kaluza schrieb:

Du kannst problemlos innerhalb eines Frames mehrere Pakete versenden. Oder abholen. Weniger problemlos ist es dann, das zeitlich gezielt zu machen, wenn Du nicht isochron arbeiten willst oder kannst.

Gruß Martin

--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

Hallo Uwe,

Uwe Hercksen schrieb:

Im Zweifelsfall sorgst Du erstmal dafür, daß das Gerät allein an dem jeweiligen USB-Controller hängt. Nachdem ein typischer PC heute einen ganzen Schwung 1.1er Controller hat, ist das kein Problem. Wenn Du dann nicht gleichzeitig irgendwelche den Speicherbus überlastenden Dinge tust, sollte als einziges Problem noch bleiben, genügend schnell (am besten vorab) entsprechend Speicher auch freizuräumen.

Gruß Martin

--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

1ms ist der Basistakt, mit dem der USB-Host die Planung für den nächsten Zyklus macht. D.h. es werden alle bis dahin anliegenden Aufträge "begutachtet" und die verfügbare Bandbreite für diese 1ms nach Priorität verteilt. Wenn jetzt für Dein Gerät mehr als ein Auftrag gleichzeitig vorliegt und deren Bearbeitung in die verfügbare Bandbreite passt, werden sie auch in dieser 1ms abgearbeitet. Wie sonst soll man mit nur 64 Byte pro Bulk-Paket beim USB1 mehr als 64.000 Bytes pro Sekunde schaffen? Das geht nur über n-Pakete in diesem 1ms Zeitaster (beispielsweise bis zu 19 Bulk-Transfers a 64 Byte pro 1ms Raster bei USB1). Aber leider werden Bulk-Transfers zeitlich nicht vorhersagbar "verschoben", wenn ansonsten viel auf dem Bus los ist.

jbe

Du brauchst also alle 500us einen vollen 64 Byte Bulk-Transfer. Sobald es auch nur einmal länger dauert, knallt Deine Anwendung (was nützt ein FIFO, wenn er schneller entleert, als gefüllt wird). Für diesen Anwendungsfall wurde der "isochronous transfer type" geschaffen: Garantierte Bandbreite und Latenz. Darüber wäre dann zumindest auch sicher gestellt, dass es immer funktioniert. Sonst passiert es eben, dass es mal geht und mal nicht (Mondphase), oder an diesem Rechner prima und zuverlässig geht, an jenem aber überhaupt nicht.

64kiB wären etwa 500ms Puffer (wegen 32 Byte/250us). Standard-Bulk könnte dann auch so funktionieren.

Gruß jbe

Stimmt. Die spielen dann Ping-Pong im 1ms Raster.

jbe

Wie kann fuer mein Geraet mehr als ein Auftrag vorliegen? Der Inhalt des n+1 Auftrag kann ja erst generiert werden wenn die Antwort vom Slave auf den n-Auftrag zurueckgekommen ist da von der Antwort der Inhalt abhaengt.

Olaf

Hallo Jürgen,

Juergen Beisert schrieb:

Die können auch innerhalb der Millisekunde mehrfach Ping-Pong spielen. Wenn der Prozessor das auf die Reihe kriegt.

Gruß Martin

--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

Hallo Jürgen,

Juergen Beisert schrieb:

Die können auch innerhalb der Millisekunde mehrfach Ping-Pong spielen. Wenn der Prozessor und das OS das auf die Reihe kriegt. Vom USB und seinen typischen Controllern her spricht jedenfalls nichts dagegen.

Gruß Martin

--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

Hallo Olaf,

Olaf Kaluza schrieb:

Das kommt wohl sehr auf die Anwendung an. Wenn Daten an eine Platte übertragen werden, liegen eigentlich immer mehr als 64 Byte vor. Bei seriellen Übertragungen auch sehr häufig. Es ist aber auch kein Problem, auch während der Millisekunde weitere Aufträge in die Schlange zu hängen.

Gruß Martin

--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

Aber ob die dann noch in der bereits laufenden Millisekunde abgearbeitet werden? Ich würde eher davon ausgehen, dass die dann in der nächsten Millisekunden zum Zuge kommen.

jbe

Sende 1024 Bytes zu Deinem Gerät. Dann sind das 16 Aufträge am Stück.

Wenn Du mit Deinem Device Ping-Pong spielst: Ja. Aber musst Du das? Ansonsten "volles Rohr", äääh Pipe.

jbe