Date: October 24, 2006 1:25:04 PM CDT
Subject: Re: ReadPipeTO timeouts not working?
Well, I sort of hacked around it. if I get one of these 0 length replies, I just sleep the thread for 1 sec, then try again, and do my own timeout calculations, before returning a success or error from the libusb bulk transfer.
Seems to work ok, and solves the CPU utilization problem. Probably not the best solution for high speed devices, but I am not sure libusb uses the correct impl there anyway.
On a side note to that, are the kernel drivers doing any buffering on the pipes. What I mean is that if I do not have an outstanding ReadPipe or ReadPipeAsync on the pipe, and the devices sends data, is it lost? Or is there some lower level buffer or protocol that would not allow this to happen (i.e. the device is prohibited from sending if there are no outstanding reads).
On Oct 24, 2006, at 1:15 PM, Barry Twycross wrote:
At 11:54 AM -0500 10/24/06, robert engels wrote:
What I have found is that during certain exchange sequences, ReadPipeTO with a timeout specified (45000ms) returns immediately with kIOReturnSuccess but a read size of 0.
How can this be? Could the printer be signaling a NAK, or some such thing, and ReadPipeTO is interpreting this as a valid read.
It could be returning a zero length packet, only a bus trace would tell you for sure. You might get some hints from the logging family at a high logging level.
A NAK should never cause a completion.
I've seen printers which do return zero length packets when they have nothing to say. Its a reasonable way of saving bus bandwidth.
--
Barry Twycross
---
USB, it's not a Dyslexic BUS. (Thanks to TC.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
