Hello, I've got a problem with the FTDI-chip FT2232 running under Linux:
--------------------------- I have written a small test program for WinXP. The access to the FT2232 in FIFO-Mode occurs as expected. The porting to the Linux system was also successful.
I use the Evaluationboard "EZ1CUSB 12" of EasyFPGA as hardware. The board has a USB connector, a FT2232 chip and a FPGA. Linux system: Suse 10.1, Kernel 2.6.16.13 FTDI driver software: libftd2xx.so.0.4.10
When opening the DEVICE the following parameters are adjusted: FT_SetUSBParameters (ftHandle, 0 x10000, 0;) // InTransferSize = 64 Kbytes FT_SetLatencyTimer (ftHandle, 2); // Latency timer = 2 ms
To test the data processing speed I call following function in my program (ReadBurstFT2232 =): [1] The host PC claims a larger amount of data (e.g. 16 Kbytes). Therefore we write an instruction (approx. 5 bytes) with a FT_Write into the FPGA. The FPGA writes the requested data into the FIFO of the FT2232. [2] Start for the time measurement. [3] The status of the "Receive queue" is as long as queried with FT_GetStatus, till 16 Kbytes are available. The number of requests with FT_GetStatus are counted. [4] end of the time measurement. [5] The 16 Kbytes read into an Array in my program with FT_Read.
This function "ReadBurstFT2232" is called repeatedly in a loop. Great differences during the time measurement (= proportionally to the number of FT_GetStatus requests) occours:
- the first run needs approx. 1000 milliseconds.
- the next 2 -5 runs needs approx. 250 milliseconds
- all further runs needs approx. 30 milliseconds in which randomly runs occurs from time to time with approx. 150 milliseconds. I get comparable transmission delays for reputations -- if I call the loops with the "ReadBurstFT2232" requests. If I make a delay from approx 1ms [sleep(1)], all runs needs approx.
1000 milliseconds second. Under Windows the different transmission delays don't occur. Every run with an amount of data of 16 Kbytes needs approx. 18 milliseconds.
---------------------------
Has anybody got an idea about this issue? Could it perhaps be a resource scheduling issue of the host PC?
Greetings, Harald