IMPLEMENTING A SIMPLE USB INTERFACE FOR AN EMBEDDED PROCESSOR

THE MAGAZINE FOR COMPUTER APPLICATIONS Circuit Cellar Online offers articles illustrating creative solutions and unique applications through complete projects, practical tutorials, and useful design techniques.

	IMPLEMENTING A SIMPLE USB INTERFACE
FOR AN EMBEDDED PROCESSOR by Stuart Allman Start ı Typical USB Solutions ı Required Components ı An Easier Solution ı Following the Rules ı Firmware ı Vendor-Specific Requests ı Host Transfer Mechanisms ı USB Transfers ı How Does It Work? ı The Grand Conclusion ı Sources and PDF USB TRANSFERS The example application for this project uses three types of USB transfersıbulk out, bulk in, and a number of vendor-specific requests formatted as control read and no-data control transfers. They are defined as follows: ı Bulk outıthe computer sends information to the peripheral using a bulk endpoint ı Bulk inıthe peripheral sends information to the computer using a bulk endpoint ı Control readıthe computer requests specific data on endpoint 0, and the peripheral returns the requested data on endpoint 0 ı No-data controlıthe computer sends a control parameter to the peripheral on endpoint 0. A zero length acknowledgment packet is sent by the peripheral to the computer on endpoint 0. The bulk out transfers occur by specifying endpoint 2, the transfer mechanism, and data buffer location to a DeviceIOControl() function call. Note that the bulkControl.pipeNum parameter is zero-based, so you need to write a value of one to this parameter. The rest of the parameters are constants sent to the driver to specify a bulk out transfer, output buffer, and the result of the transaction. When the transfer has completed or if there was an error in transmission, the DeviceIoControl() function will return with the result in iResult (see Listing 1). Bulk in transfers are similar, except they specify the constants for a bulk in transaction and a buffer to capture data. Note that the function call specifies to get 32 bytes, which is the endpoint size of the CY7C64013. If the device returns 32 bytes or less, this function will return with the number of bytes captured in numBytesReturned (see Listing 2). Control read transfers are a bit different in that you fill a VENDOR_OR_CLASS_REQUEST_CONTROL structure and specify a vendor-specific request to the DeviceIoControl() function call. In Listing 3, the vendor_request structure is specifying the parameters to perform a control read for the GET_IO request. The request should return one byte in the buffer parameter. The last transfer type used in the example application is a no-data control transaction used during a SET_IO command. The transfer parameters are basically the same as a control-read, only the direction is changed to host-to-device. In this case, no data is returned from the peripheral. The peripheral simply returns a zero length packet to acknowledge that it received the request (see Listing 4). The other transfer types that are available with this driver are isochronous, interrupt, and control writes. The EZ-USB driver documentation describes how to use these, so I will leave these transfer types for you to explore. PREVIOUS • NEXT Circuit Cellar provides up-to-date information for engineers. Visit www.circuitcellar.com for more information and additional articles. For subscription information, call (860) 875-2199, subscribe@circuitcellar.com or subscribe online. ıCircuit Cellar, the Magazine for Computer Applications. Posted with permission.