If the application's receive buffer becomes full and it cannot accept more data, the receive logic will save the offset in the data buffer where it left off. If will return the data payload to the application by copying it from the read request's buffer into the application-provided receive buffer.Ħa. The receive logic starts when the application requests data (or it is resumed after the receipt of new data) it will look at the read request at the HEAD of the list of filled read requests. This step will also wake up read logic that has been suspended waiting for the availability of incoming data.Ħ. This will then be available to the the driver read logic when the application requests more data. When the filled read request if returned, the USB device class driver will add the newly filled read request to the TAIL of a list of filled read requests. The data is returned using a callback function pointer that is contained inside of the read request.ĥ. If the list of read requests is not empty, the DCD will remove the next read request from the list, receive the DATA accompanying the OUT token, copy the received packet data into the read request's buffer, and return the filled reqd request to the USB device class driver. This NAKing will continue until the list of read requests is non-empty and the DCD disables the NAKing to signal that it can accept the OUT packet data.Ĥb. If there are no requests in the list of empty read requests, the DCD will have configured the endpoint to NAK the OUT token. When the OUT token is received what happens next depends upon the stat of the list of empty read requests.Ĥa. Upon receipt, the DCD will keep all of these empty read requests in a list.Ĥ.
The USB device class driver sends each allocated read request to the device DCD via DRVR_EPSUBMIT().ģ. At initialization time when the USB device class driver is enumerated by the host, the class driver will allocates a number of read requests (which contain request buffers).Ģ.
NAKing USB OUT Tokensīelow is how the NAKing is implemented in the interaction between the USB device class driver and USB Device Controller Drivers (DCDs):ġ. For the device this is a read (peripheral-to-memory) operation. OUT refers to data sent from the host OUT to the device.
But for the device, this is a write operation (write being peripheral-centric: from-memory-to-peripheral). This makes life difficult for people working USB device drivers: IN refers to data coming from the device INto the host. NOTE: USB direction naming is host-centric. Similarly, USB will refuse to perform the USB host's requests for IN data by NAKing the host's IN tokens. The USB device class driver can control this NAKing only indirectly by the manner in which it manages read requests. USB supports a NAKing mechanism to pace incoming OUT data from the USB host.
0 kommentar(er)
