Windows 7 - Control of serial RTS line.

Asked By Guid on 13-Nov-08 05:44 AM

I am looking for a way to control the RTS line of a serial interface
So the state should also be valid after closing the serial interface (COM

I have tried several ways (DOS mode command (rts=on/off), SetCommState,
programming MCR register directly (giveio.sys)) but when the program releases
the serial interface (COM port) the old state of the RTS line is restored.

Could anyone give me a hint?

Thanks & Regards.

Wilhelm Noeker replied on 13-Nov-08 06:59 AM
The serial driver does not allow this, by design. If you look at the DDK
sample code (src\kernel\serial\openclos.c), you will see that DTR and
RTS are cleared explicitly and unconditionally when the port is closed.
Guid replied on 14-Nov-08 04:13 AM
Thanks for your answer.
But the reality (Windows XP) shows that on some laptops/notebooks the RTS line
is high after booting or closing the serial port.
I am looking concrete for a way to clear the RTS line (as intended by design)
on these laptops/notebook to get well defined conditions for serial
mpv replied on 14-Nov-08 02:51 PM

I've looked again in Joe Campbell's: C Programmer's Guide to Serial
The RTS/CTS lines are officially only used in half-duplex modems. In all but
these prehistoric
modems, RTS is ignored and CTS is permanently high. In typical computers,
RTS is high by
default (as you have found).

The null-modem cables in the book all tie RTS to CTS.
You could just tie the line to a known high or low if you want it to have a
known state.

Besides, I do not think you really need to care about the state of RTS.
On modern equipment, you should not need any handshaking at all. I use data
equipment at 115200 bps with 64K packets using 3 line cables, no hardware
is needed, not even software handshaking is used.

regards, Matt
Guid replied on 17-Nov-08 04:31 AM

Thanks for your help.
But in the application the RTS line is used for some special function
(enabling transmitter for RS485) and had to be controlled directly
by a special software. The problem is to set this line to a deterministic
level when the software is not running (idle or after booting).

mpv replied on 17-Nov-08 05:57 AM

In that case, I think you really might have a half-duplex modem. Many years
ago, I did write some software for the Hart protocol, which used an ancient
Bell modem standard, which was half-duplex. The RTS line was used to toggle
between sending and receiving data.
This system used a fixed master/slave system, and it was clear who would
initiate the communication. Surely something like that must be the case in
your setup ?

regards, Matt
Ben Voigt [C++ MVP] replied on 17-Nov-08 10:59 AM
In RS-232, "clear" is "high" as in positive voltage means binary 0.  "mark"
is the negative voltage means binary 1.
Guid replied on 18-Nov-08 07:44 AM

This kind of software I have. But when this software is not running on some
PCs the RTS line will be pulled automatically to high and this enables
the transmitter and this blocks the RS485 bus. So you must disconnect
the cable each time when the software is not running.

Pavel A. replied on 18-Nov-08 03:46 PM
Maybe you can make a simple adapter that inverts the RTS line.
Then, in idle state (your app not running), RTS will be low,
and your app should toggle it as needed, while it runs.

Wilhelm Noeker replied on 19-Nov-08 08:10 AM
So what is special about these "some" PCs? Do they have serial cards
with vendor-supplied drivers?

I am still convinced that any COM port controlled by the
Microsoft-supplied serial.sys will drop RTS when not in use. (And as far
as I know, all serial ports are briefly opened when the computer starts,
because serenum.sys is looking for attached devices.)

Btw.: Setting RTS_CONTROL_TOGGLE in the DCB structure is supposed to
make RTS behave just the way you describe it, but apparently you
implemented that behaviour in your own software. How come?
Maxim S. Shatskih replied on 27-Nov-08 01:03 PM
all but=20

All serial-attached modems use RTS/CTS for flow control.

Maxim S. Shatskih
Windows DDK MVP
mpv replied on 29-Nov-08 03:41 PM
Hi Maxim,

I am afraid that things are not that simple.

- Some modems are half-duplex and use RTS/CTS for switching between talking
and listening.
The RS-485 modem that Guido is talking about falls in this category. RS-485
does not use hardware
flow control. These modems are still used, typically in process control.
Some very early Bell modems
were also half-duplex. The original RS-232 standard concerns these very
early modems.
- Some modern modems indeed use them for hardware flow control. I have
looked at the manual
of a later USR Courier modem and it indeed does use RTS/CTS for hardware
flow control.
- Some (older) modems have no hardware flow control and do not use RTS/CTS
at all.
For instance the Hayes Smartmodems that Joe Campbell wrote about in 1987
fall in this category.

Regards, Matt