libusb is an open source library that helps developers communicate with UBS devices at the user's level. If you want to know more, you can view their home page: http://libusb.org/
In its documentation, it is recommended that you first read the USB2 specification: http://www.usb.org/developers/docs/, which can help you really understand how USB works.
You can get the source code from the official home page and compile and install it. Or the use of the release already contains a package that can be easily installed.
If the installation is complete, please continue
The communication between the device and the client is a clear idea called the use of the pipeline. Each pipe is a host on a software and an endpoint on the device. Each endpoint performs a specific target for the device, such as accepting commands or transferring data. A full-speed device can have up to 16 endpoints, and then the low-speed device has only three endpoints.
All USB devices support port 0 when powered. This port is the default target pipe. When the device connection is detected, the USBD software uses port 0 to initialize the device, perform a normal (non-special) configuration, and obtain information about other endpoints provided by the device. Endpoints are characterized by their number of endpoints (depending on the time of design), bus broadband, access frequency, latency, and processing error requirements.
Once the endpoint in the device is identified and configured, the pipeline will allow the client software to communicate with the device. Contact with a pipe is to describe the characteristics of the bus access and bandwidth, the type of transmission, the direction of transmission and the maximum data load size.
USB defines four transmission modes: control transmission, usually used to transfer commands and status operations; interrupt transmission, through the device to initialize some requests from the host; synchronous transmission, used to transmit the key events of the data (such as video and dialogue); Batch transmission, using all available bandwidth but not a specific time. All digital transmissions use the same format of packaging, including control information, data and error validation areas.
There are two types of pipes: the message pipe and the pipeline. Control the transmission using the message pipe. In the message pipeline, the data portion in each package is meaningful for the USB system software.
The pipeline is interrupted for transmission, synchronous transmission and batch transmission. In the stream pipeline, the data portion of each packet is meaningless for USB, and is only transmitted between the client software and the device.
The synchronous interface allows you to call a USB transfer using a single function. When this function call returns, the transfer is already completed and the result is returned for parsing. The advantage of this approach is very clear: you can do anything with a simple function call.
Nevertheless, this interface still has its limitations. Your program will go into sleep when libusb_bulk_transfer () (when bulk transmission) until the transfer is complete. If it takes three hours, your program also needs to sleep the same time. The implementation will end in the library, the overall thread during this period is useless. Another problem is that when a single transfer thread ends, there is no need for multiple endpoints and multiple devices to perform I / O operations at the same time, unless you create a new thread. In addition, there is no chance that the transmission will be canceled when the request is submitted.
Equipment and interfaces:
In libusb, each USB device operates through the libusb_device and libusb_device_handle objects. The libusb API connects an open device to a specific interface. This means that if you request multiple interfaces on the device, you have to open the device several times to accept a libusb_dev_handle, which corresponds to the interface you want to communicate with each other. Do not forget to call libusb_dev_handle.
What does this mean? This means that you can complete the request interface before you can operate on the device. Similarly, you can release the interface before completing the device operation.
Each device has its own configuration, such as vendor id, product id and so on. We use these settings to find the required devices and work through these configurations. First we write a function to find out the configuration and print it out so that we can find the right one; our basic operations are as follows:
1. Initiate a library by calling libusb_init and create a conversation at the same time;
2. Call libusb_get_device_list to get the queues of the connected devices. This will create an array of libusb_device that contains all the usb devices connected to the system;
3. Loop through all the devices to check their options;
4. Find one of them, use libusb_open or libusb_open_device_with_vid_pid (when you know the device vendor id and product id) to open the device;
5. Use libusb_free_device_list to clear the queues obtained with libusb_get_device_list;
6. Request interface via libusb_claim_interface (requires you to know the interface value of the device);
7. Operate the desired I / O;
8. Release the device via libusb_release_interface;
9. Turn off your previously opened device with libusb_close;
10. Close the conversation pc sync via usb libusb_exit;
PS: English need hard training ah, a short tutorial article to see the stuttering