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?

Grilled

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.

Paunchy

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.

Calices

Your this-link is dead. Do you remember at least the title of it? – Selfmoving

It is still possible to access through WaybackMachine Internet Archive: Serial How-To - RobBayer.com Windows Serial Port Programming - Robertson Bayer (PDF) – Alright

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.

Hypoplasia

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().

Blackmun

It's been a while since I worked on this stuff, but my memory is that the 8250/16550 UARTs that are standard issue in the PC world do not handle hardware handshaking on-chip. This is not an issue of the Win driver - it can only support what the hardware has. The driver has to get status during device interrupt and toggle/sense the handshaking lines itself. SeaLevel or Hayes had (or have) more intelligent hardware and their drivers would take advantage of that. Also, it's certainly true that early Windows drivers were really, really bad, but they eventually got to be more or less good enough. – Paunchy

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

Intercom