On Tue, Jun 21, 2011 at 2:05 PM, Caleb Kemere <[email protected]> wrote: > On Mon, Jun 20, 2011 at 10:03 PM, Xiaofan Chen <[email protected]> wrote: >> On Tue, Jun 21, 2011 at 8:09 AM, Caleb Kemere <[email protected]> wrote: >> >> If you use synchronous API, the main way to help is to increase >> the bufferSize but then there is a limit. After all, the internal buffer >> of FTDI chips are limited (two buffers, each 512Bytes in the FIFO >> mode, for FT2232H, even though the RX/TX buffer is 4KB). So if >> the host fails to fire one USB IN request for 512B, you are still >> fine but if the host fails to fire two USB IN requests, you are done. > > Interesting, so the FT2232H is only using 512B of it's FIFO's? I don't > fully understand the frames and microframes of USB 2.0 - does the > kernel generate a schedule based on the frame clock (1 kHz)? That > could explain a lot - that would mean that if I ever missed scheduling > a frame, I'd be locked out for 1 ms (and would buffer overflow)....
For full speed USB, it is based on a USB frame which is 1ms. For high speed USB, it is based on a USB microframe which is 125us. The schedule is done by the host controller (EHCI). The host PC program may suffer another OS scheduler delay, like the Windows 10ms to 16ms delay. That is another thing to consider. If you think USB 2.0 specification is too long to read, here is a short introduction which may help. http://www.usbmadesimple.co.uk/ http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf (not updated for high speed FTDI device yet). It has the following. ************************************ 2.2 Data Transfer Comparison USB does not transfer data using interrupts. It uses a scheduled system and as a result, there can be periods when the USB request does not get scheduled and, if handshaking is not used, data loss will occur. An example of scheduling delays can be seen if an open application is dragged around using the mouse. For a USB device, data transfer is done in packets. If data is to be sent from the PC, then a packet of data is built up by the device driver and sent to the USB scheduler. This scheduler puts the request onto the list of tasks for the USB host controller to perform. This will typically take at least 1 millisecond to execute because it will not pick up the new request until the next 'USB Frame' (the frame period is 1 millisecond). Therefore there is a sizable overhead (depending on your required throughput) associated with moving the data from the application to the USB device. If data were sent 'a byte at a time' by an application, this would severely limit the overall throughput of the system as a whole. *********************************** The above is for full speed USB. For high speed USB, replace the Frame with MicroFrame. -- Xiaofan -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
