On Apr 29, 9:53=A0am, H <H...@[EMAIL PROTECTED]
> wrote:
> I am reading data for a USB device using the following principle
> algorithms:
>
> algorithm (1)
> for (;;)
> {
> =A0...
> =A0(*dev)->ReadPipeTO(...,&size,10,10000);
> =A0...
> =A0if (size =3D=3D 0) break;
>
> }
>
> or
>
> algorithm(2)
> for (;;)
> {
> =A0...
> =A0milliSleep(10); // sleeps for 10 milliseconds
> =A0(*dev)->ReadPipeTO(...,&size,0,0);
> =A0...
> =A0if (size =3D=3D 0) break;
>
> }
>
> While I can read all the data from my device using algorithm 2 I cannot
> do with algorithm 1. In the middle of the transfer there is no data
> anymore available and algorithm 1 quits the for-loop too early. This
> does not occur with algorithm 2.
>
> From my point of view the two methods reading the USB device should be
> identical (ignoring the 10000 completion timeout in the ReadPipeTO). But
> they are not. Actually the second example works while the first one
> fails. Can anybody tell me where the difference is? Using Mac OSX 10.5.2
> and IOUSBInterfaceInterface220.
>
> Hartwig
>
> PS: What is the recommended parameter setting for =A0ReadPipeTO to
ignore
> the completion timeout (I assume 0)?
If you do not wish to use a timeout at all, you should use ReadPipe(),
not ReadPipeTO(). ReadPipe() will continue to block until data is
read, whereas ReadPipeTO() will keep reading until either the data is
read or the timeout period expires, whichever comes *FIRST*. Nothing
in the do***entation suggests that a timeout value of 0 in
ReadPipeTO() is the same as calling ReadPipe(), but you may have
lucked out as to this being how it is implemented.
If you choose to use ReadPipeTO(), remember that the minimum timeout
threshold is 1 second (1000 ms), so any value less than 1000 is
meaningless. I don't know what a timeout value of 0 means.
Another problem I see is that your code is not handling the cleanup
after a timeout. You are suppose to call ClearPipeStall() or
ClearPipeStallBothEnds() to resynchronize the data toggle. This may
be why algorithm(1) is failing. Using a 0 timeout in algorithm(2) may
be sidestepping this issue somehow, perhaps having no timeout
upsetting the toggle.
You might also consider using ReadPipeAsync(), or even placing
ReadPipe() into a separate thread. I am doing this now (the separate
read thread), and it works nicely. The read thread doing nothing but
continue to wait for ReadPipe() to return, and if/when it does so, the
thread appends a buffer with the new data and reissues ReadPipe(). My
main thread simply looks at this shared buffer to see if more data has
arrived, and I can implement my own virtual "timeout" mechanism
without upsetting Apple's USB toggle.
Jonathan Hoyle
Eastman Kodak
|
