Forums

FTDI & Win/D2xx driver questions

Started by Johnny July 25, 2006
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.



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

"Johnny" <jo@john.jo> wrote in message
news:MPG.1f2fb8b541b1ee809897c1@news-server.san.rr.com...
> 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. > > >
On Sat, 29 Jul 2006 14:05:09 -0500, "Patrick Johnson" <kirilian@bellsouth.net> wrote:

>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 > >"Johnny" <jo@john.jo> wrote in message >news:MPG.1f2fb8b541b1ee809897c1@news-server.san.rr.com... >> 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?
I think it gives you however many it has and returns a value indicating that it didn;t get all the bytes you requested.
>> 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.
The latter.
>> 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. >> >> >>
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.
Johnny wrote:
> 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...
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.