Hello,

Thanks for your updates and for your inputs too Allen,

Yes unfortunately the USB transfers are limited to 64K on the interrupt endpoints and so although the device can run at 12Mbaud and 3.4M I2C, the actual throughput will not match these.

We specify this on page 12 of the datasheet but it is in amongst the text and is also not directly referring to the baud and I2C rates. We can look at improving the datasheet to make sure that this limitation is clear and stated explicitly as you suggested,

Sorry to hear the FT260 is not suitable. The FT260 is ideal for many uses as it uses HID class but the throughput is limited by this. We have other hi-speed USB devices which use bulk transfers such as the FT4222H which might be an option for you,
Bulk transfers don't offer guaranteed bandwidth at any instant as the bandwidth is shared with other devices and so can depend what other devices you have connected to the PC, but the overall bandwidth is usually much higher than this 64K interrupt transfer on the FT260.

Best Regards, FTDI Community

Hi Willy,
We have replicated the observed issue and are working on it.
If/When a fix is in place i will follow up with you. 

Regards
FTDI Community

Hello,

You are already in contact with our technical support team on this matter.

Please feel free to post any resolution here to help other community users.

There may also be other FTDI Community users who will be able to help you.

Best Regards,
FTDI Community

Hi,

One thing to check is that you have set timeouts to a finite value (e.g. 5000ms) which will avoid the read and writes hanging if they are unable to complete. You should check the status value once a call returns as well as comparing the sizeTransferred, which is provided by the read and write functions, to what you had requested, to see if all data was written/read.

Best Regards, FTDI Community

Hello,

You are correct, the driver retrieves the data from the chip automatically and stores it in the driver buffer within the PC and so you are reading the data from this local buffer. You can check the RxStatus to see how many bytes are available in this buffer.

Best Regards, FTDI Community

Hi,

We can try this out to see if we can see the same thing,

What timebase was your scope on and so what kind of pause duration were you seeing in each case?

One thing to note is that the FT260 uses interrupt transfers which support 64Kbytes/sec (for each IN or out pipe) and so the throughput will be limited by this, this may be one factor in the delay you see. 

Best Regards, FTDI Community

Hello,

The FTCI2C.dll is no longer supported so we would recommend using the LibMPSSE.dll for new projects. however unfortunately the LibMPSSE helper library only supports GPIO functionality on the GPIOH pins.

There are two options for programming the MPSSE on the device to act as a SPI/I2C bridge, the first being to utilise LibMPSSE
The second option is to use raw D2XX commands to issue opcodes and data to the device, please see the following for a list of MPSSE opcodes:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf

You will need to utilise a D2XX approach if you wish to utilise the GPIOL pins in your application.

Please see the following for an example of using raw D2XX commands in an I2C MPSSE application:
https://ftdichip.com/wp-content/uploads/2020/08/AN_113_FTDI_Hi_Speed_USB_To_I2C_Example.pdf

The MPSSE Basics application note may also be useful to you:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

Best Regards,
FTDI Community