Functional USB data exchange is
used to move data to and from the device. There are three types of USB data
transfers: Bulk, Interrupt and Isochronous
, which are described
in detail in
Functional USB data transfers can be implemented using two alternative methods:
single-blocking transfers and streaming transfers, both supported by WinDriver, as
explained in the following sections. The generated DriverWizard USB code
In the single-blocking USB data transfer scheme, blocks of data are synchronously transferred (hence — "blocking") between the host and the device, per request from the host (hence — "single" transfers).
WinDriver's WDU_Transfer() function, and the
WDU_TransferBulk(), WDU_TransferIsoch(), and
WDU_TransferInterrupt() convenience functions — all
described in
You can also perform single-blocking transfers using the DriverWizard utility
(which uses the WDU_Transfer() function), as demonstrated in
In the streaming USB data transfer scheme, data is continuously streamed between the host and the device, using internal buffers allocated by the host driver — "streams".
Stream transfers allow for a sequential data flow between the host and the device, and can be used to reduce single-blocking transfer overhead, which may occur as a result of multiple function calls and context switches between user and kernel modes. This is especially relevant for devices with small data buffers, which might, for example, overwrite data before the host is able to read it, due to a gap in the data flow between the host and device.
WinDriver's WDU_StreamXXX() functions, described in
To begin performing stream transfers, call the
WDU_StreamOpen() function
WinDriver supports both blocking and non-blocking stream transfers. The open
function's fBlocking parameter indicates which type of transfer to
perform (see explanation below). Streams that perform blocking transfers will
henceforth be referred to as "blocking streams", and streams that perform
non-blocking transfers will be referred to as "non-blocking streams".
The function's dwRxTxTimeout parameter indicates the desired
timeout period for transfers between the stream and the device.
After opening a stream, call WDU_StreamStart()
In the case of a read stream, the driver will constantly read data from the
device into the stream's buffer, in blocks of a pre-defined size (as set in the
dwRxSize parameter of the
WDU_StreamOpen() function
To read data from a read stream to the user-mode host application, call
WDU_StreamRead()
In case of a blocking stream, the read function blocks until the entire amount
of data requested by the application is transferred from the stream to the
application, or until the stream's attempt to read data from the device times
out.
In the case of a non-blocking stream, the function transfers to the application
as much of the requested data as possible, subject to the amount of data
currently available in the stream's data buffer, and returns immediately.
To write data from the user-mode host application to a write the stream, call
WDU_StreamWrite()
In case of a blocking stream, the function blocks until the entire data is
written to the stream, or until the stream's attempt to write data to the
device times out.
In the case of a non-blocking stream, the function writes as much of the write
data as currently possible to the stream, and returns immediately.
For both blocking and non-blocking transfers, the read/write function returns
the amount of bytes actually transferred between the stream and the calling
application within an output parameter —
*pdwBytesRead*pdwBytesWritten
You can flush an active stream at any time by calling the
WDU_StreamFlush() function
You can flush both blocking and non-blocking streams.
You can call WDU_StreamGetStatus()
To stop the data streaming between an active stream and the device, call
WDU_StreamStop()
An open stream can be stopped and restarted at any time until it is closed.
To close an open stream, call WDU_StreamClose()
The function stops the stream, including flushing its data to the device (in
the case of a write stream), before closing it.
Note: Each call to WDU_StreamOpen() must have a matching call to
WDU_StreamClose() later on in the code in order to perform the
necessary cleanup.