Re: [Libusb-devel] userspace URB processing

[Thomas J. <tho...@in...>]

Hi JE,

> > > > -> It can easily happen to have two or more of those status bytes
> > > >      in the usb_bulk_read stream.
> > >
> > > I believe you always see these status bytes at 64-byte boundaries,
> > > ie. at offset 0, 64, 128, 192, etc. in the FTDI data stream.
> > > Doing this on the result of usb_bulk_read worked fine for me.
> >
> > Thanks for your reply. On user of libftdi tried this, too, but it wasn't
> > stable. It depends on your readbuffer size and timing as the kernel
> > groups two or more URBs to one request if the usb_bulk_read buffer is big
> > enough.
>
> Actually it doesn't.
>
> usb_bulk_read() on Linux will result in one and only one URB being posted.

True that, but atleast the usb_bulk_read function in libusb's linux.c
groups together multiple reads if there's enough room in the buffer.

> > Think about the situation when you don't read fast enough: The status
> > bytes are generated every 16ms in the absence of data. When your next
> > read is f.e. after 48ms, you will have 3x2 status bytes in your stream
> > (which got transfered as 3 single URBs) -> You'll end up with 4 bogus
> > status bytes as only the first two get filtered by the ftdi_read_data
> > function.
>
> It sounds like the device is buffering those status bytes and sending
> multiple status packets into one transfer.

No, it creates an USB "packet" for each of them.

> Perhaps libftdi should handle all of the status bytes?
>
> It sounds like what you really wanted are queued transfers, since the
> data you get is sent every 16ms, you want an URB posted to receive the
> data when it occurs.

This is only a special case. Those status bytes are in every URB.

I'll try something out: I'll reduce libftdi's read buffer size to 64 bytes as 
this is the maximum size the device will handle internally
due to hardware limitations/bugs. After that I remove the do/while stuff
from libusb's usb_bulk_read. If everything goes well, it'll work :-)

If it works: Is there an API compatible way to add a "only-one-read" flag
to usb_bulk_read or would we need another bulk_read_function?
(which gets called internally if you use the normal bulk_read)

Cheers,
Thomas