If all you need is to stream serial data, use the kernel driver:
modprobe ftdi_sio
cat /dev/ttyUSB0 > file
It's higher performance, lower overhead, and simpler.
-jim
Krishnendu Chatterjee wrote:
> Hi,
>
> I presume, you are going to run your application on ARM running Linux. If
> so, D2XX driver cannot offer that kind of throughput. This is because
> "overlapped I/O" is not supported by D2XX driver on Linux. And you need
> overlapped I/O to sustain this kind of data rate. The reason is data fetch
> from FT2232 occurs only when FT_Read is executed. But due to application
> scheduling, your application, and hence the FT_Read function, may not be
> executed for sometime. The on-board 4kB buffer of FT2232 will provide some
> space to breath. But if it is full, and your application is not yet
> scheduled, then you will loose data.
>
> The way out is "overlapped I/O", which registers a number of transfers to
> the operating system, which can execute in the background as a parallel
> thread. These transfers are controlled by the device driver and interrupts.
> Hence they are less likely to be affected by the scheduler.
>
> Overlapped I/O is a Windows term. On Linux, they are replaced by
> asynchronous I/O. The latest libFTDI offers asynchronous I/O feature. I
> have not tested it, but it uses asynchronous I/O functions offered by
> libusb, which I know to work quiet effectively.
>
> I could manage to get data at around 1MB/sec using FT_Read. But not beyond
> that point.
>
>
>
> On Fri, May 10, 2013 at 9:46 AM, Peter Witkowski <pwitkowski@xxxxxxxxx>wrote:
>
> > Hello,
> >
> > I am writing an application that uses the FTDI FT2232H chip to read RS-485
> > data. The data is coming in at a fairly high rate (6 Mbps baud rate with
> > an effective data rate of about 3.2 Mbps). My application must read in the
> > data and then process it as quickly as possible. Latency is frowned up,
> > however I can generally accept up to 250 ms.
> >
> > I have interfaced with the device using the D2XX driver provided by FTDI.
> > Overall, the application works fine from a functional standpoint. However,
> > the D2XX driver alone pulls about 45% CPU usage. I have to run the
> > application on an embedded ARM processor, which runs at 720 Mhz, so I don't
> > have alot of horsepower per say. I am using the FT_Read() function in a
> > loop to extract the data and then pass it along. In a simple application I
> > wrote to test the driver, I extract the data in the loop and just write it
> > to a file. This alone pulls the 45% CPU usage figure (numbers from the top
> > command) referenced earlier.
> >
> > My problem is that I just received requirements forcing me to add to the
> > application. As a result, I was wondering if you all could give me some
> > sense of the type of performance (in terms of CPU load) that I could expect
> > comparatively from libftdi. I'm primarily interested in ball park numbers
> > of what I could expect using the ftdi_stream functionality. Note that the
> > application is written in C++, so if there are any things to worry about in
> > terms of compiling with g++ vice gcc, please let me know.
> >
> > Thank you in advance for your assistance. I will keep you appraised of my
> > progress.
> >
> > --
> > Peter Witkowski
> >
> > ------------------------------
> >
> > *libftdi* - see http://www.intra2net.com/en/developer/libftdi for details.
> > To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >
> >
>
>
> --
> Dr. Krishnendu Chatterjee
> IIT Delhi
> India
>
>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
