Ports and Interfaces > USB

USB Communication protocol

<< < (2/2)

Limited_Atonement:
Okay, I think all is well and I understand.


--- Quote ---device firmware might not bother checking the direction bit in bmRequestType
--- End quote ---

I suppose I'm just quibbling about custom protocol practice now, but if the control type defines a direction, you're forfeiting requests.  In the case that you want lots of request types, and you want to pass the two parameters vValue and wIndex, all you have is a BYTE for bmRequestType and a BYTE for bRequest.  You can double the amount of messages you can sent if you rely on bmRequestType bit 7 (direction) so that bRequest 0x00 is a particular request with device-to-host, and a completely different request if bmRequestType specifies host-to-device.

Is this a violation of the conventions?  As I'm writing this, I see that there is almost no way that you could run short on message types (especially since with parameter-less requests, you could specify another two WORDs-worth of different commands, and one WORD with single-parameter requests!).

Thanks again for your time.

Jan Axelson:
9.3.1 in the USB 2.0 spec says

bmRequestType
This bitmapped field identifies the characteristics of the specific request. In particular, this field identifies
the direction of data transfer in the second phase of the control transfer.

To me that suggests that each request has a single direction for the Data stage.

I don't recall ever seeing a bRequest that supports both directions depending on bmRequestType. The USB spec has Get_Descriptor and Set_Descriptor, Get_Configuration and Set_Configuration, Get_Interface and Set_Interface. HIDs have Get_Report and Set_Report.

Classes that support many different requests tend to use a different transfer type. For example, mass storage uses bulk transfers to send SCSI commands.

Jan

Bret:

--- Quote ---I don't recall ever seeing a bRequest that supports both directions depending on bmRequestType. The USB spec has Get_Descriptor and Set_Descriptor, Get_Configuration and Set_Configuration, Get_Interface and Set_Interface. HIDs have Get_Report and Set_Report.
--- End quote ---

I don't recall seeing a real device that ever did that either, and certainly the standard requests separate even pairs of "related" IN's and OUT's with distinct bRequests.  But, I don't think it's a violation of the spec to "reuse" a bRequest number for multiple purposes.  In fact, the design appears to have the intent of requiring the total combination of bmRequestType and bRequest to determine the request, not just one or the other.


--- Quote ---Classes that support many different requests tend to use a different transfer type. For example, mass storage uses bulk transfers to send SCSI commands.
--- End quote ---

Absolutely correct.  If you're trying to control a device that requires lots of different types/combinations/sizes of data to be sent back and forth, USB control requests would probably be a poor choice, for a number of reasons.

Navigation

[0] Message Index

[*] Previous page