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

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: November 15, 2021, 10:27:29 PM 
Started by kalle - Last Post by William J. Croft
Hello,

That would be the last version of macOS to support .kext drivers, this would be 10.15, but there is an extra notarization step for .kext drivers required by Apple in 10.15, that is not noted in that document. As such it would be safe to assume these instructions work up for drivers up till macOS 10.14.

Best Regards,
FTDI Community

Hi "FTDI Community" / moderator,

I've been in contact with @scottmiller regarding his difficulty adjusting the macOS 11 FTDI 'latency' setting. (macOS 11 is required for Apple hardware using the new M1 CPU.) For our Windows customers, this is extremely easy: they just bring up the Windows driver control panel, and type in the new Latency value. In this case '1' ms is the Latency value we need for optimum packet latency with the OpenBCI Cyton product.

What we are requesting: is a similarly easy way to do this on macOS 11. That should not require modifying Info.plist files, or signing a driver. It should be an external file that you look for, upon driver loading time. This would have fields similar to a .plist, for adjusting values like are possible on Windows. But it would not have to be a .plist, could even be something simple like one line per adjustment: "variablename value".

Can you give us a timeline for when FTDI will release this macOS 11 compatible driver with adjustable settings? The lack of this is causing great difficulty with our Mac customers.

Thanks,

William Croft
OpenBCI Forum admin

 22 
 on: November 15, 2021, 05:13:22 PM 
Started by lelebass2001 - Last Post by lelebass2001
I just saw that a 2.12.36.4U driver appeared on D2XX drivers download page https://ftdichip.com/drivers/d2xx-drivers/.
I wonder what does Universal stands for on a Windows OS? Which are the differences between 2.12.36.4U and 2.12.36.4?

Daniele 

 23 
 on: November 15, 2021, 09:27:45 AM 
Started by a4711 - Last Post by FTDI Community
Hi,

we were able to recreate the high CPU load on the raspberry pi. you can add the following setting at the beginning of your code which will resolve this issue: ftStatus = FT_SetTimeouts(ftHandle, 5000,0);

concerning the gaps between bytes, sorry this is a firmaware limitation so there is no way to resolve it.

Best Regards

FTDI Community

 24 
 on: November 09, 2021, 04:09:50 PM 
Started by a4711 - Last Post by a4711
Quote
In the mean time, have you tried running the example as is? Just to see if the hardware is functioning properly?

My original code is much more complex. Therefore I thought I would strip it down and fit it into the "official" example.
 
Just copy-paste this function into the example file i2cm.c and run it on Linux and include <unistd.h>. On Windows you will have to replace usleep by Sleep. It works on my end. If you could run it on a Raspberry Pi you could see how high the CPU load is. But the gaps are visible on any platform I have checked.

 25 
 on: November 09, 2021, 02:26:23 PM 
Started by a4711 - Last Post by FTDI Community
Hello,

As we are working from home at the moment, I do not have the required hardware to see if I can recreate your issue. However, I have sent your code to my colleague who does have access to the required hardware, so they can test it. I'll let you know what they find.

In the mean time, have you tried running the example as is? Just to see if the hardware is functioning properly?

Best Regards

FTDI Community

 26 
 on: November 08, 2021, 10:45:50 PM 
Started by a4711 - Last Post by a4711
Thank You for your reply.

Quote
Set the latency timer to a value appropriate for the application. Note that a low latency timer
value may result in many short incoming USB packets rather than a single large packet, thus
diminishing performance.

The latency timer is set to 16 ms (the default). Changing the value has only a very small effect on the gaps and and absolutely no effect on the CPU load on Linux.

Quote
you should also refer to section 5.3 of the FT4222 datasheet: https://ftdichip.com/wp-content/uploads/2020/07/DS_FT4222H.pdf
This section outlines the I2C bus interface.

I do not understand how this relates to the problem I am reporting here.

Quote
also which example are you referring to? the one shown in the LibFT4222 user guide or the one included in the library download?

From the library download. To illustrate my problem I modified the contained I2C example like this:

Code: [Select]
static int exercise4222(DWORD locationId)
{
    int                  success = 0;
    FT_STATUS            ftStatus;
    FT_HANDLE            ftHandle = (FT_HANDLE)NULL;
    FT4222_STATUS        ft4222Status;
    FT4222_Version       ft4222Version;
    const uint16         slaveAddr = 0x58;
    uint16               bytesToRead ;
    uint16               bytesRead = 0;
    uint16               bytesToWrite;
    uint16               bytesWritten = 0;
    char                *writeBuffer;
    uint8_t              pageBuffer[BYTES_PER_PAGE + 1];
    int                  page;


    ftStatus = FT_OpenEx((PVOID)(uintptr_t)locationId,
                         FT_OPEN_BY_LOCATION,
                         &ftHandle);
    if (ftStatus != FT_OK)
    {
        printf("FT_OpenEx failed (error %d)\n",
               (int)ftStatus);
        goto exit;
    }

    ft4222Status = FT4222_GetVersion(ftHandle,
                                     &ft4222Version);
    if (FT4222_OK != ft4222Status)
    {
        printf("FT4222_GetVersion failed (error %d)\n",
               (int)ft4222Status);
        goto exit;
    }

    printf("Chip version: %08X, LibFT4222 version: %08X\n",
           (unsigned int)ft4222Version.chipVersion,
           (unsigned int)ft4222Version.dllVersion);

    // Configure the FT4222 as an I2C Master
    ft4222Status = FT4222_I2CMaster_Init(ftHandle, 400);
    if (FT4222_OK != ft4222Status)
    {
        printf("FT4222_I2CMaster_Init failed (error %d)!\n",
               ft4222Status);
        goto exit;
    }

    // Reset the I2CM registers to a known state.
    ft4222Status = FT4222_I2CMaster_Reset(ftHandle);
    if (FT4222_OK != ft4222Status)
    {
        printf("FT4222_I2CMaster_Reset failed (error %d)!\n",
               ft4222Status);
        goto exit;
    }

    for (;;) {

        // Sequential read from slave EEPROM's current word address.
        uint8_t content[512];
        bytesToRead = sizeof(content);
        ft4222Status = FT4222_I2CMaster_Read(ftHandle,
                                             slaveAddr,
                                             content,
                                             bytesToRead,
                                             &bytesRead);
        if (FT4222_OK != ft4222Status)
        {
            printf("FT4222_I2CMaster_Read failed (error %d)\n",
                   (int)ft4222Status);
            goto exit;
        }

        if (bytesRead != bytesToRead)
        {
            printf("FT4222_I2CMaster_Read read %u of %u bytes.\n",
                   bytesRead,
                   bytesToRead);
            goto exit;
        }

        usleep(100000);
    }

    success = 1;

exit:
    if (ftHandle != (FT_HANDLE)NULL)
    {
        (void)FT4222_UnInitialize(ftHandle);
        (void)FT_Close(ftHandle);
    }

    return success;
}

It reads out 512 byte chunks in a loop with 100ms sleep in between transfers.

  • There are still gaps between 8µs and 17µs between each byte
  • The CPU load on a RPi3b is >50% which is unexpectedly high. On a RPi0 it is even higher due to the slower CPU.

I found the following note in the errata (3.1.2):
Quote
The FT4222H doesn’t support the latency timer feature and causes the USB scheduler to be busy and
uses too much CPU resource.

This looks exactly like what I am seeing, but I have chip revision D.

Can you reproduce this issue? How to solve it?

 27 
 on: November 08, 2021, 03:44:23 PM 
Started by a4711 - Last Post by FTDI Community
Hello,

We have a technical note about USB data transfer efficiency that can help you: https://ftdichip.com/wp-content/uploads/2020/08/TN_103_FTDI_USB_Data_Transfer_EfficiencyFT_000097.pdf.

The main points are:

• Send as much data to the IC from the host application as possible in a single write. This will
maximize the size of the data packets being sent to the device and hence minimize the number of
packets required and time to transfer an amount of data.

• Set the latency timer to a value appropriate for the application. Note that a low latency timer
value may result in many short incoming USB packets rather than a single large packet, thus
diminishing performance.

you should also refer to section 5.3 of the FT4222 datasheet: https://ftdichip.com/wp-content/uploads/2020/07/DS_FT4222H.pdf

This section outlines the I2C bus interface.

also which example are you referring to? the one shown in the LibFT4222 user guide or the one included in the library download?

Best Regards

FTDI Community

 28 
 on: November 08, 2021, 07:22:25 AM 
Started by HI_type - Last Post by HI_type
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)?

 29 
 on: November 06, 2021, 06:41:40 AM 
Started by a4711 - Last Post by a4711
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?

 30 
 on: November 05, 2021, 08:04:05 PM 
Started by KTrenholm - Last Post by KTrenholm
Hello,

Ok that's fine then.

using the BOMS and FAT files to detect connection/removal won't work. As you say the UART2DSC doesn't do anything to detect removal or connection of USB devices. This is because it is a minimum project that is used to demonstrate how to write to a file on a flash disk. the procedure is as follows:

the USB host call to VOS_IOCTL_USBHOST_GET_CONNECT_STATE to see if there is a device connected and enumerated.
Search through the devices for the correct device.
Then open and attach the BOMS driver to the handle to the correct device.
After that attach the FAT driver to the BOMS driver.

Periodically poll the VOS_IOCTL_USBHOST_GET_CONNECT_STATE for disconnection, this checks that a device is connected to the root hub.
Also check the return value of any FAT or BOMS driver calls for FAT_NOT_FOUND or FAT_ERROR/FAT_FATAL_ERROR, MSI_NOT_FOUND or other errors. If there is an error again check VOS_IOCTL_USBHOST_GET_CONNECT_STATE to confirm or if there is a bub involved

On disconnection, detach FAT then BOMS drivers from the device.

I would recommend you use one of our other projects such as V2DAP, which has increased functionality and can be downloaded here: https://ftdichip.com/firmware/precompiled/.

Best Regards

FTDI Community

Thanks for this!  I've been sidetracked to another project for the moment but will be sure to give this a try when I get the chance ;D.

Pages: 1 2 [3] 4 5 ... 10