Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-10-20
2001-10-30
Ray, Gopal C. (Department: 2181)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C710S033000, C710S063000
Reexamination Certificate
active
06311294
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates generally to a device and method for data retrieval over an electrical bus which connects various peripheral components of a computer system together, and in particular to a device and method which provides efficient bulk data retrieval over a Universal Serial Bus (USB).
A typical personal computer system has a main central processing unit (CPU) enclosed within a housing and one or more peripheral devices, such as a keyboard, a mouse, a monitor, a modem or a printer connected to the housing and electrically connected to the CPU by a unique connector and an electrical bus, respectively. These different connectors and electrical buses include serial buses, parallel buses and RS-232 ports. Typically, each of these different buses had different signaling requirements and different connectors to the housing. For example, a parallel bus has a certain physical connector and communicates bits of data in parallel (i.e., a predetermined number of bits at the same time). In contrast, a serial bus may have a different physical connector and may transmit bits of data in a serial manner (i.e., one bit at a time).
In order to connect a keyboard, printer, monitor, modem or mouse to the personal computer, it was often necessary to use several different types of local electrical buses and associated ports, such as a serial port for a modem, a parallel port for the printer, a keyboard port and a mouse port. This leads to unnecessary complexity since each peripheral device may use a different bus. Therefore, a new universal serial bus (USB) was created to provide a standard interconnect for peripherals, and to facilitate connecting peripheral devices to the computer. The USB not only replaces the multiple cables and physical connectors typically needed with a single standardized connection system, it provides a standard electrical specification. The USB also permits peripheral devices to be connected and/or disconnected from the bus while the computer system is powered up which eliminates the need, with conventional buses, to power down and “re-boot” every time that a peripheral device is connected or disconnected. The USB further permits a peripheral connected to the USB to be detected and then a configuration process for the device, known as enumeration, may be commenced.
In any USB architecture, there is a single master (the USB host) which communicated with one or more slaves (the USB devices). Between each USB host and each USB device, there may be one or more communication/data flows which may include a control flow, an interrupt flow, a bulk flow and an isochronous flow as described below. Within each USB device interface, there may be one or more logical endpoints which have unique endpoint addresses so that each endpoint corresponds to the one or more communication/data flows. Each endpoint is a uniquely identifiable portion of a USB device that is the end of a particular communications flow between the host and the device. Each endpoint may communicate data in only one direction (e.g., an “IN” direction to the host and an “OUT” direction to the device interface). Thus, for each USB interface, there may be four different types of endpoints which accommodate control data flows, interrupt data flows, bulk data flows and isochronous data flows.
Each different endpoint and communications flow has different characteristics which are suited for the particular type of data being transferred. For example, the control, interrupt and bulk endpoints have built-in error checking and resend to guarantee data integrity while the isochronous endpoint has less built in error checking and no ability to resend. As another example, isochronous and interrupt or isochronous endpoints, and to some extent control endpoints, have a guaranteed bandwidth while the bulk endpoint does not have a guaranteed bandwidth. The control endpoint is particularly suited for communicating commands to a USB device while the interrupt or isochronous endpoint is particularly suited for communicating one data packet (e.g., no more than 64 bytes) at a specified interval, such as no more than once per frame (about 1 mS). The bulk endpoint is suited for communicating raw data that requires data integrity, but that is not time sensitive while the isochronous endpoint is suited for raw data which is time sensitive and needs a certain number of bytes passed per frame, but that is not sensitive to data corruption or data loss.
Some software applications which utilize the USB (USB applications) may use the bulk data IN endpoint of the USB to communicate data from the USB device interface back to the host. For example, USB applications that require low latency, error-checked, high throughput retrieval of bulk data from the device which needs to be communicated at an unpredictable rate often use the bulk IN endpoint. The problem with using the bulk IN endpoint is that the bulk endpoints have no bandwidth guarantee and therefore may suffer from severe latency problems in retrieving the data. This problem is exacerbated when the bulk data arrives at unpredictable times because there is no guarantee that any bandwidth will be available at the time the bulk data is ready for retrieval. Therefore, the host driver of the USB device which is receiving the data is not guaranteed to get the data as soon as it wants it and it also does not know when the data will be available for retrieval.
In typical USB devices, a brute force solution to this problem with the bulk IN endpoint is used. In particular, the device driver via the operating system will continuously send bulk data request signals (known as IN tokens) to the device which will be responded to with “not acknowledged” signals (NAKs) repetitively by the device until some bulk data is generated by the device. Once there is bulk data to be communicated, the IN tokens are responded to with the data instead of the NAKs. Once all of the bulk data has been communicated, the device returns to the state of sending NAKs in response to the IN tokens until more bulk data is ready to be communicated. This process may be referred to as the conventional “pending-IN” process.
Although this pending-IN process incurs the least latency in retrieving bulk data from the device since bulk data is retrieved as soon as it is available, the pending-IN process generates it own problems because it is inefficient. In particular, the pending-In process places extra burden on the USB bus because of the constant sending of the IN tokens and the NAKs even when no bulk data is available. In addition, since the USB host controller typically utilizes the host computer's central processing unit (CPU) and system bus, this pending-IN process degrades not only the performance and throughput of the USB bus, but also the overall system performance of the host computer. This degradation of the USB bus and host computer's performance is not acceptable. A second problem with this approach is that, unlike a data response, the NAK from the device does not reset the error count in the USB host. Thus, if three errors (missing or corrupted NAK packets) accumulate during the time that the device is sending NAKs, then the device may appear broken to the USB host. Thus, it is desirable to provide a device and method for efficient bulk data retrieval over a USB which avoids the problems of the conventional pending-IN process, and it is to this end that the present invention is directed.
SUMMARY OF THE INVENTION
In accordance with the invention, a device and method for efficient bulk data retrieval over a USB is provided which solves the problems associated with the pending-IN strategy described above without incurring too much additional latency. In particular, the method may be interrupt-driven while achieving the low latency and high data throughput of the conventional pending-IN strategy. In more detail, the method may use an interrupt or isochronous endpoint and a “dry” flag, as described below in more detail, that is sent from the bulk endpoint to provide an efficient bulk data
Kolokowsly Steve
Larky Steven P.
McCoy Mark
Swindle Scott
Christopher P. Maiorana P.C.
Cypress Semiconductor Corp.
Ray Gopal C.
LandOfFree
Device and method for efficient bulk data retrieval using a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Device and method for efficient bulk data retrieval using a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Device and method for efficient bulk data retrieval using a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2563593