Home
Products
Drivers
Firmware
Support
Documents
Reference Designs
Software Examples
Utilities
Knowledgebase
Related Links
FAQs
Android
EVE
MCU
Sales Network
Web Shop
Newsletter
Corporate
Contact Us

 

 

  FAQs
General
Can I make FTDI devices appears as a different USB device class?

Application Software - General
How do I open a COM port on Windows CE?

Hardware - General
How do I prevent buffer overrun in 245 FIFO mode?
How does FTDI handle USB suspend?
How does RTS/CTS flow control work in an FTDI chip?

Drivers - General
How do I set permissions to allow the D2xx driver to be used on Linux?
Why does my edited driver work on VISTA but not on VISTA x64?
Why does the driver fail to load in Windows CE?

  General

Can I make FTDI devices appears as a different USB device class?

FTDI have defined our own device class, so FTDI devices return a 0 for the bDeviceClass (Vendor class).

The class cannot be configured by the designer.

Our devices do not return the correct USB device descriptors to be USB HID class or USB Mass Storage class. It may be possible to write a filter driver that will make our chip appear to be a HID or mass storage class device, but to do this would involve a lot of work.

 

 

  Application Software - General

How do I open a COM port on Windows CE?

If CreateFile("COMx"...) where x is the com port number fails you may need to open the port by the full name.

e.g.

CreateFile("\$device\COMx",......)

 

 

  Hardware- General

How do I prevent buffer overrun in 245 FIFO mode?

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.

 

 

How does FTDI handle USB suspend?

USB suspend is controlled by the USB host telling telling the peripheral device to go to suspend.

The FTDI drivers do not force the FTxxx devices to go to suspend.

If the USB data bus is idle for >3ms the USB host should put the FTxxx into suspend.

To prevent this happening you should ensure there is always data within 3ms. This could be done by sending dummy data.

The alternative sneaky fix is to set the latency timer to 2ms. This forces the 2 status bytes to be returned every 2ms and hence creates enough traffic to keep the device awake.

 

 

How does RTS/CTS flow control work in an FTDI chip?

FTxxx RTS# pin is an output. It should be connected to the CTS# input pin of the device at the other end of the UART link.

If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.

If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.

RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

FTxxx CTS# pin is an input. It should be connected to the RTS# outout pin of the device at the other end of the UART link.

If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.

If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.

Word to the wise. Not only do RS232 level shifting devices (e.g. MAX232) level shift, but they also invert the signal.

 

 

  Drivers - General

How do I set permissions to allow the D2xx driver to be used on Linux?

FTxxx RTS# pin is an output. It should be connected to the CTS# input pin of the device at the other end of the UART link.

If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.

If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.

RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

FTxxx CTS# pin is an input. It should be connected to the RTS# outout pin of the device at the other end of the UART link.

If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.

If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.

Word to the wise. Not only do RS232 level shifting devices (e.g. MAX232) level shift, but they also invert the signal.

 

 

Why does my edited driver work on VISTA but not on VISTA x64?

VISTA x64 requires that a driver be signed by Microsoft before it can be installed.

The default driver on our website will install on VISTA x64.

If a customer edits the driver and wants to use it on VISTA x64 then the customer must re-certify the driver.

This limitation does not apply to 32 bit VISTA.

 

 

Why does the driver fail to load in Windows CE?

Sometines on a WinCE platofrm a user will have the correct device VID/PID in the inf file and the driver will still fail to load.

These registry keys (only one per system but could be in either location) seem to control how much memory is allocated on a CE 4.2 system using the Microsoft OHCI host driver for holding device descriptors and buffers for the devices. If the memory allocated is too low for the number of devices they want to connect, the ones enumerated later will not load.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI]

"PhysicalPageSize" = dword:00100000 : use this setting to get 128 kb of bufferspace

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PCI\Template\OHCI]

"PhysicalPageSize"=dword:00100000 ; use this setting to get 128 kb of bufferspace

 
 
 



 

© Future Technology Devices International Ltd. 2014