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]
