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 <[email protected]>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 [email protected] > > > > > > > -- > Dr. Krishnendu Chatterjee > IIT Delhi > India > > > -- > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > To unsubscribe send a mail to [email protected] -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
