It is difficult to analyze data packets. I copied some of the information. I don’t know if it will be useful to you.

3.7 Data flow types

There are two channels for the exchange of data and control signals between the host and the USB device: one-way and two-way. USB data transfer is between the host software and a designated port of a USB device. This connection between the host software and the USB device port is called a channel. In general, the data flow between channels is independent of each other. A given USB device can have many channels. For example, a USB device has a port that can establish a channel to send data to the ports of other USB devices, and it can establish a channel to receive data from the ports of other USB devices.

The structure of USB includes four basic data transmission types:

·Control data transmission: used to set the device when the device is connected, and can also control the specified device. Such as channel control;

·Batch data transmission: Data generated and used in large batches has a wide dynamic range under transmission constraints;

·Interruption data transmission: with To describe or match a person's feelings or responses to characteristic responses.

· Synchronous data transmission: filling the predetermined USB bandwidth with a predetermined transmission delay.

When setting up any given device, a channel can only support one of the above methods of data transmission. More details of the data flow mode are detailed in Chapter 4.

3.7.1 Control data transmission

When a USB device is first installed, the USB system software uses control data to set up the device, and the device driver uses control data to transmit it in a specific way. ,Data transmission is lossless.

3.7.2 Batch data transmission

Batch data is composed of a large amount of data. For example, when using printers and scanners, batch data is continuous. Error detection can be used at the hardware level to ensure reliable data transmission, and multiple transmissions of data are introduced at the hardware level. In addition, depending on other bus actions, the bandwidth occupied by large amounts of data can be changed accordingly.

3.7.3 Interrupt data transmission

Interrupt data is a small amount, and its data delay time is also limited. This data can be sent by the device at any time and is transferred over USB at a speed no slower than the device's specified speed.

Interrupt data generally consists of event notification, characteristics and coordinate numbers, with only one or a few bytes. Matching the coordinates of a pointing device is one example. Although a precisely specified transfer rate is not necessary, USB must provide a minimum bound on the response time for interactive data.

3.7.4 Synchronous transmission

The establishment, transmission and use of synchronized data are continuous and real-time. Synchronous data sends and receives real-time information at a stable rate. Synchronous data To keep the receiver on the same schedule as the sender, in addition to the transmission rate, synchronization data is very sensitive to transmission delay. Therefore, the determination of the bandwidth of the synchronization channel must meet the sampling characteristics of the relevant functional components. The unavoidable signal delay is related to the number of buffers available per port.

A typical example of synchronous data is voice. If the transmission rate of the data stream cannot be maintained, whether the data stream is lost will depend on the size of the buffer and the degree of corruption. Even if the data is transferred at the appropriate rate on the USB hardware, the transfer delay caused by the software will harm applications such as real-time systems such as teleconferencing.

Real-time transmission of synchronized data will definitely cause potential instantaneous data stream loss. In other words, even the introduction of many hardware mechanisms, such as retransmission, cannot avoid the occurrence of errors. In practical applications, the data error rate of USB is so small that it is almost negligible. From the USB bandwidth, a dedicated portion is allocated to the USB synchronization data stream to meet the desired transfer rate. USB also designs a minimum delay time for the transmission of synchronization data.

3． The processing process of USB transmission

As mentioned earlier, there are four types of transmission in the USB system: a transmission is usually broken down into several transactions; and the processing of a transaction generally goes through token packets, data packets and handshakes. There are three packet phases, but there are also some transactions that are processed without a data packet phase or a handshake packet phase, and some transactions that only have a token packet phase. The following is an introduction to the processing procedures of these four types of transmission.

1) Block transfer

Used for batch data transfer between the host and the USB device. Usually a block transfer needs to be broken down into several block transfer transactions. Obviously, the direction of a block transfer is single, for the host, it is either input or output. Therefore, a block transfer is composed of several IN transactions or several OUT transactions. Figure 10.38 shows a schematic diagram of the block transfer transaction process. The PING packet and NYET packet in the picture are only used for high-speed transmission equipment, and beginners can ignore them for the time being.

For input block transfer, several IN transactions are generally performed. Each time an IN transaction is executed, the host first issues an IN token packet. The device endpoint responds after receiving it, usually by sending back a data packet. If the data cannot be sent back, a NAK packet or STALL packet is sent back. NAK means that the device cannot send back data temporarily; STALL means that the endpoint has been stopped or requires intervention by the IJSB system software; if the host receives a legitimate data packet, it will respond with an ACK handshake packet; if the host finds an error when receiving the data, it will not device any echo.

For block transfer to be output, several OUT transactions are generally performed. Each time an OUT transaction is executed, the host first sends an OUT token packet, and then sends a data packet. After receiving the data packet, the device responds with a handshake packet according to the situation; responds with ACK to indicate that the data has been received correctly, and notifies the host that the next OUT transaction can be started to transmit the next data packet; responds with NAK to indicate that the data has been received correctly. However, the host should not send any more data because the device cannot receive it temporarily (such as the buffer is full); if the endpoint has terminated, it will respond with STALL to notify the host not to resend data because the device is faulty; if a CRC check error occurs during reception , no handshake packet is sent.

It should be pointed out that IN transactions and OUT transactions are not only used in block transfer transactions, but also in several other transfer transactions. Of course, the processing procedures may be different.

2) Interrupt transmission

It is used for data transmission with small data transmission volume and no periodicity, but is sensitive to response time and requires immediate response. The name of the interrupt transfer implies that a device can cause a hardware interrupt that will cause the host to respond quickly. But the reality is that interrupt transfers, like all other USB transfers, only occur when the host is accessing the device. It is called interrupt transfer because it guarantees that the host will respond or send data with the shortest delay. The special thing about interrupt transmission is that the host will access the endpoint that can cause an interrupt (called an interrupt endpoint) in a specific cycle to see if an interrupt occurs. Figure 10.39 shows the processing process of the interrupt transfer transaction.

For input interrupt transmission, the host executes IN transactions according to a specific cycle. If no interrupt occurs, the interrupt endpoint returns a NAK packet; if an interrupt occurs, interrupt data is sent back. After the host receives the data, it sends an ACK packet.

For interrupt transmission to be output, the host executes the OUT transaction according to a specific cycle, and after sending the OUT token, then sends the data packet. If no interruption occurs, the interruption endpoint returns a NAK packet or STALL packet; if an interruption occurs and the received data is correct, an ACK packet is returned. It should be pointed out that when there is no interruption to the device, the host will always execute OUT transactions according to a specific cycle, and the data sent remains unchanged. When an interrupt occurs, the data pointer is modified to point to the next data area.

An interrupt transfer consists of one or more IN transactions or one or more OUT transactions. An interrupt transfer ends in one of two situations: when the requested amount of data has been transferred, or when the length of the data packet is less than the specified maximum (including zero-length packets). The end of the interrupt transmission indicates that the data to be transmitted has arrived and the receiver can use it; and the host's periodic query of the interrupt endpoint will continue to start the next interrupt transmission when the next interrupt occurs.

3) Isochronous transmission

Used for periodic data transmission with constant transmission rate. Isochronous transmission transfers a certain number of bytes in each frame. An isochronous transmission consists of one IN or one OUT transaction per frame in one or more consecutive frames. Figure 10.40 shows the processing of an isochronous transfer transaction. It can be seen that the IN transaction and OUT transaction of isochronous transmission only include two phases: token packet and data packet. There is no handshake packet phase, and retry is not supported.

4) Control transfer

Control transfer provides a way to configure a USB device and control certain aspects of its operation. Each device must set a default control endpoint (usually the O-numbered endpoint). Control endpoints are used to configure devices, control device status, and certain aspects of device operation. The control endpoint responds to some USB special requests sent via control transfers. For example, when a device is detected by the system, the system software must read the device's descriptor to determine its type and operating characteristics.

Control transmission consists of at least two phases, and can also be three phases:

① SETUP phase: Control transmission always starts with the SETUP phase, which sends information to the target device. , defines the type of request to the device (for example, reading a device descriptor).

②Data stage: This stage is only defined for requests that require data transmission. For example, during the data phase, a read descriptor request sends the contents of the descriptor to the host. Some requests do not require data transfer outside the SETUP phase.

③Status phase: This phase is always used to report the results of the requested operation.

In the SETUP phase, a SETUP transaction is used to transmit information to the control endpoint. The SETUP transaction is similar to an OUT transaction, except that the package identifier PID is SETUP instead of OUT. Figure 10.41 shows the execution process of the SETUP transaction. The data phase of the SETUP transaction always utilizes the DATA0 PID. If the reception is correct, the control endpoint will send back an ACK packet; if the reception is incorrect or the data is lost, no handshake packet will be sent back.

The data phase of the control transfer is not required. If this phase is required, it consists of one or more IN transactions or one or more OUT transactions. The direction of all transactions in the data phase must be consistent, that is, they are all IN transactions or all OUT transactions. The amount and direction of data transmitted in the data phase are specified in the SETUP phase. If the amount of data exceeds the predetermined data packet size, sending the data requires multiple transactions (IN or OUT) that can carry the largest packet, and another transaction is scheduled for the remaining part (less than the maximum packet size).

The status phase of a control transfer is the last phase of the transfer and requires only one transaction. The data flow direction of the status phase should be different from the previous phases and always utilize the DATAl PID. For example, if the data phase performs an OUT transaction, the status phase is an IN transaction. If a control transfer has no data phase, the status phase consists of an IN transaction. Figure 10.42 shows the transaction sequence, the value of the trigger bit (in brackets) and the type of data PID for control read transfers, control write transfers, and control transfers without data phases.

The transmission and transmission transaction processing procedures described above reflect the data transmission process in the USB system. Note that one frame (or microframe) includes four transmission transactions, so the actual transmission process is more complicated than what is described here.

4. Data trigger technology

Data trigger technology is adopted in the USB system. Data triggering is a mechanism used to ensure synchronization between the sender and receiver of data transmission. It is especially important for a long transmission process that requires a large number of transactions. The data triggering mechanism allows the sender and receiver to resynchronize in the event of a handshake packet error.

Data triggering only supports interrupt transfer, block transfer and control transfer. The sender and receiver that supports the data triggering mechanism must have a trigger bit for each data transmission. When both parties believe that the data transmission has been completed correctly, they will convert their trigger bits to the opposite state. Two types of data packets (DATAO and DATAl) are transmitted alternately, and the receiver of the packet will compare it with the trigger bit to determine whether the received packet is correct. The data packet type used by the sender is consistent with the current state of its trigger bit (for example, if the trigger bit is 0, the data packet uses DATA0). The following only takes the OUT transaction as an example to understand the data triggering mechanism.

Example 10.1 Figure 10.43 shows the processing process of an error-free OUT transaction and the changes in the trigger bit. It is assumed that the trigger bits of the sender and receiver are both 0 at first. The transmission process is as follows:

Transaction processing l:

①The host sends an OUT token to the target device.

②The target device receives the token packet without error.

③The host sends a DATA0 data packet to the target device (consistent with its trigger bit).

④The target device receives the data packet DATA0, which is consistent with the trigger bit.

⑤The target device successfully receives the data packet DATA0, and the trigger bit changes to 1.

⑥The target device sends an ACK handshake packet to the host to notify the host that the data has been received without error.

⑦The host receives the ACK packet without error.

⑧ After successfully receiving the ACK packet, the host changes the trigger bit to l.

Transaction 2:

①The host sends a new OUT token to the target device to start the next transaction process.

②The target device receives the token packet without error.

③The host sends a DAl, A1 data packet to the target device (consistent with its trigger bit).

④The target device receives the data packet DATAl, which is consistent with the trigger bit.

⑤The target device successfully receives the data packet DATAl, and the trigger bit changes to 0.

⑥The target device sends an ACK handshake packet to the host to notify the host that the data has been received without error.

⑦The host receives the ACK packet without error.

⑧ After successfully receiving the ACK packet, the host changes the trigger bit to 0.

This process continues for each transaction until the entire transfer is completed. As long as the received data packet is consistent with the trigger bit and the sender receives the ACK handshake packet without errors, the sender and receiver remain synchronized.

The above is the case where both the data packet and the handshake packet are transmitted correctly. Let's take a look at the situations when data packet transmission errors and handshake packet transmission errors occur respectively.

Example l0.2 Figure 10.44 shows the mth OUT of a transmission. During the transaction processing, an error occurred in the data packet transmission. The actions taken by the host and target device are as follows:

Transaction m:

①The host sends an OUT token to the target device.

②The target device receives the token packet without error. ,

③The host sends a DATA0 data packet to the target device (consistent with its trigger bit).

④When the target device receives the data packet DATAO, an error is found.

⑤ Because an error in the data packet is detected, the target device will ignore the packet. The data is discarded and no handshake packet is sent to the host. Because the packet was not received correctly, the trigger bit remains unchanged.

⑥The host is waiting for the return of the handshake packet, but there is no response. After the bus timeout period (16 bit times) is reached, the host detects no response, so it considers the transmission of the data packet to be unsuccessful, and the host's trigger bit remains unchanged. The host must redo the transaction later.

Transaction m is re-executed:

①The host then sends the OUT token to the target device.

②The target device receives the token packet without error.

③The host sends a DATAO data packet to the target device (consistent with its trigger bit). This data packet was not successful in the last transmission.

④The target device successfully receives the data packet DATA0, which is consistent with the trigger bit.

⑤ Because the data packet DATA0 is received correctly, the target device changes the trigger bit to 1.

⑥The target device sends an ACK handshake packet to the host to notify the host that the data has been received without error.

⑦The host receives the ACK packet without error.

⑧The ACK packet is successfully received, and the host changes the trigger bit to l.

It can be seen from the above process that despite transmission errors, the host and target devices can still maintain synchronization.

Example 10.3 Figure 10.45 shows the processing process of the nth OUT transaction of a transmission, during which it failed due to an ACK packet error. Each step of error detection and recovery is listed below:

Transaction n:

①The host sends an OUT token to the target device.

②The target device receives the token packet without error.

③Then the host sends a DATA0 data packet to the target device (consistent with its trigger bit).

④The target device receives the data packet DATA0, which is consistent with the trigger bit.

⑤The target device successfully receives the data packet DATA0, and the trigger bit changes to 1.

⑥The target device sends an ACK handshake packet to the host to notify the host that the data has been received without error.

⑦ There is an error in the ACK packet received by the host.

⑧Because the host detected the error, it cannot determine whether the target device has successfully received the data. Therefore, the master's trigger bit has not changed (still 0). The host assumes that the target device did not receive the data and redoes the transaction.

Transaction n is re-executed:

①The host then sends the OUT token to the target device.

②The target device receives the token packet without error.

③The host resends the DATA0 data packet to the target device (consistent with its trigger bit). This data packet was not known to be received correctly by the target device when it was last transmitted.

④The target device receives the data packet DATA0 without error, but it is inconsistent with the trigger bit.

⑤The target device thinks that it is out of sync with the host, thus discarding the data, and the trigger bit remains unchanged (1).

⑥The target device sends an ACK handshake packet to the host to notify the host that the data has been received without errors. This is because

The host obviously did not receive the last ACK handshake packet.

⑦The host receives the ACK handshake packet without error.

⑧The ACK packet is successfully received, and the host changes the trigger bit to 1. The host and target devices are now ready for the next transaction.

It can be seen from this example that the host and the target device temporarily do not agree on whether the data transfer is completed.

However, the data triggering mechanism ensures that out-of-sync states can be detected and synchronization can be re-established.

/yangchengbo82/blog/item/e9301b895c00b1b10e244435.html