How does a computer know which device is connected to the usb port?

Solution 1:

Yes. USB, aka Universal Serial Bus is a connection of 4 ports. VCC, Data+, Data- and Ground, where newer specifications will have more bandwidth and power transmission.

When you connect a USB device to your computer, the computer will first supply 5v over the port and data to request an init. The other end of the USB cable, the device, will have a controller chip that handles the communication of the port. It will send a response with an identifaction code.

There is a huge list of generic identifications that it can use, or it can say other, and transmit an additional code. In case of a computer, if this happens, it will look if driveres are installed or available matching this unique identifier. If not, it will respond with: "The device was not recognized." and you can only get it to work by installing the right driver, which will add support for that unique identification code.

Once the initial stage is complete, the device goes into operation mode, and the driver will continue to communicate to the USB device.

Small sidenote: If you try to just connect leads to a USB plug, say... power +, and ground, you will find out that it does not work reliably because there is no init stage. It will go on and then off.

And please recommend me some book about these stuff.

Sorry, but asking for learning recommendations is considered Off-Topic. Its too broad and can get outdated. See the Help Center for more information.

Solution 2:

Do each usb device send some unique information about them to the computer to be recognized by the computer?

Yes.

Basically USB devices have a class number (which isn't super unique across devices but does define the "type" of device), and a Vendor ID (VID) and Product ID (PID) that they tell the host when they connect. On Windows, in Device Manager, you can see the USB class number here under "Compatible IDs" ...

enter image description here

... and you can see the VID and PID under "Hardware IDs" ...

Illustration of USB PID/VID in devmgmt.msc

Device manufactuers get new USB VIDs from the USB Implementers' Forum, and the USB-IF also maintains the list of class codes.

The example above, if you look at this, you can see that Class 0x03 is a "Human Interface Device." An OS or other can support things based on class, or combination of class+PID/VID.

USB vendor IDs (VID) and product IDs (PID) are 16-bit numbers used to identify USB devices to a computer or other host. Each vendor ID is assigned by the USB Implementers Forum to a specific company, which in turn assign a PID to individual products. Reference

PCI/PCIe (and ISA in the early 90's with ISAPNP) had this mechanism before USB and that's what made PCI/PCIe "plug and play" - where the operating system could detect a device and load a driver automatically. The mechanism for PCI/PCIe is more complex as the operating system can assign resources to the device in addition to just getting the VID/PID.

Solution 3:

A good source of information on USB is the www.usb.org, more on that later. I admit that it can be difficult to understand where to start, so I try to give a short introduction below.

Firstly, there are several variations on USB, but they basically works the same. The USB device is connected to the computer with its own cable. Most often using a hub, but let us keep it simple here.

Once the microcomputer in the device gets power it will try to communicate with the computer. The computer and the device starts with what you might call a "negotiation" where they agree on a number of things. One is the speed to use, they go from 1.5MBit per second and upwards to 10GBit/s. As each USB device has its own connection to the computer, via the hub, each can have different speed. The device also negotiates for power, as it can only draw 100mA from the start.

The USB device will have one or several end-points. This can be used as example for a device having both an audio interface and a midi keyboard.

The USB device will in the protocol present itself with a Vendor Id, that is a unique number assigned for a vendor and also more information on the device. This information allows a vendor specific device driver in the computer to talk with the device.

Always requiring vendor specific devices is not a good idea however. Most devices today are "class-compliant" -- they send a class code and behave as expected. Class codes are defined here: https://www.usb.org/defined-class-codes . One of the more common class codes, 03, is used for human interface devices, a collective name for keyboards, mouses, joystick and so on. In the document section of www.usb.org there are a documents describing how the different classes are supposed to behave. One example is here https://usb.org/sites/default/files/hut1_2.pdf WARNING -- check for the lates version of the document.

Solution 4:

Do each USB device send some unique information about them to the computer to be recognized by the computer?

Yes, it is called "device descriptor(s)".

There is a process in USB framework called "enumeration". When a device is connected to one of PC USB ports, the host initializes the port, assigns new unique USB address to it, and asks the device to provide a set of "descriptors". The descriptors do as the name implies, describe what the device is. Aside of vendor and product identifiers, the device provides an information about which USB device class it belongs to. And a lot more, about power requirements, fine detail of interfaces, power management parameters, etc. The class is the most important information the devices provide.

Classes are defined for operating system convenience, they have common way of using controls over the device. Generic keyboards and mice belong (designed) to HID class (Human Interface Device class). Other typical classes are COM devices, Webcam video class, Mass Storage Class. USB device classes define basic functionality and common way to control data. So the system loads a common driver for the class of devices, and the device just work. More sophisticated devices may define proprietary interfaces, and then you will need to download and install proprietary drivers to gain extended functionality of the device. But for user convenience all USB devices usually implement some basic class functionality, so a user can start using it.

Keyboards are designed to comply with HID class of devices, so your BIOS implements only one driver, HID. Thus, regardless of Vendor ID or Product ID, one driver works for all keyboards (if they are designed correctly), for hundreds of them. However, not all (special) keys might function unless you load a proper driver, which can be only under OS.

If you are curious, you might want to use an utility called "USBTreeView", you will be amazed how much information a USB device supplies to USB host.

Solution 5:

(Shorter reference from FTDI)

Keyboards and mice are slightly special in USB. While they do have a vendor and product ID, you don't want a situation where a new keyboard manufacturer is unable to work with computers made before they existed nor do you want to have to ship drivers for every keyboard.

So, in the same descriptor that has the vendor and product ID, there is a device class, device subclass, and protocol. All keyboards report as device class 3 (human interface device, "HID") protocol 1 (keyboard).

There is then a further set of "usages" available to the computer from the device to describe how many keys are on the keyboard, what language it is, and so on. For mice, these describe the axes (usually two, but you can have a 3D mouse) and buttons (as many as you like). Same for joysticks; the HID protocol can cover everything from a two-axis one button joystick to a complicated flight controller. And it doesn't just cover input, it covers output such as keyboard lights and force feedback or stick vibration.

USB-HID is quite useful in its ability to build generic devices without requiring too much driver work. You can get a desktop USB missile launcher, for example, which is a HID device.