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

[Abhishek M. <abm...@ya...>]

Hi Tim Roberts,
                           Thanks for your reply. 

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


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?

Thanks for the suggestion. I can check the FIFO overflow bits using the command request. I think it is spread throughout. Yup, 8192 is an odd number and i don't why it is happening. I would think there is a loss of packets than this number should be random instead of just 8192. 

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.

Regards



On Tuesday, December 31, 2013 12:11 PM, Tim Roberts <ti...@pr...> wrote:
 
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. 

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

_______________________________________________
libusb-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel