FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Pages: [1] 2 3 ... 10
 on: February 14, 2024, 04:42:46 PM 
Started by jaypdx - Last Post by FTDI Community

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

Best regards
FTDI Community

 on: February 13, 2024, 03:32:43 PM 
Started by jaypdx - Last Post by 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?

 on: February 13, 2024, 02:02:36 PM 
Started by jaypdx - Last Post by FTDI Community

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

Best Regards
FTDI Community

 on: February 13, 2024, 01:59:21 AM 
Started by jaypdx - Last Post by 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?

 on: January 19, 2024, 04:19:30 PM 
Started by Zoltan - Last Post by FTDI Community

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

 on: January 18, 2024, 05:46:40 PM 
Started by Zoltan - Last Post by Zoltan

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...


 on: January 09, 2024, 04:52:01 PM 
Started by BigApple - Last Post by BigApple
Sounds good thank you!

 on: January 09, 2024, 01:36:13 PM 
Started by BigApple - Last Post by FTDI Community

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

 on: January 08, 2024, 08:23:39 PM 
Started by bryantsorensen - Last Post by BigApple
You should fix these bugs.  I just ran into similar issues.

 on: January 08, 2024, 08:18:38 PM 
Started by BigApple - Last Post by BigApple
I downloaded the DLL libraries, examples, and source code from the following link

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

Code: [Select]
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
Code: [Select]
{/*Get ack*/
noOfBytes = 1;
noOfBytesTransferred = 0;
status = FT_Channel_Read(I2C, handle, noOfBytes, inBuffer,

I'm confused about the
Code: [Select]
/*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.

Pages: [1] 2 3 ... 10