#2128 fconfigure -ttycontrol -mode problem

[Bob Parnass]

The order of the arguments for the fconfigure command affects the outcome of the operation on WIndows 98.

I am using ActiveTcl 8.4.1 on both Linux and Windows 98 Second Edition
to run a program I wrote which uses the serial port.

My program communicates with the peripheral device ok on Linux but not Windows and I've traced the problem to fconfigure's new -ttycontrol option.

Using a simple line monitor, I can see that the RTS line
is not being held low on Windows when I execute this command:

if { [catch {fconfigure $Sid \ -buffering none \ -translation binary \ -ttycontrol {DTR 1 RTS 0} \ -mode 4800,$parity,8,2 -blocking 1}] } \ {
set code -1
}

The RTS line is held low on Red Hat Linux 7.3.

I consulted with Rolf Schroedter, who responded:

"...Yes I see the problem. In Windows the -mode "string" interpretation resets all TTY states to their default values.
A simple workaround for you is to set the baud rate first and only then the
-ttycontrol. The following should work:

fconfigure $Sid -buffering none -translation binary -blocking 1 \ -mode 4800,$parity,8,2 -ttycontrol {DTR 1 RTS 0}

Or even
fconfigure $Sid -buffering none -translation binary -blocking 1
fconfigure $id -mode 4800,$parity,8,2
fconfigure $id -ttycontrol {DTR 1 RTS 0}

I'll have a look whether there is a way to correct this for future Tcl versions. On the other hand setting -mode is an elementary thing which reconfigures the UART hardware and should not be done during communication. Thank you for pointing out the problem."

[Rolf Schroedter]

Logged In: YES
user_id=99573

Donal, I hope you agree that I assigned this bug to me.

A call to "fconfigure $serial -ttycontrol {RTS 0} -mode
4800,n,8,2" results in two calls to SerialSetOptionProc(),
one with the "-ttycontrol" and the other with the "-mode"
option. Therefore it's not possible for the serial driver to
know that both options are set together in one "fconfigure"
call.

The problem is a result of using the Win-API BuildCommDCB(),
which implicitly resets the handshake parameters.

The patch is obvious: Setting "-mode" should only set the
BAUD,PARITY,DATA;STOP parameters, but not touch handshake.
This would make "-mode" behave more compatible to the Unix
version.

The patch would have two side effects (incompatibilities):

(1). Currently there is an undocumented feature that Windows
style mode strings are allowed for "fconfigure -mode" (see
below). A patch would in future ignore all handshake
settings via Windows style mode strings.

(2). For Windows/Tcl <= 8.3 "-mode" resets handshake. That
means the serial port never stalls completely. If now
"-mode" doesn't touch handshake, then the same script may
block for Tcl 8.4 if handshake is the system default.
On one hand this is an incompatibility for 8.3 ==> 8.4, but
on the other hand this is the Unix behaviour.

A solution for (2) could be to reset handshake at opening
the com-port, or even to setup a complete default baud rate,
e.g. 2400,n,8,1.

The question is: Should this be done or will we live with (2).
Are there other drawbacks of resetting handshake at open
(e.g. for standard channels ?) ?

Mode strings:
Windows 98(SE):
C:\>mode /?
Serieller Anschluss: MODE COMm[:] [BAUD=b] [PARITY=p]
[DATA=d] [STOP=s]
[RETRY=r]

Windows 2000:
C:\>mode /?
Serieller Anschluss: MODE COMm[:] [BAUD=b] [PARITY=p]
[DATA=d] [STOP=s]
[to=on|off] [xon=on|off] [odsr=on|off]
[octs=on|off] [dtr=on|off|hs]
[rts=on|off|hs|tg] [idsr=on|off]

[Rolf Schroedter]

Document Windows limitation to -ttycontrol lines

[Rolf Schroedter]

Logged In: YES
user_id=99573

Unfortunately the problem is a Windows limitation and cannot
be resolved.
Its not only BuildCommDCB() resetting handshake but
additionally SetCommState() setting the handshake lines
RTS/DTR to their default state depending on the handshake
state. Therfore all I can do is to document this Windows OS
limitation by adding the following remark to the "fconfigure"
man-page:

A limitation of Windows is that the RTS and DTR lines are
reset when one of the -mode, -handshake, -xchar or -
sysbuffer options are set.

Nevertheless a similar problem - The order of "fconfigure -
mode -handshake -xchar" is important - can be resolved by
the following tclWinSerial.c.patch.

[Rolf Schroedter]