Hardware Reference
In-Depth Information
geschieht, indem ein STALL-PID an den Host übertragen wird, vorzugsweise wäh-
rend der nächsten Data Stage Transaktion des Control Endpoints [USB 2.0: 9.2.7].
In diesem Abschnitt werden nur die Standard Device Requests behandelt, die für
ein USB488-Gerät gültig sind. Der Firmware-Entwickler muss dafür sorgen, dass
alle weiteren (und nicht nur Standard Device) Requests, die das Gerät empfangen
mag, ordnungsgemäß mit einem Request Error beendet werden. Zusätzliche Infor-
mationen zu allen Standard Device Requests finden sich in dem bereits erwähnten
Abschnitt USB 2.0: 9.4 und den dort verzeichneten Querverweisen. Alle Requests
bestehen aus einem 8 Bytes langen Control Transfer in den Control-OUT Endpoint
desGerätsmitderfolgendenBedeutung:
bmRequestType
Das erste Byte im Control-OUT Endpoint sagt etwas über den Typ des Requests aus
[USB 2.0: 9.3.1]. Es hat den im Bild dargestellten Aufbau.
Aufbau des Datenfelds bmRequestType:
D7 D6 D5 D4 D3 D2 D1 D0
Richtung Typ
Empfänger
Bedeutung der Bits von bmRequestType:
D7
Hier wird die Übertragungsrichtung für die Daten in der zweiten Phase des Control
Transfers (Data Stage) angezeigt.
D7
Übertragungsrichtung
0
vom Host zum Device (Request im Sinne von „Aufforderung“)
1
vom Device zum Host (Request im Sinne von „Abfrage“)
D6, D5
Diese Bits zeigen an, um welche Art Request es sich handelt. Als Class specific
Requests werden im Folgenden auch noch die Requests behandelt werden, die der
Geräteklasse USBTMC sowie der Unterklasse USBTMC-USB488 zugeordnet sind.
Vendor specific Requests, also spezielle Requests, die der Hersteller eines Geräts fest-
gelegt hat, gibt es bei USBTMC-USB488-kompatiblen Geräten grundsätzlich nicht.
D6 D5 Art des Requests
00 ta ard evice e est
0
1
Class specific Request
1
0 VendorspecificRequest
1
1
Reserviert
