USB Bulk Transfer Verständnisfrage

[Tastkopf (Gast)]

Hi,

Usb basiert auf 4 Übertragungstypen, der für große, nicht zeitkritische 
Datenmengen ist Bulk-Transfer. Auf dem Bus werden die Übertragungen in 
Frames (1ms bei Low und Fullspeed und 125us bei Highspeed). Für die 
reine Verständnisfrage bleiben wir am besten bei Low/Full-Speed. Für 
Bulk wird/soll ein 64Byte goßer Buffer verwendet werden, wie auch für 
Control- und Interrupt-Transfers. Wie kommt man damit auf hohe 
Datenraten, bei einer Frame-Periode von 1ms und einer Buffer-größe von 
nur 64Byte. Für isochrone Transfers sind im vergleich 1023byte als 
Buffer größe vorgesehen.
Die Seiten die ich dank google gefunden habe, waren zwar sehr 
informative, aber klick hat es leider noch nicht gemacht. Ich hoffe ihr 
könnt mir weiterhelfen.

[Georg A. (Gast)]

Die Hostcontroller erlauben es durch chained DMA, mehrere Bulktransfers 
zu queuen. Je nach Policy werden die Queues dann pro Endpoint oder über 
alle Endpoints in einem Frame durchlaufen.

[Tastkopf (Gast)]

ok, das erklärt hohe datenraten bei vielen EPs, wenn für jeden EP 64Byte 
Buffer vorhanden sind können entsprechen viele Daten in einen Frame 
gepackt werden. Aber wie sieht das ganze aus bei nur einem Bulk-EP der 
daten vom Slave zum Host bringen will. Das muss er ja auch mit der 
(fast) vollen Bandbreite schaffen, wenn sonst keiner den Bus belegt.

[Christian R. (supachris)]

Pro Microframe können mehrere Pakete übertragen werden. Bei 2.0 
HighSpeed kommt man mit standard Host Controllern auch etwa 10...11 
volle Pakete pro Microframe, also 5120 Byte alle 125µs, was reichlich 
40MByte/s ergibt.

[Georg A. (Gast)]

> Aber wie sieht das ganze aus bei nur einem Bulk-EP der
> daten vom Slave zum Host bringen will.

Ob man die Restbandbreite nach den Isochronen und Interrupt-Transfers 
für einen EP-Transfer oder mit Roundrobin über alle gerade "aktuellen" 
EPs braucht, ist eine reine Policy-Frage. Das ist einfach "Depth-first" 
vs. "breadth-first". Das ging schon bei USB1.0 mit dem Intel-UHCI allein 
damit, wie man die Transferdeskriptoren im Speicher verknüpft.

UHCI ist zwar ziemlich "dumm", dafür sieht man einfachsten, wie die 
Transfers abgebildet werden:

http://etherboot.org/wiki/soc/2008/balajirrao/notes/uhci_design

Neuere Hostcontroller machen das mit der Aufteilung eines grossen 
Transfers auf die Pakete selbst...

[Jörg W. (dl8dtl) (Moderator)]

Tastkopf schrieb:
> Aber wie sieht das ganze aus bei nur einem Bulk-EP der
> daten vom Slave zum Host bringen will.

Anbei mal ein Screenshot eines (Hardware-)USB-Sniffers, da ich ihn
sowieso gerade in der Mache habe.  Es zeigt eine Speicherlese-
Operation von AVRDUDE über ein JTAGICEmkII.  Die dargestellte
OUT-Transaktion (ich hab' sie mal als Zeitreferenz genommen)
ist der Lesebefehl für einen Speicherblock.  Daraufhin denkt das
JTAGICE ein paar Millisekunden nach, es muss ja den Speicherblock
erstmal vom angeschlossenen AVR lesen.  Der Host versucht derweil
die ganze Zeit, Daten von IN zu lesen (da AVRDUDE ja das Lesen
einer Antwort verlangt), das wird ihm, solange das ICE noch keine
Daten hat, jeweils mit einem NACK beantwortet.  Nach etwa 7 ms
kommt die Antwort reingekleckert, bestehend aus 4 vollen Paketen
je 64 Bytes und einem fünften, kürzer ausfallenden.  (Es wurden
256 Byte Speicherdaten angefordert, aber die Antwort hat noch ein
wenig Overhead.)  Es ist gut zu sehen, wie sich die Datenpakete
ganz und gar nicht um die 1-ms-Frames kümmern müssen, da sie einfach
schnell genug nachgeliefert werden.