Книга: Writing Windows WDM Device Drivers

Client Design

Client Design

This section briefly discusses options for both device firmware engineers and Windows device driver writers.

The different types of endpoint have different characteristics. Control transfers consist of messages or requests sent when the host dictates. Interrupt, bulk, and isochronous transfers are said to be stream pipes as they keep generating application defined data.

There is usually only one control pipe, for Endpoint 0. As well as carrying the USB set up and configuration standard transfers, you can use this pipe for the class-defined or your own vendor-defined requests. If need be, define any further control pipes.

Interrupt pipes are usually used for user input data, but they can also retrieve relatively infrequent data from the device. Interrupt pipes can be used in conjunction with isochronous pipes to provide feedback so that the data rate can be varied. As mentioned previously, a device can NAK an interrupt pipe request to indicate that no data has changed. Additionally, Chapter 23 shows that HID devices support the concept of an idle rate. This technique reduces the number of interrupt reports that are generated.

Devices that generate or consume data samples regularly will want to use isochronous transfers. Isochronous transfers can vary in length, and may be used in preference to bulk transfers as they reserve USB bus bandwidth. Isochronous transfers are not error checked, but a receiver can determine if a transmission error occurred by checking the frame number. Make sure that the application or device can cope with losing data. Bulk transfers are error checked, but they have the lowest priority on the bus.

Low-speed devices can only have two endpoints after Endpoint 0. Full-speed devices can have a maximum of 16 input and 16 output endpoints. Check that maximum packet size for your pipe type is acceptable.

Do not forget that if a pipe stalls, a control pipe request must be defined to clear the stall condition.

You might want to consider some of the new USB features, discussed earlier. Check that Windows supports the relevant feature.

Isochronous devices can represent quite a challenge to software designers. An isochronous input source usually generates a regular number of samples to represent their data, while an output sink receives samples and produces the relevant output.

A driver must firstly be able to handle the volume of data coming in and take appropriate steps if it cannot keep up. It is sometimes best if a set of samples can be left to build up for processing in one fell swoop, rather than processing each sample individually. Check that your application will survive this treatment.

Synchronizing a series of devices and processes is a more complicated issue. The clocks inside each device and inside the PC may all be running at different frequencies. Even if they are nominally at the same frequency, they may well drift or produce jitter.

A basic asynchronous source just sends any samples it has produced. A basic asynchronous sink might use a feedback interrupt pipe to tell the PC how many samples to send.

There are various techniques that devices and drivers can use to handle these difficulties. At the very least, some sort of rate adaptation or conversion may be necessary.

A common technique is to group the samples into service intervals and buffer the sample groups through the relevant processes. A driver might expect a set number of samples in a service interval. If not enough have arrived, a new sample or samples could be generated by interpolation. Similarly, if too many samples arrive, some should be dropped. This technique requires that you buffer up a set of samples for a service interval, one for each rate adaptation process. Check that the resultant delay through the system is acceptable, and that adding or dropping samples is satisfactory.

Another technique is to synchronize all activities to the 1kHz USB frame clock. An input source would generate the correct number of samples each frame, even if a different number had arrived. Make sure that your device copes if the USB Start of Frame (SOF) frame packet is corrupted.

An adaptive device interacts with the PC to tell it how many samples to send or receive. It might use an interrupt pipe to tell the host how to adjust its sample rate.

Frame Length Control

Another synchronization technique is for a device to obtain control of the USB frequency (i.e., take over mastership of the [SOF] packet rate). An SOF master adjusts the USB clock slightly to match its internal clock. However, only one device can take over USB bus master-snip, so a device should not rely on this technique.

There are Windows URB functions to request control of the USB frame length, and to get and set the current frame length. The frame length may be adjusted by only plus or minus one bit at a time. You can also get the current frame number.

Patterns

A final useful technique for isochronous transfers is to let the size of each transfer vary in a regular pattern to match the source data rate. The host and the endpoint must agree which frame begins the repeating pattern. One of the calls to the Windows USB drivers asks for the frame number which starts a pattern.

An audio signal could be sampled at 44.1kHz. This means that 44100 16 bit samples are generated every second. This corresponds to 44.1 samples every USB frame. Sending 45 samples per frame would be an acceptable solution, provided some special flag is used to indicate which frames have 45, rather than 44, samples. The recommended solution is to use a frame pattern. In this case, a pattern that repeats every 10ms should be used, consisting of nine frames of 44 samples and one frame of 45 samples. In total, exactly the right number of samples is sent, 44100 per second.

Оглавление книги