On Tue, Jun 21, 2011 at 2:05 PM, Caleb Kemere <ckemere@xxxxxxxxx> wrote:
> On Mon, Jun 20, 2011 at 10:03 PM, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote:
>> On Tue, Jun 21, 2011 at 8:09 AM, Caleb Kemere <ckemere@xxxxxxxxx> 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
