Low-Level control of RS232 (Com-Port) RTS/CTS/DTR/DSR possible?

Question

I wonder if and how it's possible to control the RS-232 handshaking lines directly from win32 (the old C-API).

I'd like to interface with an external piece of hardware, and two simple data-lines would be sufficient for my needs.

So - is there a API for win32 that lets me read and write the state of the four status lines? In normal serial communication the handshaking lines are driven by the UART automatically (if hardware handshaking is enabled).

I remember that it was trivial under DOS. One just had to program the UART directly. Has this functionality survived in win32 somehow?

Answer 1

You can control RTS and DTR using SetCommState(). You can also set things up to have hardware or the driver handle hardware flowcontrol (CTS and/or DSR), or you can set things up using SetCommMask() so you get events when those signals change.

A decent overview is here: http://msdn.microsoft.com/en-us/library/ms810467.aspx

Note that the Win32 Serial Comm API and/or driver can be finicky, so be prepared to have to do some debugging of what's going on on the wire.

Answer 2

I ran across this tutorial when I had to do a project to communicate with the RS232 port. It's a complete example on how to open the port, set some properties including the timeouts, read/write and close the port. Even though your project is probably over by now, I hope this will remain useful as it remains in the SO archives.

Answer 3

You can still do similar types of programming only to get to protected hardware you will need to implement a device driver. I assume that this has gotten easier since the 1980s when I was doing the same type of work.

Answer 4

Is microsoft actually doing hardware handshaking now? For many years NT, win2000 and XP did not do handshaking in the hardware. Instead when the fifo reached a certain point the device driver would manually change the cts line. Which means it was incredibly simple to cause the device driver to lose data, grab a window with the mouse and do circles around the screen for example (making sure you take that window off the left side of the screen on all or some of the passes). Alt-enter to take a command prompt to/from full screen was an easy way to cause a data loss. Or anything else that causes enough of an interrupt latency. Basically microsofts hardware flow control is not hardware but software flow control, even if the hardware does have hardware flow control capabilities microsft's drivers were not setting that bit. SeaLevel eventually did support that bit, well sorta, you had to put the right unrelated settings in SetCommState() to enable it.

As far as your program controlling the signals, use SetCommState().

Answer 5

There are some USB to Serial adapters that do not support the DTR/DSR/DCD flow control. So may be this is your case.

http://www.digi.com/support/kbase/kbaseresultdetl?id=588