Hello,

we have now built a 32-bit version of the library for you. if you could email support1@ftdichip.com asking for the library we can send it over to you.

Best Regards

FTDI Community

Hello,

FTDI has a couple of USB hosts on offer, the Vinculum / Vinculum-II

Please note Vinculum / Vinculum-II are very mature products.The Vinculum / Vinculum-II only have a USB full speed controller and was released a long time ago. Please note that the 64-pin variant of VNC2 was recently made EOL.See VNC2-64 EOL.I’m not sure when the other package variants will be made EOL.You can check our EOL policies here: https://ftdichip.com/document/quality-documents/

However, our sister company Bridgtek have FT90x which is a newer MCU with USB Host at High Speed USB. You can learn more about FT90x on their website https://brtchip.com/.

Best Regards

FTDI Community

Hello,

Please post any new or replies on the BRT Community as Bridgetek support EVE products:

http://www.brtcommunity.com/

Best Regards,
FTDI Community

Hi,

This is likely an issue with your custom firmware, you could try using one of our precompiled firmware like V2DAP, to see if you are seeing the same degradation. You could also use VNC2 tools to debug and analyse. There are some code analysis tools built in. 

you could also try applying the SP3 patch to the VNC2 toolchain, and then rebuild. If you email into support1@ftdichip.com we can give you the details on how to access the patch.

Best Regards

FTDI Community

Hello,

FTDI FIFO Basics has a fully tested example that is compatible with all FTDI devices using FIFO mode. You should try to get this example running first. 

The following documents should help you too:

AN_130 FT2232H Used in an FT245 Style Synchronous FIFO Mode
AN_165 Establishing Synchronous 245 FIFO Communications using a Morph-IC-II
Optimizing D2xx Data Throughput
AN232B-04 Data Throughput, Latency and Handshaking



Best regards,
FTDI Community

Hi,

Try setting the latency timer to 1ms, the default is 16ms.

The 245 FIFO interface should only be written to when the TXE# pin is logic 0.
 
The TXE# pin will go to logic 1 and back to logic 0 for every byte latched in.
 
If the application on the PC never reads any data the buffer on the PC (64kbytes) and the buffer on the chip will become full.
 
When these buffers are full the TXE# line should remain at logic 1 until the application on the PC does a read to free up some space.
 
Some users report TXE# goes back to logic 0 after a brief period (actually matches latency timer).
 
This can result in data loss due to overrun.
 
To prevent this from happening the application on the PC should have set flow control for RTS_CTS flow control.
 
Although the hardware does not have RTS/CTS pins the driver does not know this, but it is now forced to monitor certain status bits, which allows the TXE# pin to be kept at logic 1 until space is made available.
 
Best Regards

FTDI Community

Hello,

Please refer to our software examples here:

https://ftdichip.com/software-examples/ft600-601-software-examples/

There are Data Loopback and Data Streamer examples available in C# and C++.

Best Regards,
FTDI Community

Hi,

i tested this for you and i am able to receive the full string at a Baud rate of 9600. See the attached capture. This is what my write looks like:

 // Write data
    ftStatus = FT260_UART_Write(handle, buffer, 10, 10, &dwRealAccessData);
    if (FT260_OK != ftStatus)
    {
        printf("UART Write NG : %d\n", ftStatus);
    }

Best Regards
FTDI Community