libftdi Archives

Subject: Re: Question about ftdi_read_data().

From: Teunis van Beelen <teuniz@xxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 21 Jan 2010 08:56:54 +0100
Let me explain my project. I designed an ADC-box and aquisition
open-source software for Linux.
The ADC-box has 5 channels x 10 KHz x 16-bit thus it produces 100 KB/sec.

I tested it with the VCP-driver which is already present in openSuse Linux 11.0.
Unfortunately, the VCP-driver does not allow me to read more than 4000
bytes per call.
So, I have to use a timer and poll the "COMport" every 10 milliSeconds.
So far, this works.

Because I would like to relax the timer-value and decrease the
overhead, I thought
switching to LibFTDI would be a good idea. After some experiments, I discovered
that a user-space "driver" does not suit my needs. I want the driver
to receive and buffer
the data from the ADC-box, even when my program is busy. So the diver
should be a different
process with high priority.

At the moment, the default VCP-driver gives much better results,
except for the overhead caused
by the small buffer used (who invented this?). It should be adjustable...



p.s. LibFTDI 0.17 causes an immediate segfault. 0.16 works ok (using
libUSB 0.1.12).

On Thu, Jan 21, 2010 at 7:12 AM, Michael Plante
<michael.plante@xxxxxxxxx> wrote:
> Sivaram Gowkanapalli wrote:
>>> Check out the "latency timer" functionality.
>>> I am not sure if your device has it.
>>> The datasheet of the FT4232H, says the below:
>>> "Latency Timer. This is really a feature of the driver and is used
>>> to as a timeout to flush short packets of data back to the PC. The
>>> default is 16ms, but it can be altered between 0ms and 256ms. At 0ms
>>> latency you get a packet transfer on every high speed microframe."
> Right.  Timing is also a function of how many bytes the device on the other
> end sends back, particularly in some modes (some funny business around 62,
> though I imagine that # is different for hi-speed).  If you know your device
> will send something, and you have control over the hardware, some modes
> allow you to toggle a pin and have it flush the data back immediately.
> Another thing is that the bulk_read call has a timeout set by
> ftdi_context::usb_read_timeout.  I usually set it to 100 (ms) on my FT2232D
> with good results, and could probably go lower.  I don't ever set the
> latency timer under about 3ms, as that gives bad results.  Sorry to be so
> vague, but it's been about a year since I tweaked these.  There are two app
> notes that might be of interest to you:
> AN232B-03_D2XXDataThroughput.pdf
> AN232B-04_DataLatencyFlow.pdf
> But if I'm interpreting your question correctly, and you want it to return
> quickly if there's no data there, you really do need something asynchronous,
> as Jie suggested.  I've not fooled with this because my device always
> responds when I poll it, but if you use async, don't use the libusb compat
> layer.
> Michael

libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx

Current Thread