1. Home
  2. Embedded Programming
  3. FTDI & Win/D2xx driver questions

FTDI & Win/D2xx driver questions

Hi,

I've read several posts from different people in here stating they have used the FTDI parts successfully. I am considering the FT232R and my application needs very low latency (yes, USB and low-latency is an oxymoron). My data throughput is 3-4 bytes/message with minimum 400 us between each message, upto 40 s between a message. Data is semi-random, not always continuous.

With the D2xx driver, with USB block transfer size set to minium of 64- bytes, what happens if an application in the two cases where an application requests more or less than the 64-bytes from the FTDI D2xx driver?

Is the read a blocking read (i.e. will the FTDI driver stall until 64 bytes are available) or will the driver pass the data to the app as and when it processes it? Details on this mechanism would be highly appreciated.

I have written software for Linux/UNIX using non-blocking reads/writes, but the Windows side is very new to me. I would hope the FTDI driver is non-blocking...

Regards. John.

Reply to
Johnny
Loading thread data ...

I am no expert at USB or Windows, but I have used the FT232R successfully with the D2xx drivers. My applications usually deal with 'messages' that are ~10 bytes. The driver always passes the data straight through. My application works such that the software sends a message to a microcontroller (via FTDI USB chip), waits a fixed amount of time, then reads the response from the microcontroller from the FTDI buffer. Again, the messages are short and rarely over 64 bytes.

The FTDI datasheet states that you can set up a callback when a certain number of bytes are received in the receive buffer. I believe you can set this number as low as 1.

Hope this helps... Patrick

Reply to
Patrick Johnson

I think it gives you however many it has and returns a value indicating that it didn;t get all the bytes you requested.

The latter.

There is a setting in the D2X driver to set the latency timer - I think this is the timeout before it sends a non-full buffer to the host. May be worth experimenting with.

Reply to
Mike Harrison

For Linux, you should also look for the ASYNC_LOW_LATENCY option, which also affects writes to normal serial ports. I had to use it to get download throughput on a serial-port debugger for the 68HC11 I wrote. At least at the kernel version I was using, non-blocking by itself is *not* enough to actually get characters sent when they're written. Search for my DB11 to find a code example.

I don't know whether W2K has a similar feature.

Clifford Heath.

Reply to
Clifford Heath

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.