Hello,

Apple are moving from what are called Kernel Extentions (.kexts) to what are called Driver Extensions (.dexts) for the implementation of drivers starting in macOS Catalina (10.15). Currently .kexts are still supported in macOS Catalina, however after the beta release they issued an update which stopped our driver from loading. This update required our driver (FTDIUSBSerialDriver.kext) to be re-signed and notarized, we completed this process with an updated Apple Developer ID. Unfortunately when Apple issued our new Developer ID to re-sign and notarize the driver package they did so without the .kext support option enabled (as .kexts are being deprecated it is no longer automatically included). This is why there is a code signature issue with our driver, currently we are waiting on Apple issuing us with the correct Developer ID to be able to sign .kexts for macOS Catalina.

As such our current VCP driver available on the website has a signature issue and wont load. However if the device you are using implements a default FTDI VID/PID combination it should be picked up by the inbuilt AppleUSBFTDI.dext driver and present accordingly in the ‘/dev’ folder on your system in the following form:
/dev/cu.usbserial-xxxxxxxx
/dev/tty.usbserial-xxxxxxxx

Best Regards,
FTDI Community 

Hello,

Welcome to the FTDI Community,

Those changes seem fine.

      // UART_TXD to pin 29 as Output.
      vos_iomux_define_output(29, IOMUX_OUT_UART_TXD);
      // UART_RXD to pin 30 as Input.
      vos_iomux_define_input(30, IOMUX_IN_UART_RXD);
      // UART_RTS_N to pin 31 as Output.
      vos_iomux_define_output(31, IOMUX_OUT_UART_RTS_N);
      // UART_CTS_N to pin 32 as Input.
      vos_iomux_define_input(32, IOMUX_IN_UART_CTS_N);

If you have access to the default UART pins, it would be worth making sure your serial device can communicate with those using default firmware first of all. Note that RTS and CTS must be used as the device is set by default for hardware flow control and so no data will flow if not asserted (we always recommend this to avoid data loss).

Best Regards, FTDI Community

Hello Allen,

Our drivers may have a dependency on Windows Timer Resolution.
Some applications like Chrome for example may change the Windows Timer Resolution which can have an effect on all software that uses it.
We think it’s a bad practise from Microsoft to allow for the Windows Timer Resolution to be changed by applications, but it is out of our control.

The screen saver issue is not something that we have encountered before. Maybe disabling it is an option, or take a look at the other Windows settings?

Please take a look at the standard I2C examples provided with LibFT4222.

Best Regards,
FTDI Community

Hello,

We don't have a 64-bit version included with our Linux built at the moment but we are currently working on a build for 64-bit Linux. We should have a beta version soon and will let you know when it is available.

Best Regards, FTDI Community

Hello,

Is the device configured to be a different interface (I2C master?) before you try and initialise it as a I2C slave?
Do all of the function calls return with an FT_OK return code?


Best Regards,
FTDI Community

Hello,

We are dealing with your request via email.
Please feel free to add any resolution here when complete to help other community users.

Best Regards,
FTDI Community

Hello Jeff,

Power should always be applied to the device when in use.
VCC and VCCIO should be applied at the same time.

When the board is powered off, do not apply any voltages to the IC pins.
There might be some current draw but this is not specified because the device can be in unknown states.

It may be advisable to add a buffer or MOSFET gated with PWREN# to avoid such behaviour.

Best Regards,
FTDI Community

Hello,

Vinculum and Vinculum-II are quite old solutions and it don’t seem to work with a lot of newer devices due to changing designs. Note that is only a Full Speed (12Mbits/second) controller.
These mature products have not had any development for years and have been superseded by FT9xx.

The best option would be to use the FT90x MCU, however note that this only includes 1 x USB Host and 1 x USB Device controller.
This uses a USB 2.0 Hi-Speed (480Mb/s) controller.

You could take a look at the following examples to host HID class devices:

AN_360 FT9xx Example Applications

There are significant benefits of FT90x over VNC2:

-Eclipse based IDE
-Source code for API drivers is provided
-Significant performance improvement
-Actively in development by R&D
-Improved documentation and software examples

We provide FT9xx Development Modules and a free FT9xx Toolchain for custom application development.

Best Regards,
FTDI Community