class specifications should be written. Then it goes on to describe new features that may be used to extend the basic USB functionality.

Table 20.8 lists the USB extensions. The Shared Endpoint extension is described in the next section.

Support for the USB enhancements is indicated in the device descriptor. The device bDeviceSubClass field is 0x00 and bDeviceProtocol is a bitmap of supported features. Shared endpoint support is indicated in bit 0.

Currently, there seems to be no indication that Windows supports any of these new features[50].

Table 20.8 USB new feature summary

Shared Endpoints Allows one physical pipe to carry information from several logical pipes.
Synchronization Defines a standard way of reporting synchronization requirements for an endpoint.
Dynamic Interfaces Lets a device change its interface dynamically (e.g., a modem might receive either a voice call or a data call, and would want to change its interface accordingly).
Associations The ways in which different interfaces might be related (e.g., a modem data call might have voice and video information). Each interface requires a separate pipe. However, an association defines how the interfaces are related.
Interface Power Management An interface power descriptor might describe different: • power down states (apart from just suspended) or • methods of adjusting each interface's power.
Default Notification. Pipe A default notification pipe describes a common format for passing interrupt data to the host.

Shared Endpoints

Designers of some devices might find that they need many endpoints and pipes, which might require lots of resources. The basic USB standard says that only the default pipe Endpoint 0 can be shared between interfaces.

The Shared Endpoint USB extension allows several logical pipes to be carried on one normal 'physical' pipe. Such shared pipes must have the same transfer type (control, interrupt, bulk, or isochronous) and be in the same direction. Each logical pipe defines one or more logical packets for the data it might send.

Hosts and devices that handle shared pipes multiplex the data from each logical source on the physical pipe. For isochronous pipes, the combined maximum data packet size must fit into a frame. The software must ensure that a stall on one logical pipe does halt data flow on another logical pipe.

Flow control can optionally be implemented using a pipe in the opposite direction to data transfer. A source must not send data on a logical pipe until the target has provided a grant to send: a count of the number of logical packets it can receive.

Client Design

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

Endpoint Type Selection

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

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.

Conclusion

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату
×