The D2XX API basically is a way to make the Win32 File API available on other OSes. All its functions try to work exactly like the Win32 APIs.
A number of programmers have learned an inferior approach to communications, usually by bad examples written by framework programmers who don't actually use serial ports on a daily basis. Ask yourself which of these conversations is better:
- > Tell me about incoming data.
- < Ok.
- < EVENT! Here's some data that just arrived.
- > Thanks! Please tell me if you receive any more.
vs
- > Tell me about incoming data.
- < Ok.
- < EVENT! I heard something!
- > What did you hear?
- < Here's the received data.
- > Thanks! I'm ready to hear about more data.
Clearly the first version is a lot simpler and more efficient. That's why I discourage you from asking "How do I get that 'I heard something!' event?" Instead you should focus on how to get the "Here's the new data" event.
If you want an event when your serial-connected device sends you data, use FT_W32_ReadFile
in overlapped mode. When you do that, the OVERLAPPED structure has an hEvent
member, that event will be triggered when data arrives1. And the data itself will already be in your buffer, you won't need a separate operation to get it.
The .NET class AutoResetEvent
is the way to create a kernel event object that you attach to the OVERLAPPED hEvent
.
1 Actually, when the read operation completes. It can complete because the buffer was filled, or because a timeout (configured using FT_W32_SetCommTimeouts
) occurred. The ReadIntervalTimeout
is fantastic, because it causes the read to finish whenever there is a gap in the data. This generally corresponds to individual messages from the attached device. While you shouldn't rely on one read completion = one message, the fact is that having an event at the end of a message is the optimal combination of buffering and responsiveness.