Linux comes with USB drive, why do you need LIBUSB?

The software in Linux is divided into two types: User layer and Kernel layer. For example, the kernel compiles the driver of the temperature sensor, and the lm-sensors is responsible for interpreting the data submitted by the processing kernel at the user level. USB drive is a hardware-driven thing, and Libusb is a library that is provided for application development and USB drive interoperability (reading USB content at the bottom).

Drive development has always been the most workload in the kernel development, with the popularity of USB devices, a large number of USB device driver Development has become the most to drive developers to do the most things. This article mainly describes the Linux platform based on the development of Libusb, hoping to be engaged in the development of Linux-driven friends to bring some help, but also hope that other platforms on the non-drive design to bring some help. 　　The article is I in the work use LIBUSB some summary, inevitably has the mistake, if has the improper place, also please correct me. USB drive development on Linux platforms, mainly kernel-Driven developmentAnd LIBUSB-based non-flooding design。 For most of the kernel-driven devices, such as HID devices with USB interfaces, Linux itself has its own driver, so we can do most of the operation of the device by manipulating the device files ., and other devices, such as the hardware products that we have designed, require our driver engineers to develop relevant drivers.　　Kernel driver has its advantages, however, the kernel driver in some cases will encounter some of the following problems: 1, when the use of our products customers have 2.4 core platform, but also has 2.6 core platform, we want to design the driver is to be compatible with two platforms, even makefile we have to write two. 2, when we want to transplant Linux into the embedded platform, you will find that the original Linux drive is still quite large, my kernel is of course the smaller the better pull, so it is necessary. This is not the most depressing place, if the embedded platform is the customer, customers want to buy your products, you suddenly found that the customer device system and your environment is not the same, it does not have the driver you want, your program can not run, you will first think: "It's OK, I write a kernel driver to load a bit of the line." But found that the customer even Insmod loading module tools are not ported, then you look at God, said I how so unlucky ah, customers do not want you to move he spent N time to transplant the kernel Oh 3, took some kung Fu wrote a new product driver, quite a sense of accomplishment ah, code quality is also quite standard AH. Just as you indulge in your code, customer service constantly mail, "customer needs 2.6.5 kernel Driver, config file I have sent you" "Customer needs dual-core 2.6.18-SMP driver" "Customer's platform is their own custom is 2.6.12-xxx" You would like to give the driver source code to the customer, so as not to compile. 　　Part of your work time to compile the kernel, custom drive. There is a problem, there will be a way to solve the problem of the people, the emergence of LIBUSB brought us some convenience, that is to save our time, but also reduce the cost of the company. So in some cases, you can consider using Libusb's non-flooding design.　　below we will discuss in detail libusb, and to write a HID device driver to explain how to use LIBUSB, as for the article involved in the knowledge of the USB protocol, limited to length, it is not explained in detail, the relevant can be self-view USB-related protocol. LIBUSB Introduction Libusb designed a series of external APIs called by the application, through which the API application can manipulate the hardware, from the source code of LIBUSB can be seen, these APIs call the kernel of the underlying interface, and kernel The functions used in driver are similar in function, just libusb closer to the USB specification. This makes the use of libusb much easier than developing kernel drivers. Libusb Compile and install please check the Readme, here does not do a detailed two LIBUSB external interface 2.1 Initialize the device interface These interfaces can also be called core functions, which are primarily used to initialize and find related devices. usb_init function definition: void usb_init (void); From the function name you can see that this function is used to initialize the relevant data, this function as long as you have to remember that must be called on the line, and is to be called at the beginning. usb_find_busses function definition: int Usb_find_busses (void); Look for the USB bus on the system, and any USB device communicates via USB bus and computer bus. And then communicate with other devices. This function returns the number of buses. usb_find_devices function definition: int usb_find_devices (void), looking for a USB device on the bus, this function must be used after calling Usb_find_busses (). The three functions above are all used at the beginning, and this function returns the number of devices. usb_get_busses function definition: struct Usb_bus *usb_get_busses (void); This function returns the list of buses, which are not available in the higher versions, as explained in the following example 2.2 operating device interfaces Usb_ Open function Definition: usb_dev_handle *usb_open (struct *usb_device dev); Turn on the device you want to use, you have to call Usb_open to open the device before you operate on the hardware, and here you see two structures   Usb_dev_handle and Usb_device are often encountered in our development, and it is necessary to take a look at their structure. There are definitions in usb.h and usbi.h in Libusb. Here we may as well understand that the return usb_dev_handle  pointer is a handle to the device, and the input in the row parameter is the device that needs to be opened. usb_close function definition: int usb_close (Usb_dev_handle *dev), relative to Usb_open, turning off the device is a mustCalled, returns 0 success, <0 failed. usb_set_configuration function definition: int usb_set_configuration (usb_dev_handle *dev, int configuration), set the configuration used by the current device , the parameter configuration is the Bconfigurationvalue in the configurtation descriptoes that you want to use, returning 0 success, <0 failure (a device may contain multiple configuration, For example, supporting both high-speed and low speed devices have a corresponding two configuration, detailed view of the USB standard) Usb_set_altinterface function definition: int usb_set_altinterface (Usb_dev_handle * dev, int alternate); As the name implies, this function sets the interface descriptor for the current device configuration, and the parameter alternate refers to interface in descriptor balternatesetting. Return 0 success, <0 failure usb_resetep function definition: int usb_resetep (usb_dev_handle *dev, unsigned int EP), reset specified endpoint, parameter EP It means bendpointaddress,. This function is not used frequently and is replaced by the Usb_clear_halt function described below. Usb_clear_halt function definition: int usb_clear_halt (usb_dev_handle *dev, unsigned int EP), reset specified endpoint, parameter EP refers to Bendpointaddress. This function is used to replace the Usb_resetepusb_reset function definition: int usb_reset (Usb_dev_handle *dev), this function is not very useful now, but here I also say, as the name of the meaning, This function resets the device, since restarting the device or re-opening the device, so with Usb_close can already meet the requirements. usb_claim_interface function definition: int usb_claim_interface (usb_dev_handle *dev, int interface), register interface with operating system communication, this function must be called, because only the registered interface can do the corresponding operation. Interface refers to Binterfacenumber. (The usb_release_interface described below, which corresponds to it, is also a function that must be called) usb_release_interface function definition: int usb_release_interface (Usb_dev_handle * dev, int interface), unregister the interface after being called by the Usb_claim_interface function, release the resource, and use the Usb_claim_interface counterpart. 2.3 Control Transport Interface usb_control_msg function definition: int usb_control_msg (usb_dev_handle *dev, int requesttype, int request, int value, int index , char *bytes, int size, int timeout), send and receive control data from the default pipe usb_get_string function definition: int usb_get_string (usb_dev_handle *dev, int Inde x, int langid, char *buf, size_t buflen); usb_get_string_simple function definition: int usb_get_string_simple (usb_dev_handle *dev, int in Dex, Char *buf, size_t buflen); Usb_get_descriptor function definition: int usb_get_descriptor (Usb_dev_handle *dev, unsigned char type, UN Signed char index, void *buf, int size), usb_get_descriptor_by_endpoint function definition: int usb_get_descriptor_by_endpoint (Usb_dev _handle *dev, int EP, unsigned char type, unsigned char index, void *buf, int size); 2.4 Batch Transport interface usb_bulk_write function definition: int usb_b Ulk_write (Usb_dev_handle *dev, int EP, char *bytes, int size, int timeout); Usb_interrupt_read function definition: int usb_interrupt_read (Usb_dev_handle *dev, in T EP, char *bytes, int size, int timeout); 2.5 Interrupt Transport interface Usb_bulk_write function definition: int usb_bulk_write (Usb_dev_handle *dev, int EP, CH AR *bytes, int size, int timeout), usb_interrupt_read function definition: int usb_interrupt_read (Usb_dev_handle *dev, int EP, Char *bytes, int size, int timeout);

Linux comes with USB drive, why do you need LIBUSB?