Writing a driver for a USB device. Pipe 0: what is usb?
It so happened that I had to write from scratch a driver for usb display under windows. Having the opportunity - I will tell about the details of such an entertaining process.
So, why is the usb bus so convenient, and that hides behind the word Universal in decoding the abbreviation.
Previously, when the programmer had to write a driver to communicate with the device, he worked directly at the bus level, roughly speaking, if the device was connected with a 9-wire cable, because two of them are usually diverted under power - then the programmer was manually forced to control up to 7 cores. Each device had its own idea of how to use the port provided to it. For example, one device could transfer data to a computer through 1, 2 and 5 conductors, use 3 and 7 for control, and 4 and 6 would be used to write data to a device, another device could have 2 conductors for data transfer in both directions and 5 for control signals.
All this was necessary to control in time, waiting for the reaction or readiness of the device. If the device performed more than one type of activity, it was necessary to know what functionality we are working with at the moment and, proceeding from this, to change the methods of work. In such conditions, debugging was hard, and the programmer needed to learn his own protocol for communication on this port for each device. All this could not go on forever, and the usb bus was invented.
')
On the first line of defense we are waiting for the interface level, this is a logical separation of the device according to the tasks it performs, for example, if we have an external display equipped in addition with an audible warning system - our device may well have a couple of interfaces, one to work with the display, the other for work with sound, and, for example, the third - for flashing the device itself.
If we consider writing a driver under windows using the latest driver framework (WDF), then we can find out the number of interfaces and access them using a couple of lines of code.
The interface is not the only level of separation existing in USB; each interface is divided into a set of so-called endpoints.
Suppose that we can both record a picture on the display - and read the current picture from the display; in this case, one end point will be used for reading, the other - for writing. In addition to the direction of data transmission (In / Out), the endpoint has another quite useful property, it is a type of transmission that has one of the following values:
• control transfers — used by the host to configure the device during connection, to control the device, and to receive status information during operation. The protocol provides guaranteed delivery of such parcels;
• Bulk Data Transfers - they are applied when it is necessary to ensure guaranteed delivery of data from the host to the function or from the function to the host, but the delivery time is not limited;
• interrupt transmissions — used when small, single data packets need to be transmitted. Each packet is required to transfer for a limited time. Transmission operations are spontaneous and must be serviced no slower than the device requires;
• isochronous transmissions - are used for data exchange in “real time” when a strictly defined amount of data is required to be transmitted at each time interval, but information delivery is not guaranteed (data transmission is carried out without repetition in case of failures, packet loss is allowed).
In addition to the end points defined directly by the device logic, one (zero) end point is determined directly by the protocol, any usb device must have a zero end point. Due to this, as soon as you connect the device to the computer - the operating system immediately recognizes the name of this device, and tries to find a driver for it, without this standard endpoint, it would be impossible to obtain information about the device in the absence of a driver.
This is all you need to know about the bus in order to write your first driver, which we will do in the next article.
Driver Development Kit for Windows XP, Vista, 7 Operating Systems - can be downloaded here: developer kit.
In the next part: handling of events related to the device, working with the backlight from the application, and a little reverse engineering.
Photo of the future patient:
USB is simple
Despite the fact that writing drivers is considered quite difficult compared to application programming - and in this low-level world programmers were not deprived of attention, the development of the usb bus was a big step in simplifying driver creation.So, why is the usb bus so convenient, and that hides behind the word Universal in decoding the abbreviation.
Previously, when the programmer had to write a driver to communicate with the device, he worked directly at the bus level, roughly speaking, if the device was connected with a 9-wire cable, because two of them are usually diverted under power - then the programmer was manually forced to control up to 7 cores. Each device had its own idea of how to use the port provided to it. For example, one device could transfer data to a computer through 1, 2 and 5 conductors, use 3 and 7 for control, and 4 and 6 would be used to write data to a device, another device could have 2 conductors for data transfer in both directions and 5 for control signals.
All this was necessary to control in time, waiting for the reaction or readiness of the device. If the device performed more than one type of activity, it was necessary to know what functionality we are working with at the moment and, proceeding from this, to change the methods of work. In such conditions, debugging was hard, and the programmer needed to learn his own protocol for communication on this port for each device. All this could not go on forever, and the usb bus was invented.
')
Bus structure
The first thing you can see when working with usb devices in modern operating systems is that you no longer need to work physically with the data port. So, let's see what an arbitrary usb device is in the first approximation:On the first line of defense we are waiting for the interface level, this is a logical separation of the device according to the tasks it performs, for example, if we have an external display equipped in addition with an audible warning system - our device may well have a couple of interfaces, one to work with the display, the other for work with sound, and, for example, the third - for flashing the device itself.
If we consider writing a driver under windows using the latest driver framework (WDF), then we can find out the number of interfaces and access them using a couple of lines of code.
The interface is not the only level of separation existing in USB; each interface is divided into a set of so-called endpoints.
Suppose that we can both record a picture on the display - and read the current picture from the display; in this case, one end point will be used for reading, the other - for writing. In addition to the direction of data transmission (In / Out), the endpoint has another quite useful property, it is a type of transmission that has one of the following values:
• control transfers — used by the host to configure the device during connection, to control the device, and to receive status information during operation. The protocol provides guaranteed delivery of such parcels;
• Bulk Data Transfers - they are applied when it is necessary to ensure guaranteed delivery of data from the host to the function or from the function to the host, but the delivery time is not limited;
• interrupt transmissions — used when small, single data packets need to be transmitted. Each packet is required to transfer for a limited time. Transmission operations are spontaneous and must be serviced no slower than the device requires;
• isochronous transmissions - are used for data exchange in “real time” when a strictly defined amount of data is required to be transmitted at each time interval, but information delivery is not guaranteed (data transmission is carried out without repetition in case of failures, packet loss is allowed).
In addition to the end points defined directly by the device logic, one (zero) end point is determined directly by the protocol, any usb device must have a zero end point. Due to this, as soon as you connect the device to the computer - the operating system immediately recognizes the name of this device, and tries to find a driver for it, without this standard endpoint, it would be impossible to obtain information about the device in the absence of a driver.
Conclusion
All data is transmitted via two conductors inside the usb cable (another 2 are recharged to power), this allows the use of a single connector for all usb devices.This is all you need to know about the bus in order to write your first driver, which we will do in the next article.
Driver Development Kit for Windows XP, Vista, 7 Operating Systems - can be downloaded here: developer kit.
In the next part: handling of events related to the device, working with the backlight from the application, and a little reverse engineering.
Photo of the future patient:
Source: https://habr.com/ru/post/92628/
All Articles