AutoResetEvent.WaitOne Takes Excessive Time to Return (Serial Comms)

[Charles Law]

I have a frustrating problem where WaitOne does not return when I expect.

I am using an AutoResetEvent with an overlapped structure in a call to
WaitCommEvent. The data I am expecting on the serial port is 23 bytes long,
and is sent in response to a command.

I begin timing before sending the command, and display split times when
received data is signalled. The entire exchange of command and response is
over within 6 ms (I have checked this with a scope).

When WaitOne first returns there are 18 characters in the receive buffer,
and the split time is 5 ms. As this is not the complete message, I call
WaitOne again to wait for a signal that the remaining data has been
received.

WaitOne then takes 10 ms before returning, just to signal that the remaining
5 bytes have been received.

I do not understand why the bulk of the data can be received and signalled
in 5 ms, whilst the remaining few bytes take a whacking 10 ms to be
signalled. I have checked with a scope and there are no gaps in the data -
the received data comes in as a contiguous stream, less than 1 ms after the
command is received by the remote device.

I know this is a big ask, but can anyone think why such a thing would happen
with AutoResetEvents?

TIA

Charles

[Charles Law]

And the answer is ...

The FT232AM chip that I am using has a fixed 16 ms latency when the buffer
is not full.

Charles
"Charles Law" <bl***@nowhere.com> wrote in message
news:Ol**************@tk2msftngp13.phx.gbl...

I have a frustrating problem where WaitOne does not return when I expect.

I am using an AutoResetEvent with an overlapped structure in a call to
WaitCommEvent. The data I am expecting on the serial port is 23 bytes
long, and is sent in response to a command.

I begin timing before sending the command, and display split times when
received data is signalled. The entire exchange of command and response is
over within 6 ms (I have checked this with a scope).

When WaitOne first returns there are 18 characters in the receive buffer,
and the split time is 5 ms. As this is not the complete message, I call
WaitOne again to wait for a signal that the remaining data has been
received.

WaitOne then takes 10 ms before returning, just to signal that the
remaining 5 bytes have been received.

I do not understand why the bulk of the data can be received and signalled
in 5 ms, whilst the remaining few bytes take a whacking 10 ms to be
signalled. I have checked with a scope and there are no gaps in the data -
the received data comes in as a contiguous stream, less than 1 ms after
the command is received by the remote device.

I know this is a big ask, but can anyone think why such a thing would
happen with AutoResetEvents?

TIA

Charles