Hello,

Which version of the .net library are you using? The latest can be found here:

https://ftdichip.com/software-examples/code-examples/csharp-examples/

Can you please confirm why you believe the function is not working?

What is the return code after calling the function?

Please note that other function GetBitMode does not actually get the bit mode.
It actually returns the pin state of the I/O pins (used in bit bang mode).
This can be deceiving with the function name.

Please refer to AN_373 Bit-Bang Modes for the FT-X Series which should help you.

Best Regards,
FTDI Community

Hello,

We recommend to enable the RTS_CTS flow control when using MPSSE, you can do this when configuring the device after opening the port and before entering MPSSE mode.

As you mentioned, there are no RTS or CTS lines on the device in this mode and so using RTS/CTS mode in MPSSE does not require any special connections or signals.

But enabling RTS/CTS mode also enables the flow control features in the driver itself, and so the driver wont try to read data from the chip if it does not have room for the data. Without flow control enabled, this data would otherwise have been lost. You may see the MPSSE wait until space is available if the driver buffer fills and the driver stops taking data over USB and the chip buffer then fills.

Best Regards, FTDI Community

Hello,

Yes that is correct the ucMask variable addresses the ADBUS0 -> ADBUS7 pins on the IC.

Please note the FT_SetBitmode(ftHandle, 0x0, 0x0) command resets the MPSSE, so you would issue a second command to enable MPSSE with 0x0 as the mask value:
ftStatus |= FT_SetBitMode(ftHandle, 0x0, 0x00);
//Reset controller
ftStatus |= FT_SetBitMode(ftHandle, 0x0, 0x02);
//Enable MPSSE mode with all pins as input
Please have a look at the following application note:
MPSSE Basics

And please also be aware of the initial pin states of the device:
FTDI Device Input Output pin States

Best Regards,
FTDI Community

Hello,

This is not a known issue with our product with our Linux drivers and the IC and driver is widely used.

There is no difference in the behaviour of the 4 ports (COM1 to COM4 ) regarding USB communications.

The nature of USB communication has to be taken into account.
The communication with USB devices depends on multiple factors such as other USB devices on the bus, USB Host scheduling, USB latency, OS processing, etc.

You attached your setup. Is this all inclusive on custom hardware or are the elements separate?

Is your COM2 operating much differently from the other COM Ports? For example, is there more traffic?
What is each of the FT4232H ports connected to externally and what is the expected throughput of each?
Are you using flow control on all the FT4232H ports?

Could there be issues with the Linux board running out of CPU resources to access more than one device concurrently?

You could perform tests with our known good hardware and maybe connect that to a different Linux system to see what the results are like:

USB-COM485-PLUS4
USB-COM422-PLUS4
USB-COM232-PLUS4
FT4232H-56 Mini-Module
FT4232H Mini-Module
FT-MOD-4232HUB

The FT-MOD-4232HUB might be useful as the ST60 2230-PU Wifi+ Bluetooth device can be connected to one of the ports.

Can you also test with our D2XX Drivers (rather than VCP drivers) to see if the results are the same? See the Linux Driver Installation Guide and D2XX Programmer’s Guide for more information.

Maybe there are other FTDI Community users who can help you further.

Best Regards,
FTDI Community

Hello,

I have be liaising with the driver team recently and they are making good progress. We are currently establishing which features supported in our driver but not in the Apple driver are most pertinent for a beta release. For example, baud rate aliasing or latency timer settings.

If you are using any of these feature please let me know.

Best Regards,
FTDI community.

Hello,

Have you took a look at TN_167 FTDI FIFO Basics?

This also includes software examples.

You must monitor the TXE# and RXF# flags.

The TXE# and RXF# outputs are the buffer status pins (flags).
For both Asynchronous and Synchronous FIFO modes, the status of the internal transmit and receive buffers must be monitored by the external FPGA or microcontroller to avoid buffer over run and data loss.
The TX buffer is used by data sent from the FIFO pins back to the host (write operation)
The RX buffer is used by data sent from the host to the FIFO output pins (read operation)
When the TXE# flag is low, this indicates there is enough internal transmit buffer space available for writing data back to the host. The USB host application code (VCP or D2XX for Async FIFO, D2XX for Sync FIFO) must constantly read incoming data from the device to keep the buffer from filling up.
When the RXF# flag is low, this indicates there is still unread data in the internal receive buffer remaining to be read by the downstream FPGA or micro. Instead of interpreting this flag as “receive buffer full”, the RXF# flag can best be thought of as “receive buffer not empty yet”. When the RXF# flag stays high, the last byte of data in the buffer remains on the data bus and does not change.

Here is some other useful information:

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.

Maybe there are other FTDI Community users who can help you further.

Best Regards,
FTDI Community

Hello,

The FT2232H ports will default to Async serial mode (UART) so you can check Table 3.1 FT2232H Pin Configurations for 64-pin QFN and LQFP package in the FT2232H Datasheet for the default pin functions.

Pins marked ** default to tri-stated inputs with an internal 75KΩ (approx.) pull up resistor to VCCIO.
This is the case for ACBUS1 that you mentioned.

Best Regards,
FTDI Community

Hello,

I would suggest the simplest solution is to connect the UART channels of device 0 and device 1 together if you just require a simple UART bridge.

Assuming however, that you also require a USB connection to these devices, utilising the FT4232H you would be required to write a software application that echos data back and forth between the desired COM ports/interfaces on the FT4232H. You could achieve this using standard COM port programming techniques, or via our D2XX DLL.

Best Regards,
FTDI Community