8 basic questions and answers about USB

8 basic questions and answers about USB

Question 1: What is the structure of the USB transmission line?

Answer 1: A USB transmission line consists of four lines: ground line, power line, D+, and D-. D+ and D- are differential input lines, which use a 3.3V voltage (note, this is different from the 5V level of CMOS), while the power line and ground line can provide 5V voltage to the device, with a maximum current of 500MA (which can be set during programming, and as for the hardware implementation mechanism, just ignore it).

Question 2: How is data transmitted in the USB transmission line?

Answer 2: Data is transmitted from low to high in the USB cable.

Question 3: What is the USB encoding scheme?

Answer 3: USB uses non-return-to-zero inversion to transmit data. When the differential data on the transmission line is input as 0, it is inverted, and when it is input as 1, it keeps the original value. In order to ensure the accuracy of signal transmission, when a packet is sent on the USB bus, the transmission device must perform a bit insertion operation (that is, insert a 0 after every 6 consecutive 1s in the data stream), thereby forcing the NRZI code to change. Just understand this, which is handled by special hardware.

Question 4: What is the data format of USB?

Answer 4: Like other USB data, USB data is composed of binary digital strings. First, the digital strings form domains (there are seven types), domains form packets, packets form transactions (IN, OUT, SETUP), and transactions finally form transmissions (interrupt transmission, parallel transmission, bulk transmission, and control transmission). The following is a brief introduction to domains, packets, transactions, and transmissions. Please pay attention to the relationship between them.

(I) Domain: It is the smallest unit of USB data and consists of a number of bits (the number of bits is determined by the specific domain). Domains can be divided into seven types:

1. Synchronization field (SYNC), eight bits, fixed value 0000 0001, used for synchronization of local clock and input

2. The identification field (PID) is composed of a four-bit identifier + a four-bit identifier inverse, indicating the type and format of the packet. This is a very important part. It can be calculated here that there are 16 types of USB identification codes. Please see question 5 for the specific classification.

3. Address field (ADDR): A seven-bit address representing the address of the device on the host. Address 000 0000 is named zero address. It is the default address of any device when it is first connected to the host before it is configured and enumerated by the host. This explains why a USB host can only connect to 127 devices.

4. Endpoint field (ENDP), four bits, from which we can know that the maximum number of endpoints a USB device has is 16.

5. Frame number field (FRAM), 11 bits. Each frame has a specific frame number. The maximum capacity of the frame number field is 0x800. It is important for synchronous transmission (synchronous transmission is one of the four transmission types, see below).

6. Data field (DATA): The length is 0~1023 bytes. The length of the data field varies in different transmission types, but it must be an integer number of bytes.

7. Check field (CRC): A method of checking the non-PID field in token packets and data packets (see below for the classification of packets). CRC check is widely used in communications and is a very good check method. As for the specific check method, I will not go into details here. Please refer to relevant information. Just note that the division of CRC code is modulo 2 operation, which is different from the division in decimal system.

(II) Packet: There are four types of packets consisting of fields, namely token packets, data packets, handshake packets and special packets. The first three are important packets. Different packets have different field structures, which are introduced as follows.

1. Token packet: can be divided into input packet, output packet, setting packet and frame start packet (note that the input packet here is used to set the input command, and the output packet is used to set the output command, not to release the data)

The formats of input packages, output packages, and settings packages are all the same:

SYNC+PID+ADDR+ENDP+CRC5 (five-bit checksum)

(Please refer to the above domain description for the explanation of the above abbreviations, and please refer to question 5 for the specific definition of the PID code)

The format of the frame start packet is:

SYNC+PID+11-bit FRAM+CRC5 (five-bit checksum)

2. Data packets: divided into DATA0 packets and DATA1 packets. When USB sends data, if the length of the data sent at one time is greater than the capacity of the corresponding endpoint, the data packet needs to be divided into several packets and sent in batches. DATA0 packets and DATA1 packets are sent alternately, that is, if the first data packet is DATA0, the second data packet is DATA1. However, there are exceptions. In synchronous transmission (one of the four transmission types), all data packets are DATA0, and the format is as follows:

SYNC+PID+0~1023 bytes+CRC16

3. Handshake packet: The packet with the simplest structure, the format is as follows

SYNC+PID

(Note that each of the above packets has different types. USB1.1 defines a total of ten types of packets. For details, please see Question 5)

(III) Transactions: There are three major transactions: IN transactions, OUT transactions, and SETUP transactions. Each transaction consists of three stages: token packet, data packet, and handshake packet. The term "stage" is used here because the sending of these packets has a certain time sequence. The three stages of a transaction are as follows:

1. Token Packet Phase: Start an Input, Output, or Set Transaction

2. Data packet stage: send corresponding data according to input and output

3. Handshake packet stage: Returns the data reception status. This stage does not exist in the IN and OUT transactions of synchronous transmission, which is quite special.

The three types of transactions are as follows (a transaction is described in three stages below):

1. IN transaction:

Token packet stage: the host sends an input packet with PID IN to the device, notifying the device to send data to the host;

Data packet stage - the device will respond in three ways depending on the situation (note: the data packet stage does not always transmit data, and it will enter the handshake packet stage in advance depending on the transmission situation)

1) The device endpoint is normal, and the device sends data packets to the host (DATA0 and DATA1 alternately);

2) The device is busy and cannot send a data packet to the host, so it sends a NAK invalid packet, and the IN transaction ends early and continues until the next IN transaction;

3) The corresponding device endpoint is disabled and an error packet STALL packet is sent, so the transaction ends prematurely and the bus enters the idle state.

Handshake packet stage - after the host receives the data correctly, it will send an ACK packet to the device.

2. OUT transaction:

Token packet stage - the host sends an output packet with PID OUT to the device, notifying the device to receive data;

Data packet stage - relatively simple, the host sends data to the device, DATA0 and DATA1 alternately

Handshake packet stage - the device will respond in three ways depending on the situation

1) The device endpoint receives correctly, and the device returns ACK to the host, notifying the host that new data can be sent. If a CRC check error occurs in the data packet, no handshake information will be returned;

2) The device is busy and cannot send a data packet to the host, so it sends a NAK invalid packet to notify the host to send data again;

3) The corresponding device endpoint is disabled, an error packet STALL packet is sent, the transaction ends prematurely, and the bus directly enters the idle state.

3. SETUT transaction:

Token packet stage: the host sends an output packet with PID SETUP to the device, notifying the device to receive data;

Data packet stage - relatively simple, the host sends data to the device. Note that there is only one DATA0 packet with a fixed length of 8 bytes. The content of these 8 bytes is the standard USB device request command (there are 11 in total, please see question 7 for details)

Handshake packet stage - after the device receives the command information from the host, it returns ACK, after which the bus enters the idle state and prepares for the next transmission (usually a transmission consisting of an IN or OUT transaction after the SETUP transaction)

(IV) Transmission: Transmission is composed of OUT, IN, and SETUP transactions. There are four types of transmission: interrupt transmission, bulk transmission, synchronous transmission, and control transmission. Interrupt transmission has the same structure as bulk transmission, synchronous transmission has the simplest structure, and control transmission is the most important and complex transmission.

1. Interrupt transmission: It consists of OUT transactions and IN transactions and is used for data transmission of HID devices such as keyboards and mice.

2. Bulk transfer: It consists of OUT transactions and IN transactions and is used for large-capacity data transmission. It has no fixed transmission rate and does not occupy bandwidth. When the bus is busy, USB will give priority to other types of data transmission and temporarily stop bulk transfer.

3. Synchronous transmission: It consists of OUT transactions and IN transactions. There are two special features. First, there is no return packet phase in the IN and OUT transactions of synchronous transmission; second, all data packets in the data packet phase are DATA0

4. Control transmission: The most important and complex transmission. Control transmission consists of three stages (initial setup stage, optional data stage, status information step). Each stage can be regarded as a transmission, that is to say, control transmission is actually composed of three transmissions. It is used for the first time when the USB device is connected to the host. The host exchanges information, device address and reads the device descriptor through control transmission, so that the host can identify the device and install the corresponding driver. This is an issue that every USB developer should be concerned about.

1. Initial setup step: a transmission consisting of a SET transaction

2. Optional data step: This is a transmission consisting of an IN or OUT transaction. This step is optional and depends on whether the initial setup step requires read/write data (determined by the standard request command sent in the data packet phase of the SET transaction)

3. Status information step: As the name implies, this step is to obtain status information, which is composed of IN or OUT transactions. However, it should be noted that the IN and OUT transactions here are different from the previous INT and OUT transactions in two points:

1) The transmission direction is opposite. Usually, IN means that the device sends data to the host, and OUT means that the host sends data to the device. Here, IN means that the host sends data to the device, and OUT means that the device sends data to the host. This is to combine with the optional data step.

2) In this step, the data packets in the data packet stage are all 0 length, that is, SYNC+PID+CRC16

Apart from the above two differences, the others are the same, so I won't go into details here.

(Think: How and in what way should these transmission modes be set up in practice?)

Question 5: What are the identification codes?

Answer 5: As mentioned above, the identification code is composed of four bits of data, so it can represent sixteen identification codes. In the USB1.1 specification, only ten identification codes are used, and USB2.0 uses sixteen identification codes. The identification code is used to describe the properties of the packet. The identification code is associated with the packet. First, let's briefly introduce the types of data packets. Data packets are divided into four types: token packets, data packets, handshake packets, and special packets (see question seven for specific classification). There are sixteen types of identification codes:

Token Packet:

0x01 Output (OUT) starts a transfer from the host to the device and includes the device address and label

0x09 Input (IN) Starts a transfer from device to host and contains the device address and label

0x05 Start of Frame (SOF) indicates the beginning of a frame and contains the corresponding frame number

0x0d SETUP starts a control transfer for the host to initialize the device

Data Pack:

0x03 Even data packet (DATA0),

0x0b odd data packet (DATA1)

Handshake Packet:

0x02 Confirmation of receipt of correct data packet (ACK)

0x0a Invalid, the receiving (sending) end is busy and cannot receive (send) information.

0x0e Error, the endpoint is disabled or does not support the control pipe request

Special packet 0x0C leading, used to start data transmission of low-speed devices on the downstream port

Question 6: How does the USB host identify the USB device?

Answer 6: When a USB device is plugged into the host, the host enumerates and configures the device through a series of actions (configuration is a state of enumeration, and a state indicates a temporary state). These states are as follows:

1. Attached: After the device is connected to the host, the host detects the level change on the signal line to detect the device connection;

2. Powered: It is to supply power to the device, which is divided into the default power supply value when the device is connected and the power supply value after the configuration stage (according to the maximum value required in the data, which can be set by programming)

3. Default: Before being configured, USB communicates with the host through the default address 0;

4. Address state: After configuration, when the USB device is reset, it can communicate with the host according to the unique address assigned to it by the host. This state is the address state;

5. Configured state: Obtain various information of the device through various standard USB request commands, and change or set certain information of the device.

6. Suspended state: If the bus-powered device has no bus operation within 3ms, that is, if the USB bus is in an idle state, the device will automatically enter the suspended state. After entering the suspended state, the total current power consumption shall not exceed 280UA.

Question 7: What exactly is the standard USB device request command mentioned in answer 4?

Answer 7: The standard USB device request command is used in the data packet stage (i.e. DATA0, consisting of eight bytes) in the "initial setup step" of the control transmission. Please refer to the content of Q&A 4. There are 11 standard USB device request commands, all of which are 8 bytes in size and have the same structure. They are composed of 5 fields (the fields are the data part of the standard request command). The structure is as follows (the numbers in brackets represent the number of bytes, and the initials bm, b, and w represent bitmap, byte, and double byte respectively):

bmRequestType(1)+bRequest(1)+wvalue(2)+wIndex(2)+wLength(2)

The meaning of each field is as follows:

1. bmRequestType: D7D6D5D4D3D2D1D0

D7=0 Host to Device

=1 device to host;

D6D5=00 Standard request command

=01 Class request command

=10 User defined commands

=11 Reserved value

D4D3D2D1D0=00000 The receiver is a device

=00001 The receiver is a device

=00010 The receiver is an endpoint

=00011 The recipient is another recipient

=Other values ​​are reserved

2. bRequest: request command code. In the standard USB command, each command has a defined number. The value of the number is the value of the field. The number and command name are as follows (note that the command code here should be used in conjunction with other fields. It can be said that the command code is the core of the standard request command code. It is these command codes that determine the 11 USB standard request commands):

0) 0 GET_STATUS: used to return the status of a specific receiver

1) 1 CLEAR_FEATURE: used to clear or disable certain features of the receiver

2) 3 SET_FEATURE: used to enable or activate certain features of the command receiver

3) 5 SET_ADDRESS: used to assign an address to the device

4) 6 GET_DEscriptOR: used by the host to obtain a specific descriptor of the device

5) 7 SET_DEscriptOR: Modify the relevant descriptors in the device, or add new descriptors

6) 8 GET_CONFIGURATION: used by the host to obtain the current configuration value of the device (note: different from the above)

7) 9 SET_CONFIGURATION: used by the host to indicate the required configuration adopted by the device

8) 10 GET_INTERFACE: used to obtain the current interface descriptor number

9) 11 SET_INTERFACE: used by the host to request the device to use a descriptor to describe the interface

10) 12 SYNCH_FRAME: Synchronization frame used by the device to set and report an endpoint

It would take a long time to explain the above 11 commands. Please go read a book. I will not elaborate here. Controlling transmission is the focus of USB, and these 11 commands are the focus of controlling transmission. Therefore, these 11 commands are of utmost importance. If you understand this, you can get started with USB.

Question 8: In standard USB request commands, we often see Descriptor. What does it come from?

Answer 8: Descriptor is a complete data structure that can be implemented through programming in C language and stored in USB devices. It is used to describe all the properties of a USB device. The USB host requires the device to send this information through a series of commands. Its function is to pass information to the host through command operations such as those mentioned in the question and answer section, so that the host knows what functions the device has, what type of device it belongs to, how much bandwidth it will occupy, what type of transmission method it uses, and the amount of data. Only after the host determines this information can the device really start working, so the descriptor is also a very important part and must be mastered. There are 5 standard descriptors, and USB defines numbers for these descriptors:

1——Device Descriptor

2 - Configuration Descriptor

3 - Character descriptor

4——Interface Descriptor

5 - Endpoint Descriptor

There is a certain relationship between the above descriptors. A device has only one device descriptor, and a device descriptor can contain multiple configuration descriptors, and a configuration descriptor can contain multiple interface descriptors. If an interface uses several endpoints, there will be several endpoint descriptors. This descriptor is composed of certain fields, which are described as follows:

1. Device Descriptor

struct _DEVICE_DEscriptOR_STRUCT

{

BYTE bLength; //The byte size of the device descriptor is 0x12

BYTE bDescriptorType; //descriptor type number, 0x01

WORD bcdUSB; //USB version number

BYTE bDeviceClass; //USB assigned device class code, 0x01~0xfe is standard device class, 0xff is manufacturer-defined type

//0x00 is not defined in the device descriptor, such as HID

BYTE bDeviceSubClass; //USB assigned subclass code, same as above, the value is specified and assigned by USB

BYTE bDeviceProtocl; //USB assigned device protocol code, same as above

BYTE bMaxPacketSize0; //The maximum packet size of endpoint 0

WORD idVendor; //Manufacturer number

WORD idProduct; //Product number

WORD bcdDevice; //Device factory number

BYTE iManufacturer; //Index of the string describing the manufacturer

BYTE iProduct; //Index of the string describing the product

BYTE iSerialNumber; //Describes the index of the device serial number string

BYTE bNumConfiguration; //Number of possible configurations

}

2. Configuration Descriptor

struct _CONFIGURATION_DEscriptOR_STRUCT

{

BYTE bLength; //The byte size of the device descriptor is 0x12

BYTE bDescriptorType; //descriptor type number, 0x01

WORD wTotalLength; //Configure the size of all quantities returned

BYTE bNumInterface; //Number of interfaces supported by this configuration

BYTE bConfigurationVale; //Parameter value required by Set_Configuration command

BYTE iConfiguration; //Index value of the string describing the configuration

BYTE bmAttribute; //Power supply mode selection

BYTE MaxPower; //The maximum current drawn by the device from the bus

}

3. Character descriptor

struct _STRING_DEscriptOR_STRUCT

{

BYTE bLength; //The byte size of the device descriptor is 0x12

BYTE bDescriptorType; //descriptor type number, 0x01

BYTE SomeDescriptor[36]; //UNICODE encoded string

}

4. Interface Descriptor

struct _INTERFACE_DEscriptOR_STRUCT

{

BYTE bLength; //The byte size of the device descriptor is 0x12

BYTE bDescriptorType; //descriptor type number, 0x01

BYTE bInterfaceNunber; //Interface number

BYTE bAlternateSetting; //Alternate interface descriptor number

BYTE bNumEndpoints; //The number of endpoints used by this interface, excluding endpoint 0

BYTE bInterfaceClass; //Interface type

BYTE bInterfaceSubClass; //Interface subclass

BYTE bInterfaceProtocol; //Protocol followed by the interface

BYTE iInterface; // string index value describing the interface

}

5. Endpoint Descriptor

struct _ENDPOIN_DEscriptOR_STRUCT

{

BYTE bLength; //The byte size of the device descriptor is 0x12

BYTE bDescriptorType; //descriptor type number, 0x01

BYTE bEndpointAddress; //Endpoint address and input and output properties

BYTE bmAttribute; //Transmission type attribute of the endpoint

WORD wMaxPacketSize; //The maximum packet size that the endpoint can receive and send

BYTE bInterval; //Time interval for host to query endpoint

}