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

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - HI_type

Pages: [1]
1
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« 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.

2
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« 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.

3
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« 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?

4
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« on: November 24, 2021, 09:54:43 AM »
Hello

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

5
Discussion - Software / Re: FT4222H - Clock rate issues and pauses. Again?
« 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)?

6
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

7
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.

8
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 11:59:34 AM »
Thank you for the clarification FTDI Comunity

I think the FT4222H is definelty the way to go. Never heard of quadSPI and interpreted the title as 4 x SPI or 4 x I2C, implying a lot of pins, large package. This is not the case and the package does fit the application. Will look into the FT4222H.

9
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 10:06:06 AM »
Thank you FTDI community

I would be looking at the FT201X as we are constraint with space. Do you see any issues with that device regarding speed?

In our setup, this device will be only one in use when it is accessed. Thank you for the heads up.

10
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 08:10:28 AM »
OK, i talked to our software engineer again and he had news: He used a USB package analyzer to see what the LibFT260.dll is sending and proclaims he would not be able to optimize this.

At the same time, the maximal transfer speed for HDI seems indeed to be 64kbit/s. This appears to be a hard limit. Going beyond this limit would again require a custom driver, defeating the point. Unfortunately, the FT260 is deemed unfit for our use case as we need an actual transfer rate of around 2Mbit/s.

Maybe FTDI would like to point this out explicitly in the datasheet? We have also seen the pause when sending a full set 64bits, effectively making a burst meant to be 2Mbit/s to be closer to 1Mbit/s.

Thank you for the support to everybody involved.

11
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 06:19:57 AM »
Thank you allenhuffman

I will forward this information to our software engineer and see if he is willing to have a look.

Hopes are still to get a confirmation from somebody that this chip actually can run at 3,4Mbits actual throughput. An alternative could be the FT201X https://www.ftdichip.com/old2020/Support/Documents/DataSheets/ICs/DS_FT201X.pdf but it requires drivers, not a show stopper, but the lesser choice.

Thank you again for the input.

12
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 12, 2021, 11:26:18 AM »
Hello FTDI Community

Any updates on the issue? Shall I open a service ticket somewhere?

13
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 04, 2021, 11:37:57 AM »
Hello and thank you for the support :)

The time base in the 400 kBit case was 10us/div, the cursors measure the pause to be approximately 28.4us.

The pause in the 2 Mbit test is shorter: 3.8 us.

14
Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 04, 2021, 07:49:38 AM »
So, nobody has seen the FT260 communicate without those pauses? Is this a chip design issue?

15
Discussion - Software / FT260 - Pauses in I2C comunication.
« on: July 27, 2021, 09:41:43 AM »
Hello

Hope this is the right place to ask.

Problem: Using LibFT260 (form here: https://ftdichip.com/products/ft260q/) we can successfully read from our slave device, but at an effective speed lower than the clock speed would allow. The issue is pauses in between frames:

X -> Byte + ACK
_ -> Clock held low by FT260 (Pause)

XX_X_X_X_X....

See attached images. The slave device is not clock stretching as it has a weak driver and it is clearly visible by the low level of the clock when that happens. The duration of the pause at 2Mbit clock is shorter than at 400kbit.

The pauses occur during read and write.

Questions:
- Is the FT260 capable of communicating without these pauses?
- If so, how, and can it be done with the dll provided in LibFT260?

Our software Engineer has provided c++ pseudo code to illustrate what he is doing:

##############################################################
FT260_HANDLE FFT260Handle;
FT260_STATUS status;
...
uint32 kbps = 400;
int dwBytesToWrite = 7;
uint8 writeBuffer[dwBytesToWrite] = (0x01, 0x81, 0x80, 0x00, 0x00, 0xA0, 0x15);
DWORD dwBytesToRead = 14;
uint8 deviceAddress = 0x60;
uint8 readBuffer[dwBytesToRead];
DWORD dwBytesReturned;
...
    status = FT260_I2CMaster_Init(FFT260Handle, kbps);
    if (status== FT260_OK)
    {
       status= FT260_I2CMaster_Write(FFT260Handle, deviceAddress,
          FT260_I2C_START, writeBuffer, dwBytesToWrite, dwBytesWritten);
       if (status== FT260_OK)
       {
           status= FT260_I2CMaster_Read(FFT260Handle, deviceAddress,
              FT260_I2C_START_AND_STOP, readBuffer, dwBytesToRead, dwBytesReturned);     
       }
...   
    }
##############################################################

Pages: [1]