Posts Tagged ‘data’
The Flow Control Condition on Responding
Posted by Parkzone Corsair in USB on February 6th, 2010
To conserve bandwidth and to enable inactive links to transition to low-power states, USB 3.0 hosts stop requesting to send or receive data from SuperSpeed endpoints that are in the flow control condition. This condition indicates that the endpoint temporarily can’t send or receive data. To request to resume communications, the endpoint sends an ERDY Transaction Packet. A device can send the ERDY at any time without waiting for the host to request a packet.
On receiving the ERDY, the host resumes communications with the endpoint. An IN endpoint is in the flow control condition after responding to an ACK Transaction Packet with either of the following A NRDY Transaction Packet. A Data Packet with the End of Burst (EOB) field set to 1, indicating that the packet is the last in a burst. The device sets EOB if the data payload is equal to the endpoint’s maximum packet size and the endpoint is returning fewer than the number of packets requested in the previous ACK Transaction Packet.
An OUT endpoint is in the flow control condition on responding to a Data Packet with either of the following A NRDY Transaction Packet. An ACK Transaction Packet with the NumP field set to zero, indicating that the endpoint can’t accept any Data Packets. Hosts retain the option to attempt communications with bulk endpoints in the flow-control condition before receiving ERDY.
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.
