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?

Hello,

There are 2 kinds of delays / pauses.

1. Occurs when FIFO switches from ping to pong buffer. There are 2 FIFO Buffers and when current one gets filled, hardware moves to second FIFO. There will be a brief delay during this period.
2. Occurs when a session is ended and a new session is created. This delay can be slightly larger than the above one.
A session will be ended when the length of transferred data equals with the stream length set by FT_SetStreamPipe API (if not in stream mode, then the length passed in Read Pipe API), or when an unaligned write happens.
 
Between the end of session and start of new session, there could be some delay as observed.

If the stream length is shorter, this delay will be seen often.
The recommended stream length is, several multiples of the FIFO size.
For example, if the FT600 configuration uses 4K FIFO size, it's best to make the stream length as multiples of 4K - Say 10 times or 100 times of 4K.
This way, instead of seeing a long delay every 4K, the long delay will happen only at 400K transfer boundaries.

The FPGA is expected to buffer at least a FIFO size worth of data so that the delay does not cause any issues such as overflow.

If you have any additional questions please contact us via email as we have already been in contact with you.

Best Regards,
FTDI Community

Hi

I would need continuous communication between the IC and the PC, at a speed of 160MB/sec. There is no problem with the speed, but the communication between the IC and the data source is not continuous, but intermittent!
I am currently using a test environment for testing. Here, I upload the data to the IC at a speed of 100MHz, and this is continuous for 20.47usec. Then in each case comes an approx. 0.5-1usec pause in reception (TXE_N=1), after which the whole cycle starts again.
The time of 20.47usec matches the size of the internal FIFO (1 channel out, 1 channel in direction = 2048 words), but I don't understand why there is a little pause afterwards??!

But that's the minor problem. The biggest one is that in stream mode, when the value set on the FT_SetStreamPipe API is reached, a pause occurs again (TXE_N=1), but this lasts for about 10usec! Whatever size is specified for the ulStreamSize parameter, there is always a pause of approx. 10usec at the end!
This is quite a problem, because the data source requires continuous communication, and the bigger the pause in the communication, the bigger the buffer I have to use to bridge these pauses.
This big pause is there even if I used my own test program and even if I tested it in the FT600DataStreamerDemoApp program!

Does anyone have an idea of what causes these regular pauses? And is there any way to eliminate them? But at least the goal would be to eliminate the 10usec pause...

Thanks

Sounds good thank you!

Hi,

This is a known issue, and there is a fix. if you send an email to support1@ftdichip.com, we can send you a fixed version.

Best Regards
FTDI Community

You should fix these bugs.  I just ran into similar issues.

I downloaded the DLL libraries, examples, and source code from the following link
https://ftdichip.com/software-examples/mpsse-projects/libmpsse-i2c-examples/

After running the code I noticed that the library is having an issue reading the ACK bit.

In the attached scope capture, the slave successfully acknowledges the 9th bit.  However, the FTDI device does not see it.

In LibMPSSE-I2C, I noticed there's a function called: static FT_STATUS I2C_Write8bitsAndGetAck(FT_HANDLE handle, uint8 data, bool *ack)

The function appears to call

status = FT_Channel_Write(I2C, handle, noOfBytes, buffer, &noOfBytesTransferred);
which writes a byte a data along with the 9th clock for the acknowledge bit.

For some reason, the code then calls this
{/*Get ack*/
noOfBytes = 1;
noOfBytesTransferred = 0;
INFRA_SLEEP(1);
status = FT_Channel_Read(I2C, handle, noOfBytes, inBuffer,
&noOfBytesTransferred);
I'm confused about the /*Get Ack*/ code.  Exactly where does the I2C library read the ACK bit?

From what I can tell the library reads the acknowledge bit AFTER the 9th clock.  Is this correct?

Based on my understanding of I2C, this is the wrong time to read the acknowledge bit.

Hi,
If you use FT_SetBitMode to reset (zero for reset)   
https://ftdichip.com/wp-content/uploads/2023/09/D2XX_Programmers_Guide.pdf (Page 66, D2xx programmers guide)

Regards
FTDI Community

Hi,

I realized that the only option I have is to use bitbang mode and implement the UART protocol myself. It's not a problem, I just need to send 10 bytes for every byte I actually wanted to send. However, when I use FT_SetBaudRate() to set the UART speed, the resulting speed is 5 times faster than I expected. So to get 115200 I have to call FT_SetBaudRate(115200/5). What am I doing wrong?

Regards,
Slava

Hello,

There are no issues with changing the Manufacturer/Description/Serial string without change VID/PID.

Best Regards,
FTDI Community