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.

Topics - a4711

Pages: [1]

Discussion - Drivers / When will libft4222 be available for 64Bit ARM (aarch64)?

« on: March 27, 2024, 08:58:33 PM »

It is becoming more and more common to install a 64 Bit OS on a Raspberry. Libft4222 is available for ARMv8 32 Bit architecture, but not for 64 Bit (aarch64). When will you publish it or when will you publish the source code of LibFT4222 so that we can compile it on any architecture?

Thanks.

Discussion - Software / I2C data is corrupt when FT4222_I2CMaster_GetStatus is being called

« on: September 27, 2022, 06:34:18 PM »

I am observing an issue when calling FT4222_I2CMaster_GetStatus() after FT4222_I2CMaster_Write().

I am doing this:

Code: [Select]

FT4222_STATUS stat = FT4222_I2CMaster_Write(data_handle, slaveAddress_, data, size, &bytesWritten);
if (stat != FT4222_OK)
    throw std::runtime_error("Error writing data over FT4222");
uint8_t flags = 0;
do {
    for (uint32_t retries = 3; retries > 0; --retries) {
        stat = FT4222_I2CMaster_GetStatus(data_handle, &flags);
        if (stat == FT4222_OK)
            break;
        // Add an arbitrary wait time
        Sleep(100);
    }
    if (stat != FT4222_OK)
        throw std::runtime_error("Error reading status from FT4222");
    if (I2CM_DATA_NACK(flags) || I2CM_ADDRESS_NACK(flags))
        throw std::runtime_error("The peripheral did not acknowledge the message as expected");
} while (!I2CM_IDLE(flags));

I read the status after the write operation because FT4222_I2CMaster_Write() returns before the FT4222 has written all data. I need to verify that the transaction completed.

After about 90 minutes of heavy traffic I am sometimes observing that the SCL line is stuck low and flags reports 0x40 (bus busy) forever. I can confirm that the peripheral is not the problem. The SCL line remains low even when I disconnect the peripheral in that situation. It seems that the FT422 is the problem. In that case, the last message being sent is corrupted: The address is wrong and hence the peripheral device does not acknowledge the message.

Now I found this information in the errata sheet https://ftdichip.com/wp-content/uploads/2022/03/TN_161_FT4222H-Errata-Technical-Note.pdf:

Quote

Issue:
An error would happen when i2c master is writing data and FT4222_I2CMaster_GetStatus is being called
at the same time.

Workaround:
Call FT4222_I2CMaster_GetStatus after the end of i2c transmission.

The wording in the errata sheet is confusing. In above code snippet I call FT4222_I2CMaster_GetStatus() after FT4222_I2CMaster_Write(). But I also know that FT4222_I2CMaster_Write() may return while the transmission on the bus is ongoing which is not explicitly described in the application note.
Could you therefore please answer the following questions:

Is above code affected by the problem described in the errata?
If yes, how do I determine the end of the i2c transmission so that I can immediately verify success/fail of the transaction? Feel free to take and change my code from above.

Thank you in advance.

Discussion - Software / How to properly use FT4222_ChipReset()?

« on: September 20, 2022, 07:19:13 PM »

After about 60-90 minutes heavy I2C traffic I run into the situation that the FT4222 holds the SCL line (yes the clock line, not SDA) low and FT4222_I2CMaster_GetStatus() keeps reporting 0x4e as status flags (error condition, bus busy, slave address not acknowledged, data not acknowledged). Further read/write transactions always fail. It's indeed the FT4222 that keeps pulling the SCL line low, because the SCL line remains low even when disconnecting the slave but keeping the pull-ups connected.

Though closing and reopening the FT_Handle does make it work again, the GPIO interrupt timing is not as expected. Only disconnecting/reconnecting the USB cable resets the original behavior.

As a workaround I would like to perform FT4222_ChipReset() right after opening the driver handle, but the function is not working as expected and it's also unclear what the function exactly does. I call FT4222_ChipReset() after FT_open() as shown in the application note. Calling FT4222_I2CMaster_Init() right after that returns FT4222_DEVICE_NOT_SUPPORTED.

I would like to have an advice how to properly use FT4222_ChipReset(), especially what to do after the function call. Is some delay needed? Do I need to close and re-open the driver instance? The example in the application note is not sufficient and indicates that I can just call this function after FT_Open() and before other things.

Thanks.

Discussion - Drivers / Relinkable object files for libft4222

« on: November 23, 2021, 10:15:08 PM »

Since libft4222 links to ftd2xx which links statically to libusb (L-GPL), I would like to link libft4222 to different version of libusb. I am kindly requesting access to relinkable object files for libft4222 similar to how you distribute ftd2xx.

Thanks.

Discussion - Drivers / FT4222: Very high CPU load and gaps between bytes

« on: November 06, 2021, 06:41:40 AM »

We are using a FT4222 with libFT4222 1.4.4.44 to communicate to an I2C peripheral at 400 KHz. Our communication involves a mix of writes and reads, but mainly we are reading out chunks of 128-256 bytes. We are facing two problems:

The CPU load caused by libft4222 is extremely high. On a Raspberry Pi Zero this is becoming a bottleneck.
There a gaps between bytes on all platforms.

Here you can see the gaps:

As you can see, there is no gap between address byte and the first data byte, but every subsequent byte. On a modern x86 processor and Windows the gaps are at least 8µs long, on a Raspberry PI3 and Linux they are 17µs large. One byte takes about 23µs which means we are wasting 40% of our bandwidth. On a FT232H we don't see these kind of gaps and the CPU load is much better.

We are using the FT4222_I2CMaster_Read() function as shown in the example, nothing else.

How can we avoid having such gaps in the transfer?
How can we achieve a lower CPU load?