USB-Protokoll Verständnisfragen

[Daniel K. (daniel_k80)]

Hallo zusammen,

ich lese mich gerade etwas in das USB-Protokoll ein und möchte 
(demnächst) auch das USB auf dem XMega realisieren. Da ich bisher noch 
GAR KEINE Ahnung vom USB habe, habe ich mir diese Webseite 
herausgepickt:

http://www.usbmadesimple.co.uk

An für sich ist die Webseite auch sehr verständlich geschrieben (gut USB 
3 fehlt, aber ich möchte sowieso erst einmal mit Low Speed anfangen).

Bisher habe ich es so verstanden, dass das Gerät angesteckt und vom Host 
ein Reset durchgeführt wird. Danach sendet der Host ein Get_Descriptor 
um den Device Descriptor abzufragen (in Kapitel 4 beschrieben). Das 
ganze wird dann Setup Transaction genannt (Kapitel 3) und das komplette 
Paket vom Host zum Slave sieht dann so aus:

Sync-PID(Setup)-ADDR(0)-ENDP(0)-CRC5-EOP -> Sync-PID(DATA0)-DATA(Get_Descriptor)-CRC16-EOP -> Sync-PID(ACK)-EOP

Und die Daten für Get_Descriptor sehen wie folgt aus:

0x80 0x06 0x0000 0x0000 0x12

Der Slave antwortet dann darauf und sendet den Descriptor (als Data 
Packet oder in welchem Format?).
Ist das soweit korrekt?

Beim Token Packet wird als Adresse und Endpoint beim Setup immer 0 
gesendet, weil jedes neu angesteckte Device erst einmal diese Adresse 
hat und der Endpoint 0 für die Erstkonfiguration gedacht ist. Ist das 
korrekt?

Dann habe ich mir mal "Free Device Monitoring Studio" heruntergeladen um 
das ganze Spiel bei einer USB-Maus mitzuverfolgen. Was mich jetzt 
wundert ist, dass in den Artikeln auch noch von einem Set_Address 
gesprochen wird, ich dieses aber nicht sehe.
Es wird erst der Device-Descriptor abgerufen und dann ein 
Configuration-Descriptor. Wieso wird kein Set_Address gesendet?

Vielleicht kann mir ja jemand die paar Fragen eben beantworten :)

Vielen Dank schon mal
Gruß
Daniel

[Alex W. (Gast)]

Daniel K. schrieb:
> Hallo zusammen,
>
> und möchte
> (demnächst) auch das USB auf dem XMega realisieren.

Der ATxmega256A3U hat USB on Board! Bascom und (vermutlich) Arduino, 
können den USB direkt ansteuern. Ich habe USB schon mit den Mega8u2 und 
M32u4 gemacht. Geht problemlos.

Such dir für einen XMega ein paar Beispiele im Netz zusammen und teste 
einfach drauf los. Beim "Spielen" kommt das Verständniss automatisch.

[Jim M. (turboj)]

Daniel K. schrieb:
> An für sich ist die Webseite auch sehr verständlich geschrieben (gut USB
> 3 fehlt, aber ich möchte sowieso erst einmal mit Low Speed anfangen).

Da bist Du aber von der Hardware anhängig, und gängige µC mit Hardware 
USB laufen Full Speed. Das hat aber in der Praxis überraschend wenig 
negative Auswirkungen.

Schau Dir lieber mal den Beispiel Source Code an - es findet da nämlich 
etliches in Hardware statt, z.B. das ganze Token Gedöns, das den 
Programmierer dadurch überhaupt nicht interessiert.

Andererseits funktioniert USB ohne halbwegs korrektes Handling auf dem 
Control Endpoint 0(Null) nicht wirklich.

Daniel K. schrieb:
> Wieso wird kein Set_Address gesendet?

Das findet in gängigen USB Host Implementationen nach der Abfrage des 
Device Deskriptors statt. Könnte aber auch sein dass bei Dir schon ein 
Filter in der Paketansicht aktiv ist.

[Daniel K. (daniel_k80)]

Alex W. schrieb:
> Daniel K. schrieb:
>> Hallo zusammen,
>>
>> und möchte
>> (demnächst) auch das USB auf dem XMega realisieren.
>
> Der ATxmega256A3U hat USB on Board! Bascom und (vermutlich) Arduino,
> können den USB direkt ansteuern. Ich habe USB schon mit den Mega8u2 und
> M32u4 gemacht. Geht problemlos.
>
> Such dir für einen XMega ein paar Beispiele im Netz zusammen und teste
> einfach drauf los. Beim "Spielen" kommt das Verständniss automatisch.

Hallo,

ja, mein XPlained hat den USB auch herausgeführt. Daher möchte ich mich 
nun mal dran wagen. Ich habe mir bisher nur die Beispiele von Atmel 
angeschaut und die waren ein bisschen Overkill für mich. Daher fange ich 
lieber von unten an und gucke mal wie weit ich komme :)

Jim M. schrieb:
> Daniel K. schrieb:
>> An für sich ist die Webseite auch sehr verständlich geschrieben (gut USB
>> 3 fehlt, aber ich möchte sowieso erst einmal mit Low Speed anfangen).
>
> Da bist Du aber von der Hardware anhängig, und gängige µC mit Hardware
> USB laufen Full Speed. Das hat aber in der Praxis überraschend wenig
> negative Auswirkungen.
>
> Schau Dir lieber mal den Beispiel Source Code an - es findet da nämlich
> etliches in Hardware statt, z.B. das ganze Token Gedöns, das den
> Programmierer dadurch überhaupt nicht interessiert.
>
> Andererseits funktioniert USB ohne halbwegs korrektes Handling auf dem
> Control Endpoint 0(Null) nicht wirklich.
>
> Daniel K. schrieb:
>> Wieso wird kein Set_Address gesendet?
>
> Das findet in gängigen USB Host Implementationen nach der Abfrage des
> Device Deskriptors statt. Könnte aber auch sein dass bei Dir schon ein
> Filter in der Paketansicht aktiv ist.

Der XMega kann tatsächlich Low-Speed (einfach ein Bit setzen und mind. 
1.5 MHz Takt zur Verfügung stellen).
Das der Mikrocontroller das ganze Handling etc. alles macht und ich von 
dem ganzen Protokolloverhead nichts mitbekomme dachte ich mir bereits. 
Ich finde es (für mich gesehen) halt schön, auch etwas Hintergrundwissen 
mitzunehmen.

Ich habe den Datenverkehr noch einmal länger mitgeschnitten und das 
Adresshandling kommt dort gar nicht vor. Könnte es ggf. dran liegen, 
weil das Device bereits installiert ist und Windows dann einige Sachen 
auslässt? Ansonsten muss ich mal nach Filtereinstellungen suchen.

Edit meinte gerade, dass ich mal hier rein schauen soll:

http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_113_Simplified%20Description%20of%20USB%20Device%20Enumeration.pdf

S. 15 zeigt das sehr gut, wann die Adresse gesendet wird. Vielleicht 
habe ich sie auch einfach nur übersehen...

[Guido Körber (Gast)]

Ganz wichtig: Nicht darauf verlassen, dass die Requests in einer 
bestimmten Reihenfolge kommen. Ein USB-Device muss immer in der Lage 
sein jeden beliebigen Request zu beantworten den es unterstützt.

Andernfalls erlebt man Überraschungen mit verschiedenen 
Betriebssystemen, oder sogar verschiedenen Versionen des selben Systems.

[Niklas Gürtler (Gast)]

Da mach ich doch mal ganz unauffällig Werbung für mein [[USB-Tutorial 
mit STM32]], aber halt kein AVR. Tatsächlich macht viel die Hardware; im 
Wesentlichen hantiert man mit ganzen Paketen.

[Daniel K. (daniel_k80)]

Niklas Gürtler schrieb:
> Da mach ich doch mal ganz unauffällig Werbung für mein [[USB-Tutorial
> mit STM32]], aber halt kein AVR. Tatsächlich macht viel die Hardware; im
> Wesentlichen hantiert man mit ganzen Paketen.

Hast du da (netterweise) auch einen Link zu ;)?

[Niklas G. (erlkoenig)]

Mist, auf dem Handy geht der Link... Dann so:
https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32

[Mark (Gast)]

Sehr zu empfehlen ist das Buch 
https://www.amazon.de/USB-Complete-5th-Edn-Developers/dp/1931448280/

Leider kommt man manchmal nicht drum herum die Original-Standards zu 
lesen http://www.usb.org/developers/docs/. Daher ist es hilfreich sich 
mit denen schon einmal vertraut zu machen, für den Fall der Fälle. Dan 
ist der Schock nicht so groß wenn man reinsehen muss.

Und immer schön die Grundregel beim Implementieren von Protokollen 
beachten:

Sehr pingelig sein bei dem was man als Protokoll-Daten generiert, sehr 
nachsichtig sein was man als Protokoll-Daten akzeptiert.

[Thomas (Gast)]

>Dann habe ich mir mal "Free Device Monitoring Studio" heruntergeladen um
>das ganze Spiel bei einer USB-Maus mitzuverfolgen. Was mich jetzt
>wundert ist, dass in den Artikeln auch noch von einem Set_Address
>gesprochen wird, ich dieses aber nicht sehe.
>Es wird erst der Device-Descriptor abgerufen und dann ein
>Configuration-Descriptor. Wieso wird kein Set_Address gesendet?

SetAdress kommt immer! Vermutlich kann dieses Device Monitoring Studio 
den aber einfach nicht anzeigen weil die Software erst anspringt wenn 
die Addresse vergeben ist.
USB Reset kommt zumindest unter Win 2 mal. Hintergrund ist dass Win beim 
ersten GetDeviceRequest wLength=0x64 sendet. Zumindest in der 
Anfangszeit
von USB einige Devices mit sowas nicht klargekommen sind deshalb setzt 
WIN einfach noch mal den USB Reset ab. Dieses Verhalten unter WIN 
verhindert übrigens auch eine korrekt Implementierung des DFU Protokols

Linux macht das anders.
Dort wird der GetDeviceDescriptor zuerst mit wLenght 0x08 gesendet um 
die EP0  Fifo size zu ermitteln.
Du must einfach nur auf jeden Request korrekt antworten dann funzt das 
schon korrekt.
Achtung deine Antworten müssen in <fifosize> packets geschickt werden 
bis der Host den Transfer beendet. sind keine Daten mehr da zum senden 
muss ein short packet kommen.

Thomas