Full-Speed USB <-> SPI

jeder µc mit eingebautem usb?
im idealfall mit HW-SPI

Hab jetzt auch noch einen gefunden, den MCP2210 von Microchip welcher 
bis 12 Mbps kann.

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.

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

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!

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.