FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

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 15103 times)

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
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.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 891
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #1 on: October 26, 2021, 09:48:50 PM »

Hello,

Could you advise what your key requirements are for the I2C communication. For example, is it most important to have the bytes all close together during one read or is it the interval at which reads occur which is important? Or is it just an overall throughput (even if in bursts) if the peripheral has some buffering?

One thing to note about bulk USB transfers are that they don't have guaranteed latency or guaranteed instantaneous throughput due to the USB scheduling and the other devices on the bus as well as other factors and so there can also be trade-offs depending on which requirement is most important.

Could you advise what calls do you use in your code to send the bytes?
You mentioned that there was no peripheral connected and so note that the communication may also differ as the device will not see an ACK on the bus

Best Regards, FTDI Community
Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #2 on: October 27, 2021, 09:18:26 AM »

Hello FTDI Community

Thank you for the reply.

Our key requirement is throughput, we need to write around 8 Mbyte of Data in the optimal amount of time. In our case, we expect the target to be able to store data at around 1Mbit/s.

The I2C connection itself is capped at around 1.8 MBits/s (Target and physical limitations). With the gaps, the actual throughput is less than half of this, i.e. less then 900 kBit/s. This is below our target, but also far from having a margin. Furthermore, I believe it to be an advantage to use the lowest clock rate reasonable, around 1.2 Mbit/s, as this would improve stability of the communication. Obviously, with the gap situation, this is not feasible either.

Our expectation was that the FT4222H would use its large buffer and very fast USB upstream connection to keep the buffer filled. However, when sending 16 Bytes in a single burst, we did not expect buffering or USB throughput to be an issues in the first place, which is part of our concern.

It was our understanding that the FT4222H will simply ignore a NACK? We do also see the gaps when our slave device acknowledges each byte correctly. In those cases, we believe that the FT4222H is producing the gaps, as it has a stronger driver than our device and the low level is lower. However, to remove uncertainty regarding this, we elected to go for a test without any slave connected.

Here is the information regarding the calls we use:
Using the simple api call we have an initialization part:
1.   ftd2xx.h: FTD2XX_API FT_STATUS WINAPI FT_CreateDeviceInfoList(LPDWORD lpdwNumDevs);
•   To obtain the number of devices connected. Success if returns FT_OK
2.   ftd2xx.h: FTD2XX_API FT_STATUS WINAPI FT_Open(int deviceNumber, FT_HANDLE *pHandle);
•   For deviceNumber 0.. lpdwNumDevs loop around calling FT_Open returns FT_OK
3.   LibFT4222.h: LIBFT4222_API FT4222_STATUS FT4222_I2CMaster_Init(FT_HANDLE ftHandle, uint32 kbps);
•   ftHandle is the handle from the FT_Open. Success if returns FT4222_OK

and an I2C Write command / read response part:
1.   LibFT4222.h: LIBFT4222_API FT4222_STATUS FT4222_I2CMaster_Write(FT_HANDLE ftHandle, uint16 deviceAddress, uint8* buffer, uint16 bufferSize, uint16* sizeTransferred);
•   Writing the Tx Bufffer. Success if returns FT4222_OK and  sizeTransferred== bufferSize
2.   LibFT4222.h: LIBFT4222_API FT4222_STATUS FT4222_I2CMaster_Read(FT_HANDLE ftHandle, uint16 deviceAddress, uint8* buffer, uint16 bufferSize, uint16* sizeTransferred);
•   Reading into the Rx Bufffer. Success if returns FT4222_OK and  sizeTransferred== bufferSize
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 891
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #3 on: November 05, 2021, 01:46:57 PM »

Hi,

Here is an example attached of 64 bytes transferred by a single write (to address 0x22) at 1MHz clock rate

The gap between the 0x02 and 0x03 for example is 4.6uSec

ftStatus = FT4222_I2CMaster_Write(ftHandle, 0x22, master_data, sizeof(master_data), &sizeTransferred);
master_data is a buffer with 64 bytes (0-63 in value)

Best Regards, FTDI Community



Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #4 on: November 08, 2021, 07:22:25 AM »

Thank you FTDI community

I understand thereby that you are not aware of a solution for the issue as you get the same result?

Regarding the "slow start" we came a step further. The I2C standard specifies that "A high-speed transmission starts up in full-speed mode, i.e. at max. 400 kbit." https://www.i2c-bus.org/highspeed/

Is there a way to change the transmission speed of the startup byte from around 40 kHz to 400 kHz (Image attached again)?
« Last Edit: November 11, 2021, 05:15:06 AM by HI_type »
Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #5 on: November 24, 2021, 09:54:43 AM »

Hello

No suggestions regarding the startup byte clock rate in HS+ operation?
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 891
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #6 on: November 26, 2021, 06:22:51 PM »

Hello,

We checked with our dev team on this and it is not possible to completely avoid the small gaps between the bytes.

The start-up byte for the full-speed is fixed at 100Kbps and is enabled when you go above 1M and so if you run at 1M or less you can avoid it. However, you would not be able to change the speed of this byte.

I'm not sure if it will be possible to reduce those short pauses any further than what you had seen at 1MHz unfortunately.

Does your target device need the interface to check the ACK/NAK status which it returns?

Best Regards, FTDI Community
Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #7 on: November 29, 2021, 04:54:06 AM »

Hello FTDI Community

Understood and thank you for the explanation. Our target device does not require us to check every ACK/NAK, but will double check just to be absolutely certain. Assuming that ACK/NAK checks are not needed, do you have another I2C master device that performs better?
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 891
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #8 on: December 03, 2021, 11:40:19 AM »

Hello,

I'm not 100% sure but I was wondering if the MPSSE-based FT232H might be suitable but it would depend if the system needs to check ACK as if so it would definitely have gaps.

Note that any of the devices could have gaps (at the very least where data is split across USB packets and frames) and the timing could also vary depending on USB bus conditions. For high throughput devices, they use bulk USB transfers and these have their latency and assigned bandwidth determined by the host and by the bus conditions (other devices connected) and so I would say that it isn't possible to have a 100% guaranteed gap or latency.

For specifc cases where the gaps are important, having additional processing on the device end may be one consideration(for example an MCU or logic device with an FT232H in async FIFO mode feeding data at up to 8MBytes/sec) and the MCU then outputting the I2C data and even checking the ACK.

If you definitely dont need to check the ACK, we could do a basic check with a UM232H (acting as USB-I2C via MPSSE in place of the UMFT4222H) to see how writing a stream of 100 bytes etc. looks if it would help you determine if it is worth pursuing,

Best Regards, FTDI Community


Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #9 on: December 03, 2021, 12:04:46 PM »

Hello FTDI Community

I did nor get an answer from my colleagues but still believe that we do not need to check for ACK/NACK. I shall push for an answer and return soon.

When sending above 1 MBit, will the FT232H send the start byte at 100 Kbit (we measured 50 kBit on the the FT4222H)? Not sending the start bit at 400 KBit (or ideally more, even if it is outside of spec) is currently the biggest limitation.
Logged

HI_type

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #10 on: February 17, 2022, 08:47:31 AM »

Hello

For those seeking better performance, it turns out that FT4232H (and presumably FT2232H) can deliver the expected performance using the MPSSE. Getting this up and running requires more software, but this seems to be a solution as the bit streams can be defined at will (If i understood correctly, I am on the hardware side of things).

Downsides: These device seem to be only available in larger packages and need more external support components.

Best regards.
Logged

cioma

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: FT4222H - Clock rate issues and pauses. Again?
« Reply #11 on: May 09, 2022, 04:59:30 PM »

Indeed, it's only FT232H, FT2232H, FT4232H (and their variants with USB PD) that have MPSSE which IMHO is much more capable, flexible and controllable than fixed SPI/I2C engines in FT4222H.
Logged