Hello,

We have measured i2c write/read on Windows and Linux platform.

The test consists of:
1.            Read / Write 10 bytes
2.            Using different frequency 500Kbps/1000Kbps/3400Kbps

The difference is very small:

Linux i2c write                                 
500Kbps  1000Kbps   3400Kbps
305us      206us        250us

Windows i2c write                                         
500Kbps  1000Kbps   3400Kbps
309us      170us        250us

Linux i2c read                                   
500Kbps  1000Kbps   3400Kbps
818us      760us        577us

Windows i2c read                                           
500Kbps  1000Kbps  3400Kbps
712us      660us       652us

So this shouldn't cause an issue of data within 10ms of data available.

You are also in contact with our support team via email. Please work with the support person and post any resolution here to help other community users.

Best Regards,
FTDI Community

Hello,

In Linux, 'FT4222 A' is the interface 0 description of device. Not the chip code of the device.
See code output below:

cc get-version.c -lft4222 -WI,-path,/usr/local/lib
sudo./a.out

Device 0: 'FT4222 A'
  Chip version: 42220400, LibFT4222 version: 01040409
I have requested support from our R&D engineers to see if there are any known issues with LibFT4222 which could cause issues like you are seeing. Please expect significant delays in the process.

Best Regards,
FTDI Community

Hello,

The description in the chip will be shown when the device is initially connected but in device manager Windows will replace the name with those taken from the inf files of the driver (e.g. USB Serial Port). This will happen for other USB devices too including our other USB-serial chips.

To change the string, you would need to edit the inf files but the latest versions of Windows have these digitally signed and so if you edit these you would not be able to install the driver in normal user mode on Windows. If your device was to be distributed to customers you would normally get a custom PID and program the device with this and have a driver edited to match your PID along with the new strings. You would then get reseller rights from Microsoft to re-sign your driver. Microsoft require you to purchase an EV certificate and so this would involve costs.

An alternative is to keep the VID/PID and the inf file as default, but to open the device using our D2xx driver as you can open by description. This means your application can find the device with no effort by the user. As a trade-off you would not get your device name in the device manager but on the other hand it saves cost and time. But if your main objective is to make the device easy to find and open with minimal hassle to users then this might be a good solution.

If you already have an application on Windows that uses VCP, you can even open the device by description in D2xx, check the COM port number via FT_GetCOMPortNumber and then close it and pass this to your VCP program.

Best Regards, FTDI Community

Hello,

The libMPSSE uses separate FT_Write commands to send each part of the SPI transaction and so there will be a delay between the data and the CS operations as each FT_Write will be a new request to the host controller and will be at least on the next USB uframe (could be longer depending how the host schedules it). This is to make the library more generic as SPI peripherals have many different requirements.

As you mentioned, you can use D2xx and you can send the chip select GPIO command and the clocking command and data and the CS de-assert GPIO command all in one buffer with one FT_Write. If you add all these into one data array and pass to FT_Write, there will be much less delay between them (almost no delay between CS and data if you only clock in/out a few bytes).

When you have a known peripheral which needs a certain sequence, optimising the code like this will make a big improvement.

We also have the source code of libMPSSE and you can make the same change there.

Best Regards, FTDI Community

Hello,

I have no knowledge of the Al Thinker ESP32-CAM or the ESP32 Wrover Module, do these include FTDI ICs?

Can you take some screenshots of the devices in the hardware monitor similar to the attached screenshot?

Best Regards,
FTDI Community

Hello,

Which revision of silicon are you using?

Erratum 0005 only applies to RevA silicon so if you are using that, please use the latest revision of silicon (Rev B).

See the following PCNs for more information:

PCN_FT_023
PCN_FT_025

Best Regards,
FTDI Community

Hello,

The application code on the PC would enter MPSSE mode then I2C can be configured.

External pullups are required.

The pins required are clear in the documentation:

ADBUS0 –SK/CLK
ADBUS1 –DO
ADBUS2 –DI
ADBUS3 –CS

Note that from AN_135, DO must be connected to DI externally as well.

Best Regards,
FTDI Community

Hello,

Please see the following post for a resigned version of the driver:
http://www.ftdicommunity.com/index.php?topic=505.0

Best Regards,
FTDI Community