On Mon, 12 Sep 2005, Istvan De wrote:

> > It is.  Note that in general with bulk transfers, arrival of a 
> > short packet (32 bytes instead of 64, for example) indicates the end of a 
> > data stream.
> so you mean that a short packet will only arrive if the device sends a short
> packet or the usb core can decide that "ok, for now I return only this
> much,
> because this much arrived till this moment"? if the latter, how is
> "moment"
> defined, end of the USB frame?

I don't quite understand your question.  If the device sends a short
packet then a short packet will arrive, otherwise it won't.  The rule for
determining when a bulk URB is finished is this: The transfer is finished
when the number of bytes given in urb->length has been received or when a
short packet is received, whichever comes first.

> Because my device sends only 64 byte packets, no short packets..

Then why are you worried about what might happen if it sends a 32-byte 
packet?


> What I'll do probably is to segment the buffer into slots, and I'll have
> an
> int for each slot, containing the number of bytes received in that slot.

That sounds like a good way to do it.


> By the way, how do you decide on the URB's length?
> Obviously, the bigger the length, the more delay my PC-side application
> will suffer, but the more efficient the transfer will be. However if I
> go
> down to 64 byte URBs, delay will be very low, but the completion handler
> will be called more often.. or it is not so severe?

You have to balance off latency against processor overhead.  Also remember
that it's better to avoid trying to allocate large chunks of kernel memory
(much larger than 4 or 8 KB) all at once.

> The smallest chunk of data my application can use is around 5ms or 640
> bytes (the device
> sending 64byte packets),
> while the maximum delay I could tolerate is
> around 20ms
> , which comes down to 2560 bytes. Is there any reason not to stick to
> 640 byte URBs?

I would go for the maximum delay, but decreased a bit to allow for 
additional overhead (other interrupts or other processes running).  If you 
need latency <= 20 ms then set your URB size to somewhere around 10-15 ms 
worth of data.

Alan Stern



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to