On Mon, Jun 20, 2011 at 2:39 PM, Caleb Kemere <[email protected]> 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. 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? > if ((last_result > 0) | (transferred == 2)) > break; > else > bytes+= transferred; > } 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. > 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... Bulk transfer only guarantee the data integrity but the delivery is not guaranteed, it is a best effort kind of delivery. To make sure the host is able to schedule the transfers, you need to have data always available. > I have noticed something which I don't understand - on my laptop (Core > 2 Duo, about 3 years old), I get the performance described above. On > my desktop (Core i5, about 2 years old), I can run for many minutes > without ever running into trouble. Is there some way of understanding > what the USB on the laptop is doing differently? 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. -- Xiaofan -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
