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

Author Topic: FT4222H - Clock rate issues and pauses. Again?  (Read 82 times)


  • Newbie
  • *
  • Posts: 9
    • View Profile
FT4222H - Clock rate issues and pauses. Again?
« on: October 12, 2021, 07:17:04 AM »


After finding the FT260 not suitable to our purpose due to inherent limitations of HDI (https://www.ftdicommunity.com/index.php?topic=705.0), we jumped on the FT4222H but see similar issues again:

- Requesting a 2 MBit clock, the chip sents the address byte at a meager 40 kBit. [-> "16 Bytes Write 2000 kbps (addr measurement).png"]

- There is still a pause in the range of a byte time and more. [-> "16 Bytes Write 2000 kbps (payload gap measurement).png"]

- At 800kBit, the clock starts out correctly and even has the first 2 bytes abutted, but then shows a sending pattern with gaps. [-> "16 Bytes Write 800 kbps (payload gap measurement)(2).png"]

Can FTDI or someone else propose an approach which does not show the above issues?
We are limited by maximum clock speed but need to reach a minimum data throughput. The gaps, more or less, half effective throughput, the clock timing issue in the first byte on the 2 MBit packet defeats the purpose of using a higher clock rate.

- UMFT4222EV-D board with pull-ups only (no slave connected).
- LibFT4222 on top of the D2XX driver.
- Repeated start send routine.
- We tested setting the FT4222_SetClock (ftHandle, clock) to SYS_CLK_24 and every other option. SYS_CLK_60 worked best (Which i believe was stated as the default).
- OS: Windows 10; Programming language: Delphi.
- The test software is virtually identical to the pseudo-code shown in the FT260 post linked above, simply replaced the calls to the new library.

As we assume the hardware is more than capable of sending an infinite stream of bytes abutted, I post this in the software section of the forum. If someone knows for a fact that this assumption is wrong, let us know.