Tcl Source Code

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."

Win98 not supported. If the problem still exists with one of the versions of Windows built on the NT kernel, maybe we can reexamine?

File Added - 38409: tclWinSerial.c.patch

File Added - 38408: fconfigure.n.patch

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.

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]