Announcement: there is an English version of this forum on Hallo, kennt ihr zufällig einen Chip/Dongle mit dem ich SPI an USB anschließen kann und dabei die volle Bandbreite von USB nutzen (12 Mbps, im Idealfall wäre sogar 480 Mbps schön, muss aber nicht sein)? Ich hab bis jetzt nur welche gefunden, welche an UART angeschlossen sind, und dadurch bei 0.5 / 1 Mbps aufhören (FT220X, FT120X). Viele Grüße, Matze
Interessantes Thema. Ich versuche das auch gerade. Mit dem FT2232H sind laut Datasheet bis zu 30 MBit/sec per SPI möglich, das werde ich demnächst mal testen.
FT232H (ein Kanal) FT2232H (zwei Kanäle) FT4232H (vier Kanäle) wobei die beiden letzteren als fertiges "FTx232H Mini-Module"-Board für je ca. 25€ zu haben sind.
Matze schrieb: > Hallo, > > kennt ihr zufällig einen Chip/Dongle mit dem ich SPI an USB anschließen > kann und dabei die volle Bandbreite von USB nutzen (12 Mbps, im > Idealfall wäre sogar 480 Mbps schön, muss aber nicht sein)? > > Ich hab bis jetzt nur welche gefunden, welche an UART angeschlossen > sind, und dadurch bei 0.5 / 1 Mbps aufhören (FT220X, FT120X). Es gäbe noch CP2130 von SiLabs, MCP2210 von Microchip und Maxims MAX3421E Ansonsten die schon vorgeschlagene Lösung mit einem Controller der USB kann und die Umsetzung vielleicht besser hin bekommt, da nur auf diesen Anwendungsfall optimiert, als eine Universallösung.
Hallo Matze Ein ATxmega mit eingebauten USB Tranceiver bzw. http://matrixstorm.com/avr/avrstick/ Fuer letzteres gibt es vorgefertigte, "browsermodifizierbare" Firmwares die dir das ganze USB gehangel abnehmen. (http://matrixstorm.com/avr/avrstick#bideavr) MfG
Michael K. schrieb: > als fertiges "FTx232H Mini-Module"-Board für > je ca. 25€ zu haben sind. Bei ELV als UM-FT2232H für 15€. Damit habe ich mit 5MBit/s LPD8806-LED-Strips angesteuert.
Matze schrieb: > Hab jetzt auch noch einen gefunden, den MCP2210 von Microchip welcher > bis 12 Mbps kann. Hallo Matze, der MCP2210 kann leider keine 12 Mbit/s, auch wenn das Datenblatt durchaus etwas anderes behauptet. :-( Ich habe ihn seit Kurzem im Einsatz und er kann nur Bitraten bis zu 3 Mit "im Peak". Mehr geht sowieso nicht - auch wenn man (lt. Datenblatt bis zu 12 Mbit/s) einstellt. Aber die Ernüchterung war noch schlimmer: Wenn man den Chip kontinuierlich Daten übertragen lässt (er hat intern je einen 60 Byte großen RX und TX FiFo), dann kommt man bei den eingestellten 3 Mbit/s effektiv nur noch auf lächerliche ~ 80 kBit! Ich konnte es lange nicht wahrhaben und eine aufwändige Analyse gestartet: Als Erstes habe ich meinen (HID-) Treiber überprüft, habe mit meinem DSO nachgemessen. Dann den Treiber von HID auf USB Interrupt umprogrammiert (dazu zuerst das OS (Mac OS X 10.7) überredet das Device nicht als HID einzubinden). Das machte gar keinen Unterschied. Die Ergebnisse der Messungen mit dem DSO: Das Problem ist, dass der Chip zwar je ein Byte mit 3Mit sendet, sich dann aber jeweils für ca. 40us Pause macht. Ond das obschon ich explizit den "Byte to Byte" delay im MCP2210 SPI Setup auf 0 gesetzt habe! Aber es kam noch schlimmer: Dann - nach einem gesendeten FiFo (in meinem Fall mit 60 Byte optimal ausgenutzt) legt der Chip noch mal eine Pause von knapp 3ms(!) ein. Das zieht die Performance gnadenlos in den Keller und von den eingestellten 3 MBit / s bleiben dann effektiv eben nur noch schlappe 80 kBit/s (!). Zusammengefasst: Die Bytes werden durchaus bursty mit 3 Mbit/s gesendet, dann folgt aber eine Pause von 40us zwischen den Bytes. Und alle "Puffer Size" (bei mir im Test 60 Bytes (max Size des MCP2210 FiFo)) nochmal 3 Millisekunden (!) Wie gesagt - ich habe mich mit dem Chip die vergangenen Tage intensiv beschäftigt und das Problem ist gleichermassen sein (vermeindlicher) Segen, nämlich dass es sich beim MCP2210 um ein USB-HID handelt. Dazu muss man wissen das HID Devices max. 64 kByte/s übertragen können. Leider ist der MCP2210 selbst davon weit entfernt. :( Übrigens - auf meine ernüchterndes Ergebnis sind auch noch Weitere Anwender gekommen und auch die konnten die schlappe Performance erst lange nicht glauben - so wie ich: daniel-santos/mcp2210-linux: -> https://github.com/daniel-santos/mcp2210-linux/issues/11 Kerry D. Wong - MCP2210 Library Reference : -> http://www.kerrywong.com/2012/10/30/mcp2210-library-reference/ Microchip Forum „MCP2210 Breakout - Slow SPI performance?“ : -> http://www.microchip.com/forums/m661824.aspx Wenn Du magst, kann ich Dir auch eine Zusammenstellung meiner Messergebnisse (samt Screenshots vom Oszi) schicken. Die illustrieren das Problem sehr gut... VG - Peter -
:
Bearbeitet durch User
Hallo nocheinmal. Mit fullspeed USB direkt das theoretische Limit von 12Mbps zu erreichen ist auch schwer. Wieviel brauchst du denn mindestens (genau)? MfG
Stephan B. schrieb: > Mit fullspeed USB direkt das theoretische Limit von 12Mbps zu erreichen > ist auch schwer. Das ist nicht schwer, das ist völlig unmöglich. 12MBit/s ist kein theoretisches Limit, sondern nur werbewirksamer Unsinn, der so tut, als gäbe es keinerlei Protokoll und in jeder USB-Bitzeit würde wirklich ein Nutzbit über die Leitung gehen.
Zur Info: Mit dem STM32F072/42 sind 64kByte/s locker möglich (bei 48Mhz Takt). Habe ich schon am laufen. Wo seine Grenze liegen, weiß ich nicht. Mir reichen die 64kByte/s, deshalb habe ich nicht weiter getestet. Also das ist die WIRKLICHE Nettodatenrate im Interrupt Transfer (64Byte/ms)!!! Und das für <1€/Chip bzw. 19€ fürs Eval Board finde ich genial!
Sepp schrieb: > Mit dem STM32F072/42 sind 64kByte/s locker möglich (bei 48Mhz Takt). Und inwiefern hilft das jetzt weiter? 64kbyte/sec <<< 12Mbps - dachte ich zumindest... Mein ATxmega schaft sogar locker 128kbyte/sec - sogar mit USB Klassen drumrum... MfG
Sepp schrieb: > Zur Info: wen soll das interessieren? Der OP redet von Übertragungsraten, die 2-3 Größenordnungen über deiner liegen
c-hater schrieb: > 12MBit/s ist kein theoretisches Limit, sondern nur werbewirksamer > Unsinn Gewiss. Mit USB-Massenspeichern sind über USB1.1 realistische Nettotransferraten in der Größenordnung um* 1 MByte/sec erreichbar. Die nutzen dann natürlich Bulk-Transfers. *) nicht im österreichischen, sondern im hochdeutschen Sinne.
Der kann das (High-Speed-USB zu SPI): http://www.digikey.de/product-search/de?v=768&mpart=VA800A-SPI
Rufus Τ. Firefly schrieb: > Gewiss. Mit USB-Massenspeichern sind über USB1.1 realistische > Nettotransferraten in der Größenordnung um* 1 MByte/sec erreichbar. Die > nutzen dann natürlich Bulk-Transfers. So sieht's aus. Weder mit Bulk- noch mit Isochron-Transfers sind auch nur theoretisch nennenswert mehr als 8MBit/s aus Fullspeed herauszukitzeln(*). Genau deswegen ist die Angabe einer "theoretischen" Datenrate von 12Mbit/s für Fullspeed eine freche Werbelüge, denn die Verbreiter dieser Lüge kannten das selbstgeschaffene Protokoll ja vorher. (*) Es geht schon deutlich mehr, aber dann ist's maximal noch auf dem PHY-Layer eine Art USB und wird definitiv mit nix zusammenarbeiten können, was das USB-Logo trägt...
Also ich besitze einen USB 3.0 USB-Stick, der schafft effektiv ca. 100MByte/s, auch wenn er dazu auf ein paar zusätzliche Drähte zurückgreifen muss. :D
Ich kann dem Hans-Peter D. nur vollkommen zustimmen, der Microchip IC ist definitiv langsam, so langsam dass ich es erst auch nicht glauben konnte. Selbst für das Setzen der IO's (GPIO) habe ich 2 ms gemessen. Ich hatte nämlich, um zu testen ob ich etwas falsch gemacht habe, SPI Software bit-banging über dessen IO's implementiert. Das hat zwar funktioniert, war aber genauso langsam. Das Ändern des Chip Selects übere deren API dauerte bei mir im Übrigen 4 ms. Ich habe jetzt ein Modul mit FTDI Chipsatz und Teensy 3.1 bestellt, und hoffe dass er dort besser ausschaut. Fazit: Für einfache Steuerbefehle per SPI zu gebrauchen, dafür kann man dann aber auch I²C nehmen. MCP2210 ist in keinerlei Weise empfehlenswert!
Benjamin K. schrieb: > Ich kann dem Hans-Peter D. nur vollkommen zustimmen, der Microchip IC > ist definitiv langsam, so langsam dass ich es erst auch nicht glauben > konnte. > > Selbst für das Setzen der IO's (GPIO) habe ich 2 ms gemessen. Ich hatte > nämlich, um zu testen ob ich etwas falsch gemacht habe, SPI Software > bit-banging über dessen IO's implementiert. Das hat zwar funktioniert, > war aber genauso langsam. Das Ändern des Chip Selects übere deren API > dauerte bei mir im Übrigen 4 ms. Ich habe jetzt ein Modul mit FTDI > Chipsatz und Teensy 3.1 bestellt, und hoffe dass er dort besser > ausschaut. > > Fazit: Für einfache Steuerbefehle per SPI zu gebrauchen, dafür kann man > dann aber auch I²C nehmen. MCP2210 ist in keinerlei Weise > empfehlenswert! 2ms ist verdammt schnell, weil hier ein PC involviert ist. Da ist ja nicht nur USB dahinter, sondern auch noch das Multitasking Betriebssystem des PC mit Scheduler. Üblicherweise kenne ich Reaktionszeiten des PC von so ca. 10ms... Etwas Literatur zum Scheduler: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685096%28v=vs.85%29.aspx Und das USB Prototkoll. Das braucht auch seine Zeit. Ein normales PC-Betriebssystem (also Windows, Linux) ist daher auch für Echtzeitaufgaben auch völlig ungeeignet. Es gibt spezielle Echtzeit-Betriebssysteme, aber ob die schneller sind weiß ich nicht. Ob der Chip wirklich so schlecht ist, und ob die Konkurrez es besser macht bezweifle ich also. Ich habe mit einem STM32F072 auch keine viel besseren Resultate erhalten...
1 ms ist bei Full Speed USB ohne weiteres möglich, unter Windows mit etwas mehr Aufwand. Die beobachteten ca. 60 kByte/s liegen daran, dass HID als Protokoll verwendet wird und das hat die Beschränkung auf 64 Bytes pro Endpoint bei maximal einem Report pro Millisekunde pro Endpoint. Will man höhere Datenraten, dann geht kein Weg an Bulk oder Iso-Transfer vorbei, dazu braucht man dann aber einen spezifischen Treiber. HID ist halt einfacher zu benutzen, aber nicht so leistungsfähig wie es (theoretisch) ginge. In netter Darreichungsform gäbs USB zu SPI als Dongle mit Full-Speed, aber halt mit der oben genannten Einschränkung auf rund 60 kByte/s: http://www.codemercs.com/index.php?id=iow56dg&L=0
Ausgehend von meinen gemessenen 4 ms für das ChipSelect kann man sich ja leicht ausrechnen was da für die Übertragungsrate übrig bleibt. Wenn man pro Chip-Select jetzt wirklich 64 Byte übertragen kann dauert das Schreiben von 1 KB ca 64 ms, d.h. ich komme auf Übertragungsraten von knapp 16 KB/s. Im realistischen Fall wo es zum Beispiel darum geht per SPI ein Display anzusteuern, wird man wahrscheinlich sehr viel mehr Chip-Selects benötigen. Da kann man dann zusehen wie die einzelnen Pixel gezeichnet werden. Mit dem Teensy 3.1 µC Board schaffe ich es über den virtuellen COM-Port welcher über einen FTDI-Chip bereitgestellt wird Datenraten von knapp 1 MB/s von dem PC an den µC zu senden, das reicht dann bei meinem 320x240 Display für knapp 5 Bilder/s. Ähnliche Raten wird man auch schaffen denke ich wenn man den FTDI 232H USB-SPI Chip direkt ansteuern würde. Natürlich hat man das Problem dass ein Context-Switch einige ms dauert, d.h. man wird immer mal wieder diese Verzögerungen drin haben.
Also ich weiss nicht wie das bei FTDI aussieht, aber mit unserem IOW56 erreichen wir ohne Probleme die 1000 Reports pro Sekunde, was bei 64 Byte pro Report netto über 60.000 Byte/s ergibt.
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.