Re: [libusb] less data length in async bulk transfer with 2 cameras

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

zheng rong wrote:
>
> Now I am trying to use ISOC transfer mode in my design, but confused 
> by the bandwidth consideration. The device has 4K buffer in isoc mode.

Are you using a Cypress FX2?


> The maximum bandwidth for USB2.0 high-speed isoc transfer is 3x1024 
> B/uframe x 8K uframe/second=24MB/s, for one endpoint.
>
> Is it possible to use this configuration to handle a device with burst 
> datarate=27MB/s but average datarate=15MB/s?
>
> For example, in my design, the device is a camera, and the pixel clock 
> is 27MHz in frame valid period, (one byte for one poxel) so the 
> datarate is 27MB/s during frame valid interval. While the total 
> datarate is e.g. 15MB/s. From my understanding, the isoc xfer will get 
> data lost because the device fifo buffer (4KB now on my device) is not 
> enough to buffer an image frame (360960 Bytes) to handle the 
> difference between 27M  burst rate and 24M xfer bandwidth, even though 
> we don't miss any microframe. Is my understanding right?
>

You'll need to sit down with paper and pencil to figure this out, but I 
suspect you have a problem.  I did an FX2 design with a camera that had 
exactly this problem.  It works OK on some systems, and not on others, 
depending on the quality of the host controller.

Your pixel stream isn't actually continuous during a frame.  You get 
continuous pixels during a scanline, then there's a pause during 
horizontal blanking, and a longer pause during vertical blanking. Your 
frame must be 640x564, so it takes two scanlines to get a packet ready 
to send.  If you count the H blanking, does the timing work out?  Will 
you accumulate more than 3072 bytes in 125 microseconds?  If so, then 
you will require an external FIFO to survive the bursting.


> If I decrease the pixel clock to 24MHz or lower, is it possible to 
> make it work?

It should, yes.

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