Re: [libusb] Issue with Bulk Transfer in Raspberry PI

[Alan S. <st...@ro...>]

On Tue, 31 Dec 2013, Tim Roberts wrote:

> Abhishek Madaan wrote:
> >
> > With a camera, you have a very definite concept of a "transfer".  In
> > your case, a "transfer" is 614,400 bytes, which of course gets divided
> > up into 512-byte packets.  With a bulk pipe, the convention is that
> > you terminate a "transfer" by sending a short packet.  If the transfer
> > happens to be a multiple of 512, then you send a zero-length packet.
> >  When that happens, the request will be completed immediately and sent
> > back to you, without forcing you to wait for a timeout.  You can stay
> > in sync without hoping that the timing happened to work out correctly.
> >
> > I think i miss the boat on this one. What i was thinking from the host
> > level you tell how many bytes you need to receive. If you receive the
> > number of bytes you asked for, the request complete immediately. It
> > won't have to timeout to complete the transaction. It really seems to
> > work this way on PC using Cypress drivers.
> 
> No, you are correct -- the transfer ends when EITHER the byte count is
> satisfied OR a short packet gets sent.  The advantage of using a short
> packet is that you will know immediately if bytes were lost somewhere. 
> You don't have to wait a full second for a timeout.

But if the byte count is a multiple of 512 then sending a short packet 
will involve an extra, unnecessary transfer.  For example, suppose the 
byte count is 614400.  You send that many bytes (broken up into 1200 
512-byte packets) and then send a short packet containing 0 bytes.

The host receives the 1200 packets of data and realizes the transfer 
has ended, because the byte count has been fulfilled.  So then the host 
starts the next transfer.  But this one ends immediately, because it is 
terminated when the 0-byte packet arrives.  This causes extra trouble 
for the host.

> > I have another question from you. I know the bulk transfer is
> > asynchronous. Is there any way to make the transfer synchronous. what
> > i mean is there any way to tell the CPU to ignore every other request,
> > Interrupts while doing this transfer? I can't think any other way
> > where this bottleneck and causing this packet loss.
> 
> No.  If there isn't enough horsepower, then there isn't enough
> horsepower, and no mucking around with priorities is going to fix it. 
> However, once you submit a request and the host controller driver sets
> up the schedule, the actual transfers are all handled by the host
> controller hardware.  Software is not involved.

That is not necessarily true; it depends on the USB hardware.  Some 
controllers are very underpowered and rely on the system software for 
much of the processing.  I don't know what hardware the RPi uses, but 
it wouldn't be surprising for a low-price system to use cheap 
controllers that can't handle everything by themselves.

Alan Stern