USB Controllers Code Examples
USB Controllers Code Examples 子类别
This example implements a Bulk-only UVC 1.1 compliant example which illustrates the use of the CX3 APIs using an Aptina AS0260 Sensor.
This example streams Uncompressed 16-Bit YUV video from the image sensor over the CX3 to the host PC which can be viewed using a viewer such as AmCap or the Windows 8 Camera App.
This example has been tested against the Microsoft Windows UVC 1.1 host drivers available on Windows 7 and Windows 8.
The following resolutions are implemented:
- Super Speed USB 3.0:
- 1920 x 1080 @ 30 Frames per second.
- 1280 x 720 @ 55 Frames per second.
- High Speed USB 2.0:
- 640 x 480 @ 60 Frames per second.
- 320 x 240 @ 90 Frames per second.
- Full Speed USB:
- 320 x 240 @ 05 Frames per second.
The example enumerates with the VID/PID 04B4/00C3.
This example does not currently implement any UVC functions (Brightness, Contrast, Exposure etc.)
Note: This example will only correctly stream if built in Release configuration. Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example implements a USB video class (webcam) device that streams a set of 2 MJPEG frames repeatedly to the USB host over BULK Endpoint.
The MJPEG video frames are stored in the memory of the FX3 device as constant data.
The example does not support full-speed operation.
This example application demonstrates the following:
- The usage of the FX3 USB APIs to implement a standard USB video class device. The application shows how class specific USB control requests can be processed at the application level.
- Configuration and data transfer setting through an bulk endpoint.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a data loopback application over a pair of USB bulk endpoints.
The device enumerates as a vendor specific USB device with a pair of bulk endpoints (1-OUT and 1-IN). The application loops back any data that it receives on the bulk OUT endpoint on the bulk IN endpoint.
The loopback is achieved with the help of a DMA AUTO channel which is created connecting the two endpoints. There is no FX3 CPU involvement in the data transfer, and the loopback is performed automatically by the FX3 device hardware.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a Virtual COM Port or USB-UART Bridge. The implementation adheres to the CDC-ACM class and allows data communication from USB through to the UART port on the FX3 device.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a debug log mechanism over the USB interface.
The device enumerates as a vendor specific USB device with a single interrupt endpoint (EP1-IN). The application sends out periodic log information out on the USB interface. The length of log can be up to 256 bytes for Super speed and 128 bytes for High speed. So the user should never request for data transfer of size less than the length mentioned above.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a data source and data sink over a pair of USB Bulk endpoints.
The device enumerates as a vendor specific USB device with a pair of Bulk endpoints (1-OUT and 1-IN). The OUT endpoint acts as data sink and the IN endpoint acts as data source to the PC Host.
The source and sink is achieved with the help of a a DMA MANUAL IN Channel and a DMA MANUAL OUT Channel.
Any data received from the host through the DMA MANUAL IN channel is discarded. A constant data pattern is continuously loaded into the DMA MANUAL OUT channel and sent to the host.
The application also supports a set of vendor commands on the control endpoint. These are used to demonstrate the vendor command handling as well as to test cases like repeated USB connection, device reset etc.
Performance Optimizations
The default example is not optimised for performance in USB 3.0, in order to get better performance the following changes has to be done.
- Have only one endpoint (IN or OUT) This avoids any USB host bandwidth issues.
- Update the burst length to maximum burst value supported by the USB SS host This can be done by modifying the CY_FX_EP_BURST_LENGTH field (1 - 16) in cyfxbulksrcsink.h. Updating this value will change the DMA buffer size for all speeds. The bursting will be done only for USB super speed operation.
- The firmware latencies can be minimized by having a larger buffer. This can be done by changing the multiplier defined by CY_FX_DMA_SIZE_MULTIPLIER in cyfxbulksrcsink.h. When making these changes, make sure that there is enough memory available for buffering.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a USB I2C EEPROM programming example.
The device enumerates as a vendor specific USB device with only the control endpoint and provides a set of vendor commands to read/write the data on I2C EEPROM devices.
- Read Firmware ID
bmRequestType = 0xC0 bRequest = 0xB0 wValue = 0x0000 wIndex = 0x0000 wLength = 0x0008 Data response = "fx3 i2c"
- Write to I2C EEPROM
bmRequestType = 0x40 bRequest = 0xBA wValue = I2C EEPROM Slave Address (Can be in the 0 to 7 range, must be set according to the EEPROM address switch SW40) wIndex = EEPROM byte address (can vary from 0x0000 to 0xFFFF. The max address is capped by the EEPROM max size) wLength = Length of data to be written (Should be a multiple of 64 and less than or equal to 4096) Data phase should contain the actual data to be written.
- Read from I2C EEPROM
bmRequestType = 0xC0 bRequest = 0xBB wValue = I2C EEPROM Slave Address (Can be in the 0 to 7 range, must be set according to the EEPROM address switch SW40) wIndex = EEPROM byte address (can vary from 0x0000 to 0xFFFF. The max address is capped by the EEPROM max size) wLength = Length of data to be read (Should be a multiple of 64 and less than or equal to 4096) Data phase will contain the data read from the EEPROM
Note: bmRequestType, bRequest, wValue, wIndex, wLength are fields of setup packet. Refer USB specification for understanding format of setup data.
Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3 firmware APIs to implement a USB SPI flash programming example.
The device enumerates as a vendor specific USB device with only the control endpoint and provides a set of vendor commands to read/write the data on SPI flash devices.
A SPI flash write requires the following sequences:
- Erase the required sector: CY_FX_RQT_SPI_FLASH_ERASE_POLL with wValue as 1 and length as 0.
- Wait for erase to complete: CY_FX_RQT_SPI_FLASH_ERASE_POLL with wValue as 0 and IN length as 1. Repeat this until the returned value has WIP zero.
- Write data to page: CY_FX_RQT_SPI_FLASH_WRITE with correct parameters.
- Wait for write to complete: CY_FX_RQT_SPI_FLASH_ERASE_POLL with wValue as 0 and IN length as 1. Repeat this until the returned value has WIP zero.
Vendor Commands implemented:
- Read Firmware ID
bmRequestType = 0xC0 bRequest = 0xB0 wValue = 0x0000 wIndex = 0x0000 wLength = 0x0008 Data response = "fx3 spi"
- Write to SPI flash
bmRequestType = 0x40 bRequest = 0xC2 wValue = 0x0000 wIndex = SPI flash page address (Each page is assumed to be of 256 bytes and the byte address is computed by multiplying wIndex by 256) wLength = Length of data to be written (Should be a multiple of 256 and less than or equal to 4096) Data phase should contain the actual data to be written
- Read from SPI flash
bmRequestType = 0xC0 bRequest = 0xC3 wValue = 0x0000 wIndex = SPI flash page address (Each page is assumed to be of 256 bytes and the byte address is computed by multiplying wIndex by 256) wLength = Length of data to be read (Should be a multiple of 256 and less than or equal to 4096) Data phase will contain the data read from the flash device
- Erase SPI flash sector
bmRequestType = 0x40 bRequest = 0xC4 wValue = 0x0001 wIndex = SPI flash sector address (Each sector is assumed to be of 64 KB and the byte address is computed by multiplying wIndex by 65536) wLength = 0x0000 No data phase is associated with this command.
- Check SPI busy status
bmRequestType = 0xC0 bRequest = 0xC4 wValue = 0x0000 wIndex = 0x0000 wLength = 0x0001 Data phase will indicate SPI flash busy status
0x00 means SPI flash has finished write/erase operation and is ready for next command.
Non-zero value means that SPI flash is still busy processing previous write/erase command.
Note: bmRequestType, bRequest, wValue, wIndex, wLength are fields of setup packet. Refer USB specification for understanding format of setup data.
Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
BootLedBlink Example shows the usage of the FX3 boot API to sample Switches and control GPIOs.
The application senses the state of the GPIO45 pin on the FX3 part and drives the same value out on the GPIO54 pin. If the Infineon SuperSpeed Explorer Kit is used, the SW2 switch can be used to control the state of the LED2 pin.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3S firmware APIs to implement a mass storage class device that allows access to SD/MMC devices connected to FX3S.
The application partitions the storage device found on each of the storage ports into two volumes, and then enumerates them as separate logical units on the USB side. The application also demonstrates the use of the delayed write commit option to optimize write performance to the storage device.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
This example illustrates the use of the FX3S firmware APIs to implement a RAID-0 system based on SD/MMC storage devices.
The RAID-0 implementation allows two storage devices (similar SD cards or eMMC devices) to be used as a higher performance single storage volume. The performance improvement is achieved by striping the user data across the two devices.
A USB Mass Storage Class (MSC) application that provides access to this RAID-0 disk is provided.
As the RAID-0 system is only viable when two good storage devices are available, this application will only function when both devices are present. The application does not support any hotplug operation either, as replacing one of the devices in a striped volume will cause data corruption.
This application uses a logical block size of 4 KB for the RAID-0 disk. As FX3S is not capable of splitting data from a single data buffer into two output pipes, the DMA buffer size used for this application has to match the desired logical block size. This value can be controlled using the CY_FX_RAID_BLOCK_SIZE parameter in the cyfx3s_raid0.h. The minimum supported value for this parameter is 1 KB.
Note: Pre-built binaries are provided in the Release and Debug folders in the zip file. FX3 SDK should be installed in the system to rebuild the example project with any modifications made.
-
USB device interface driver
-
Support for interrupt and control transfer types
-
Setup wizard for easy and accurate descriptor generation
-
Runtime support for descriptor set selection
-
Optional USB string descriptors
-
Optional HID class support
-
Optional PS/2 support for USB-PS/2 combination devices (Note: PS/2 is not supported on CYRF69xx3 devices)
Functional Description
The USB Device User Module provides a USB Chapter 9 compliant device framework. The user module gives a low level driver for the control endpoint that decodes and dispatches requests from the USB host. The user module supports the HID Class. USB descriptors can be configured with the USB Setup Wizard.
This project implements a DVK board–based keyboard using the USB Human Interface Device (HID) class. The DVK buttons and 7-segment bars implement the keyboard functions shown in table below.
DVK | Keyboard Function |
---|---|
f1 button | Shift key |
f2 button | ‘a’ key |
f3 button | ‘b’ key |
f4 button | ‘c’ key |
7-seg top | Screen lock light |
7-seg middle | Caps lock light |
7-seg bottom | Num lock light |
After you use the USB Control Center to load the hid_kb.hex file into the FX2LP board, the FX2LP board re-enumerates as a standard Windows keyboard. Any active window that accepts text will show the key presses implemented by this application. Press the Screen Lock, Caps Lock and Num Lock keyboard keys and observe that three of the 7-segment bars light along with the keyboard indicators.
Note: To modify and rebuild the project, you need Keil μVision2 IDE that is also provided with the FX2LP DVK. The DVK setup can be downloaded from CY3684 EZ-USB FX2LP Development Kit.
This program demonstrates the maximum throughput that can be achieved over a USB 2.0 interface with the help of the Windows Streamer application. Both bulk and ISO transfers are supported.
Note: To modify and rebuild the project, you need Keil μVision2 IDE that is also provided with the FX2LP DVK. The DVK setup can be downloaded from CY3684 EZ-USB FX2LP Development Kit.
The USB specification provides a mechanism, called “vendor requests,” to create your own custom USB commands. This project shows how to implement these requests. Application note AN45471 contains detailed information. Using this project with the USB Control Center, you can do things like sending packets from the PC to the FX2LP board to update the onboard LEDs and 7-segment readout.
Note: To modify and rebuild the project, you need Keil μVision2 IDE that is also provided with the FX2LP DVK. The DVK setup can be downloaded from CY3684 EZ-USB FX2LP Development Kit.