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

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

Abhishek Madaan wrote:
>
> So I am calling the filling the bulk loop with an array of unsigned
> short 640x480 with a size of 614400.
>
> And are you sending a short packet when the frame is complete?
> No, We don't need to as 614400 is a multiple of 512. Correct me if I
> am wrong.

Your math is correct, of course, but that's not the issue.  If you don't
use a short packet, then you don't have any way to know when a frame is
complete.  You have to rely on timeouts, and as you have seen those are
not always reliable.

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.


> The problem I am receiving that sometimes I able to only get 606208
> bytes before the bulk transfer times out. Is the speed of the CPU
> matters in the transfer?
> Unfortunately, we don't have any buffer at the firmware level. We are
> receiving the data on the Ports B and D and sending to the host. Our
> assumption is that host should able to receive the frame faster than
> the device can send. It works great on a regular computer but we are
> facing issues with raspberry pi.

Cameras have special considerations that make the math more
complicated.  Even if the average bandwidth is sufficient, remember that
the FIFO data neither comes nor goes at a constant rate.  Cameras are
bursty, and USB is bursty.  With a camera sensor, you get a sudden push
of data at the beginning of a scanline, then when you reach horizontal
blank, there's a pause.  That pattern continues until you reach vertical
blank, then again there's a long gap.  On the other end, the FX2 USB
engine cannot free up a 512 packet until it knows for certain that the
transfer was successful.  While it is doing that transfer, you are
filling up the FIFO at the other end.  If there's a retry, or you happen
to hit a busy time on the bus, that FIFO can fill very quickly, and if
you aren't watching for the FIFO to fill, scanlines fall on the floor. 
If you don't have your own frame buffer, those pixels are lost forever.

Say, for example, that you are running your sensor at NTSC rates, 27
MHz.  One scanline at 16 bits per pixel takes about 60 microseconds, and
produces 1440 bytes.  That's less than half of a USB microframe.  1440
bytes plus a 512 byte packet in process makes 1952 bytes, which is
dangerously close to the 2048 size of a quad-buffered FX2 endpoint.  The
timing is very delicate.

It might behoove you to add a vendor command to let you read the "FIFO
overflow" bits in the FX2.  That would tell you if this is really what
is happening.

The fact that the shortfall is so consistent (8192) is suspicious.  Are
you able to determine whether the gap is at the beginning, at the end,
or spread throughout?

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