On Mon, Jun 20, 2011 at 4:43 PM, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote:
> On Mon, Jun 20, 2011 at 2:39 PM, Caleb Kemere <ckemere@xxxxxxxxx> wrote:
>> I did test the asynchronous mode, but now I think I've distilled the
>> essence of the test down to the following really simple (blocking)
>> code:
>>
>> int transferred = 0;
>> int bytes = 0;
>> while (bytes < MAXIMUM_TRANSFER) {
>> last_result = libusb_bulk_transfer(ftdi.usb_dev, ftdi.out_ep,
>> buffer, bufferSize, &transferred, 1000);
>
> What is the bufferSize? It is an important parameter if you use
> synchronous transfer.
It seems like a larger bufferSize yields more data transferred without
overflowing the transmit buffer. I've been testing with 2MB, though
I'd ideally like to make this (much) smaller in order to get lower
latencies.
> You are saying that you are doing Device to PC then you should
> be doing Bulk IN transfer yet you use ftdi.out_ep. Since USB
> is host centric, typically the IN and OUT are from the host's
> point of view. So what is ftdi.out_ep? Is it an IN endpoint or
> an OUT endpoint?
To be honest, I looked at the code for ftdi_readstream, and "out_ep"
is what was being used to set up the transfers. Perhaps in this case
IN/OUT are from the perspective of the FT2232H?
> For this kind of application, it is better to use async API
> and the device may need to have certain buffer if you can not
> afford data lose. For example, if the PC for some reason
> is not able to get some data from the device in one transfer,
> then the device may need to have buffers for two transfer.
> I think Uwe's advice to try the streaming API is good.
My impression is that the FT2232H FIFO is already acting as a buffer
in some sense, no?
I'm planning to integrate this into a QT multithreaded application, so
having this thread block on USB is ok. Is the async API more efficient
in other ways?
>> I've been messing around with different values for the read-chunksize
>> of the FT2232H and the bufferSize of the bulk transfer. As a reminder,
>> my data streams from the FPGA to the FT2232H at 6.5 MB/s. With that, I
>> can consistently read for about a 30 s or so before I get a buffer
>> overflow (at half speed, I can go for about 3 times that long). It
>> seems like the USB subsystem should be able to handle that data rate
>> for an arbitrary length of time, so I'm wondering what I could be
>> doing wrong...
> The USB host USB driver and system performance have some
> effect on the bulk transfer performance. As mentioned before,
> bulk transfer is a best effort kind of delivery, the bandwidth is
> not guaranteed, So different host system may schedule
> different number of packets in a microframe (125 us for
> high speed USB) which result in different speed. Slower
> system (or slower USB host controller) may be prone to
> drop a transfer as well.
It must be that the USB host controller on my laptop is deficient. It
can't be *that* bad, though, or it would not work at all, so I'm still
curious if there's something I could do to help it.
I really appreciate everybody's insight. Thanks again!
– caleb
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
