Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[jaypdx]

We're using an FT2232HQ to interface with an I2C peripheral.  We're basically writing two bytes and then reading back four bytes over and over.  We're seeing a delay of between 1-2ms between each transfer (this is once we change the latency timer to 2).  Is there any way to reduce this dead time?  Is it limited by the USB 'polling interval'?  I understand the polling interval is 1ms for full-speed and 125us for high-speed USB.  Does the FT2232HQ support high-speed USB operation for I2C?

[FTDI Community]

Hi,

You can try setting the latency timer to 1ms. This will make the device ran as fast as it can.

Best Regards
FTDI Community

[jaypdx]

Yes I've done this and it is a little faster than set_latency_timer(2).  But doesn't this device support high-speed USB (480Mbits/s)?  Or does it only run at full-speed (12Mbps) for I2C transfers?

[FTDI Community]

Hi,

yes, FT2232H is a high-speed device. The driver can only operate with 1ms latency minimum.

Best regards
FTDI Community

[cioma]

I worked with FT2232H directly through libusb, without FTDI drivers.

Here are notes from my code regarding latency timer:

Set receive buffer latency timer (vendor-specific command)
Latency Timer is used as a timeout to flush short packets of data back to the host
The default is 16 ms, but it can be altered between 0 ms and 255 ms
At 0 ms latency packet transfer is done on every high speed microframe (every 125 us)
For MPSSE it's recommended to set it to the default 16 ms and use "send_immediate" command to send bytes back to host when required
This approach seems to be working fine for FT2232H but with FT232H there seems to be a latency delay present on the first small packet transfer therefore latency is set to 1
This was observed while programming SPI flash and checking its status register value