FTDI Community

General Category => Discussion - Drivers => Topic started by: aleruggeri87 on November 06, 2019, 09:25:59 PM

Title: FT_GetQueueStatus() does not return a DWORD
Post by: aleruggeri87 on November 06, 2019, 09:25:59 PM
Hello,

I'm using an FT232H in ASYNC Serial mode.
I'm calling FT_GetQueueStatus() to understand how many characters has been received, and how many "data packets" (200-byte each in my case) I can read from the RX queue. Even if I'm using a DWORD pointer for the lpdwAmountInRxQueue parameter, it seems that the returned value saturates to 2^16 (65536, thus it is not for some strange reason internally handled as a 16-bit value, that will lead to 2^16-1 max).

In any case, if I receive more than 2^16 bytes, let's say 70k, data is correctly kept in the queue; reading some of them to go below 2^16, say 20k, FT_GetQueueStatus() starts again to indicate the correct number of bytes in the queue.

I overcomed the issue with a loop around the getStatus and Read, but I was wondering if this is a bug or something well known, but not fully documented.

Thanks and regards,
Alessandro.
Title: Re: FT_GetQueueStatus() does not return a DWORD
Post by: Ari100tel on March 12, 2020, 12:35:16 PM
Hello,

I have the same problem with FT232H working in Sync FIFO mode.
FT_GetQueueStatus() and FT_GetStatus() both return maximum 65536 bytes despite the fact that in the buffer there is much more data.
But using  FT_GetQueueStatusEx() gives correct number of bytes.
Maybe this is how it should work?
Did anyone have the same issue?

Regards,
Sergey
Title: Re: FT_GetQueueStatus() does not return a DWORD
Post by: FTDI Community on March 13, 2020, 02:47:20 PM
Hello,

It is also best to have your application regularly checking the queue status and reading the data from the driver buffer into your own application buffer for processing.

If the driver buffers keep filling up, you will eventually reach a point where either data is lost (if you don't use handshaking lines)     or where the chip is unable to take more data from the attached serial device and de-asserts the flow control (if you use handshaking which we strongly recommend). This would be CTS or DSR for UART and would be TxE for FIFO. In this latter case your serial/FIFO device would need to pause sending and buffer up any data.

We therefore recommend to have your application check the queue status, read however many bytes are reported available if > 0 and then repeat this etc.

Best Regards, FTDI Community