Hello,

If the event character is enabled and it is detected in the data stream, then the contents of the devices buffer is sent immediately. The event character is not stripped out of the data stream by the device or by the drivers, it is up to the application to remove it. Event characters may be turned on and off depending on whether large amounts of random data or small command sequences are to be sent. The event character will not work if it is the first character in the buffer. It needs to be the second or higher. The reason for this being applications that use the Internet for example, will program the event character as '$7E'. All the data is then sent and received in packets that have '$7E' at the start and at the end of the packet. In order to maximise throughput and to avoid a packet with only the starting '$7E' in it, the event character does not trigger on the first position.

You may also want to take a look at the latency timer.

The latency timer is a form of time-out mechanism for the read buffer of FTDI devices. When a FT_Read instruction is sent to the device, data will not be sent back to the host PC until the requested number of bytes has been read. If the requested number of bytes never comes, the device would not send data back.

The latency timer counts from the last time data was sent back to the PC. If the latency timer expires, the device will send what data it has available to the PC regardless of how many bytes it is waiting on. The latency timer will then reset and begin counting again.

The default value for the latency timer is 16ms. This value may be customised by adding or changing the following entries in the FTDIPORT.INF file of the driver before installation.

[FtdiPort232.NT.HW.AddReg] 
 
HKR,,"LatencyTimer",0x00010001,50 
 
This example will set the default latency timer value to 50ms. The valid range for the latency timer is 1ms - 255ms, although 1ms is not recommended as this is the same as the USB frame length.

The latency timer value is held in the registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\{Device VID, PID and serial number}\0000\Device Parameters\LatencyTimer 
 
Please see AN232B-04 Data Throughput, Latency and Handshaking for additional information on the latency timer.

Best Regards,
FTDI Community

Hello,

Thanks for your feedback, please let us know if you have any more questions.

Best Regards,

FTDI Community

Hello,

Thanks for your question.

There are known issues with Windows 7 and USB 3.0 ports, explained in the following document:
http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_152_USB_3.0_Compatibility_Issues_Explained.pdf

It is possible that this could be causing the devices to show up with the same COM port number, are you using USB 3.0 ports?

Another possibility is if the devices have the same serial number, you can check and change the serial number using our FT_Prog utility:
http://www.ftdichip.com/Support/Utilities.htm#FT_PROG

Best Regards,

FTDI Community

Hello Randy,

The sync procedure allows you to check that the device is definitely in MPSSE mode and is ready to accept the next command. If for example the device was still in UART or 245 FIFO mode, you would not get this response back as these modes would assume your command is just normal data.

After opening the device and doing SetBitMode, you can flush out the buffer using a routine similar to the one below. This might help to avoid those extra bytes at the start.

        private byte FlushBuffer()
        {
            ftStatus = myFtdiDevice.GetRxBytesAvailable(ref BytesAvailable); // Get the number of bytes in the receive buffer
            if (ftStatus != FTDI.FT_STATUS.FT_OK)
                return 1;
           
            if(BytesAvailable > 0)
            {
                ftStatus = myFtdiDevice.Read(InputBuffer, BytesAvailable, ref NumBytesRead);  //Read out the data from  receive buffer
                if (ftStatus != FTDI.FT_STATUS.FT_OK)
                    return 1;       // error
                else
                    return 0;       // all bytes successfully read
            }
            else
            {
                return 0;           // there were no bytes to read
            }
        }
You can find some C# example code in AN_411 which is for an I2C Master but could be edited to create an SPI Master instead by changing the series of GPIO and clocking commands within the I2C functions. This would allow you to implement the chip select and data operations.
http://www.ftdichip.com/Support/Documents/AppNotes/AN_411_FTx232H%20MPSSE%20I2C%20Master%20Example%20in%20Csharp.pdf
You can find the description of the commands used by this code in AN_108 below:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf

Thanks,
FTDI Community

Hello,

Thanks for your question.

Can you describe the device you are implementing this code for? is it a cable? what is it trying to communicate with?

Are you implementing the Flow Control lines, I believe the loopback code example requires these.


Best Regards,

FTDI Community

Hello,

AT-Bus with Host Emulation Mode is the only example code we have available for Host Bus Mode.

You can refer to AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes to create your own software in any language.

You may find other examples useful:
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE.htm
http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples.htm

Best Regards,
FTDI Community

Hello,

Unfortunately FTDI do not have any recommendations for a USB HUB.

TUSB4041I does look like a good choice.

Maybe someone else in this community can provide recommendations?

Best Regards,
FTDI Community