1
Discussion - Software / FT4222H - Clock rate issues and pauses. Again?
« on: October 12, 2021, 07:17:04 AM »
Hello
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.
Setup:
- 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.
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.
Setup:
- 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.