Archive for the ‘USB’ Category
Receive Communications From the Hub
Posted by Parkzone Corsair in USB on January 24th, 2010
The hub repeater in a USB 1.x hub handles low- and full-speed traffic. A USB 2.0 hub also uses this type of repeater when its upstream port connects to a full-speed bus. In this case, the USB 2.0 hub doesn’t send or receive high-speed traffic but instead functions identically to a USB 1.x hub.
A low- and full-speed repeater re-transmits all low- and full-speed packets received from the host, including data that has passed through one or more additional hubs, to all enabled, full-speed, downstream ports. Enabled ports include all ports with attached devices that are ready to receive communications from the hub. Devices with ports that aren’t enabled include devices that the host controller has stopped communicating with due to errors or other problems, devices in the Suspend state, and devices that aren’t yet ready to communicate because they have just been attached or are in the process of exiting the Suspend state.
The hub repeater doesn’t translate, examine the contents of, or process the traffic to or from full-speed ports. The repeater just regenerates the edges of the signal transitions and passes the traffic on.
USB Communications Under Windows
Posted by Parkzone Corsair in USB on January 12th, 2010
This chapter explains how a Windows PC manages communications with USB devices. The driver architecture described applies to Windows XP and Windows Vista, but much of the information also applies to other Windows editions.
A device driver is a software component that enables applications to access a
hardware device. The hardware device may be a printer, modem, keyboard, video display, data-acquisition unit, or just about anything controlled by circuits the CPU can access. Most USB devices are external devices that connect via cables (or wireless links). Some USB devices, such as fingerprint scanners, are in the box with the CPU.
USB communications under Windows use a layered driver model where each
driver in a series, or stack, performs a portion of the communication task. At the top of the stack is a client driver that the operating system has assigned to
the device. Another term for client driver is function driver. USB class drivers and vendor-specific device drivers are client drivers. Applications access a USB device by communicating with the client driver. The client driver in turn communicates with lower-level bus and port drivers that access the hardware. One or more filter drivers can supplement a client driver or bus driver. Dividing communications into layers is efficient because devices that have tasks in common can use the same driver for those tasks. For example, it makes sense to have one set of drivers that handle tasks common to all USB devices. An operating system can provide these drivers so device vendors don’t have to do so with much duplication of effort.
Define Protocols for Data or Messaging
Posted by Parkzone Corsair in USB on January 12th, 2010
The personal healthcare device class encompasses devices that help to maintain health and wellness, manage disease, and enable independent living for the elderly.Devices in the class include heart-rate and blood-pressure monitors, glucose meters, pulse oximeters, motion sensors, and pill monitors.
The class doesn’t define protocols for data or messaging. Devices may use data and messaging standards defined in the ISO/IEEE 11073-20601 Base Exchange Protocol. A device may send data that is episodic (at irregular or infrequent intervals) or continuous. A device may collect and store data before transmitting the data to the host, and a device may collect data when detached from the host. For example, a jogger might wear a monitor while out for a run and upload the data on returning home. Devices may support host-to-device communications to receive configuration data and other episodic data from a host.
The preferred location for the class code is in the interface descriptor, but declaring the class in the device descriptor is allowed. The function must have at least one bulk endpoint in each direction. An interrupt IN endpoint and additional endpoints are optional.
Several class-specific descriptors provide class-specific information. A PHDC
Class Function descriptor specifies the device’s data and messaging protocols. If needed, a Function Extension descriptor follows the PHDC Class Function descriptor. Following each endpoint descriptor is a PHDC QoS descriptor with attributes that describe the latency and reliability of the data channel. If needed, a PHDC MetaData descriptor follows the PHDC QoS descriptor to provide application-specific information.
