First of all, since the controller needs to poll on power of 2
intervals, we will convert your 10ms interval to 8ms.
You are saying that you need to queue up 1000 (!) reads, implying
that you are seeing delays of 8000ms between consecutive reads. That
seems very, very strange. Are you sure?
I would find out what the worst case delay between the IN being
completed on the bus and your callback finishing (and hence your read
re-queued) and then queue up enough reads to make sure that you cover
that case with a safety factor. For example, if you see delays of up
to 100ms, queue up 15 reads or so. Of course, having a better
behaved device would be simple :-).
Issuing 1000 reads will consume a lot of resources, probably
unnecessarily.
HTH,
--
Fernando Urbina
USB Technology Team
Apple Computer, Inc.
On Aug 7, 2005, at 10:07 AM, Matt Bendiksen wrote:
There isn't a good way for me to know when the device needs to send
data quickly, so I tried queuing up a bunch of 8 byte ReadPipeAsync
() requests at once. This seems to work well. However, in order to
handle cases where around 8K of data might be send, I need to queue
up around 1000 ReadPipeAsync() calls. Maybe I don't really need
that many since I'm still calling ReadPipeAsync() in my read
complete proc, but I'm not sure how often/quickly my read complete
callback is guaranteed to be called.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
