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

[Tim R. <ti...@pr...>]

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.


> 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.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.