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.
FTDI & Win/D2xx driver questions
Started by ●July 25, 2006
Reply by ●July 29, 20062006-07-29
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. > > >
Reply by ●July 30, 20062006-07-30
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.
Reply by ●July 31, 20062006-07-31
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.
