Hi,
>>It seems that you are having issues with the Linux D3xx driver and Windows D3xx driver is OK?
Right.
>>Please check that you are using the latest driver versions:
>>
https://ftdichip.com/drivers/d3xx-drivers/Yes I am using the latest (0.5.21).
>>Please see the following information on Transfer efficiency in D3XX Linux Library:
>>The D3xx for Linux library allocates a reading queue with 256 of 32Kbytes buffers internally by default at startup, it will keep requesting to the host driver until there is no free buffer in the queue, and the library will not combine returned buffer in the >>queue.
OK
>>When fStopReadingOnURBUnderrun flag is set, the FT_ReadPipe / FT_ReadPipeEx API will return immediately when encountering any buffer with length less then 32Kbytes, even if there are more filled buffers in the queue.
I am not sure what does it mean. Does it mean that when I run the FT_ReadPipe with BUFFER_LEN parameter less than 32Kbytes, that FT_ReadPipe will return immediately without any TXE_N = '0' at the FPGA side?
Like this: BUFFER_LEN = 4096; FT_ReadPipe(handle, 0x82, buf.get(), BUFFER_LEN, &count, NULL))
>>When fStopReadingOnURBUnderrun is not set, the FT_ReadPipe / FT_ReadPipeEx API will try to satisfy the requested reading size by merging all available filled buffers in the queue, buffer size is ignored.
>>Transfer efficiency is not determined by the reading size in D3XX for Linux, our tests showing that best performance can be achieved as long as the reading size is >= 3bytes each time.
Right now I am not concerned about efficiency. I will be satisfied even if I reach the 100MB/s reading rate.
>>Non 1K aligned data will cause additional process time on FIFO bus, FT600 bridge chip and USB3 bus, the overhead could cause FPGA master's FIFO buffer overflow, and wrong data will be collected.
I am not using non 1K aligned data.
>>Best performance can be achieved when FPGA is sending 1K aligned data as much as possible. If its not feasible to change FPGA's behaviour, try setting: CONFIGURATION_OPTIONAL_FEATURE_DISABLEUNDERRUN_INCHALL flag in chip configuration to >>remove the latency on USB3 bus.
I changed it but it appear that behavioral is the same.
>>Also try to avoid doing any heavy processing or calls to printf() from the thread which calls FT_ReadPipe(), otherwise the library's reading queue may be used up. You can use another thread to parse, or simply dump all the content into another file to verify >>the issue.
In the final application I will use lot of threads, and I will have single write thread and single read thread where I will only use FT_WritePipe() and FT_ReadPipe() and buffers. All threads will be protected by mutex, so I will have single operation at the time.
But this is not my concern at the moment.
For now, I just want to force FT_ReadPipe() to behave as FT_WritePipe(). So, when I call a single FT_WritePipe() (not from within the tread but from "main") with BUFFER_LEN = 64 I see that at the FPGA side there is a transfer of 16 of 32b words (so exactly 64Bytes).
When I call single FT_ReadPipe() (not from within the tread but from "main") I see sometimes lot of transfers from FPGA to FT601Q (each 4kBytes long) or no transfer at all (I have never saw transfer of 1024Bytes, no mater if I put BUFFER_LEN = 1024).
>>Best Regards,
>>FTDI Community
Thanks for the answer.
Petar