USB_RequestGetPending (SWI&55393) — Gets the next request which can be processed at a given frame for a given host controller from given transfer queues.
| R0 | Pointer to controller structure. |
| R1 | Number of the frame that must have been passed until pending requests can be processed or 0xFFFFFFFF to get all pending requests. |
| R2 | Pattern mask to select transfer lists from which pending requests could be taken. |
| R3 | Reserved. Must be set to zero. |
| R4 | Reserved. Must be set to zero. |
| R0 | Pointer to transaction structure or zero if an error occurred or there is no request. |
| R1 | Error code Table A.1, “Error codes used by the USB system” |
| R2, R3, R4 | Preserved |
The USB host controller driver must call this function to get the first transaction of the next pending request. If he gets a requests he must check it on following transactions belonging to the same request and get them too by using USB_TransactionGetPending (SWI&55392).
If an application generates a request it is split up into transactions and queued inside the pipe. If there are requests in a pipe and there are less requests running at this pipe than the maximal number of requests the USB host controller wants to be notified about the pipe must be registered inside a list containing pipes having waiting requests. During this process the USB frame is calculated when the first request in the pipe queue can be processed. The pipe is inserted ordered by this frame number inside the list. The pipes with the smallest frame number are located first inside the list. Note that there are several lists one per USB transfer type. The pipe is inserted into that list which is corresponding to its transfer type.
If an USB_RequestGetPending (SWI&55393) is called, it scans all the lists of pipes that are having pending requests. The pattern mask passed as a parameter to the function determines which lists are checked. Each bit of the mask corresponds to one transfer type Table A.5, “Constants used for type of USB transfer”. The list are always scanned from least significant bit to most significant bit. That means Control transfer list is always scanned first. If an allowed list contains at least one pipe with pending transaction the frame number of the first pipe is compared with the frame number passed as a parameter to the USB_RequestGetPending (SWI&55393) function. If it is less or equal than this parameter a request is found which can be passed as a result to the caller of the function. Else the next list is checked. The is no need to check the other pipes inside the list because the list is ordered by frame number and if the first entry must be started at a later frame the other entries of the list must be started later too.
The USB host controller driver is free how to set the frame number. Normally it will be the next frame of the actual USB frame or the actual USB frame. This depends on the driver. It is also possible to set a frame number far away from the actual USB frame to get all pending request and to bypass USB module request management. The pattern mask will be usually set to select all pending lists or to exactly one list per time.