| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
| Panel | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
The vendor requests are also another way to communicate with the host. When managing vendor requests sent by the host, the application can receive or send data from or to the host using the control endpoint. For that, you will need to provide an application callback passed as a parameter of USBD_Vendor_Add .
...
Synchronous communication means that the transfer is blocking. Upon function call, the application blocks until the transfer completes with or without an error. A timeout can be specified to avoid waiting forever.
Listing - Synchronous Bulk Read and Write Example presents a read and write example to receive data from the host using the bulk OUT endpoint and to send data to the host using the bulk IN endpoint.
...
The use of interrupt endpoint communication functions, USBD_Vendor_IntrRd() and USBD_Vendor_IntrWr(), is similar to bulk endpoint communication functions presented in Listing - Synchronous Bulk Read and Write Example.
Asynchronous Communication
Asynchronous communication means that the transfer is non-blocking. Upon function call, the application passes the transfer information to the device stack and does not block. Other application processing can be done while the transfer is in progress over the USB bus. Once the transfer has completed, a callback function is called by the device stack to inform the application about the transfer completion. Listing - Asynchronous Bulk Read and Write Example shows an example of asynchronous read and write.
...
The use of interrupt endpoint communication functions, USBD_Vendor_IntrRdAsync() and USBD_Vendor_IntrWrAsync(), is similar to bulk endpoint communication functions presented in Listing - Asynchronous Bulk Read and Write Example.
Vendor Request
The USB 2.0 specification defines three types of requests: standard, class and vendor. All standard requests are handled directly by the core layer. Any class request will be managed by the proper associated class. The vendor request may be processed by the vendor class. You must provide an application callback as a parameter of USBD_Vendor_Add (as shown in Listing - Vendor Class Initialization Example) to be able to process one or more vendor requests. Once a vendor request is received by the USB device, it must be decoded properly. Listing - Example of Vendor Request Decoding shows an example of vendor request decoding. Certain request may require to receive or send from or to the host during the data stage of a control transfer. If no data stage is present, you just have to decode the Setup packet. This example shows the three types of data stage management: no data, data OUT and data IN.
...
The host sends vendor requests using the function USBDev_CtrlReq(). Refer to the page USBDev_API for more details about how to send vendor requests on the host side.
...