Can't access serial port with Tcl and FreeBSD
Mike Clarke
tk-8.4.11,2 but I can't get it to communicate with my Garmin Etrex receiver
on the second serial port, (which I assume is /dev/cuad1 ?)
The error message I get is:
bad option "-mode": should be one of -blocking, -buffering, -buffersize,
-encoding, -eofchar, or -translation while executing
"fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 -translation binary"
("unix" arm line 3)
invoked from within
"switch $tcl_platform(platform) {
unix {
set Polling 0 ; set InBuff ""
fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 -translation
binar..." (procedure "OpenSerialFailed" line 10)
invoked from within
"OpenSerialFailed $SERIALBAUD"
(procedure "GPSConnection" line 17)
invoked from within
"GPSConnection EnableGPS"
(procedure "CheckGPS" line 7)
invoked from within
"CheckGPS "
invoked from within
".rcw.fr.frgps.bs.state invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tk::ButtonUp" line 22)
invoked from within
"tk::ButtonUp .rcw.fr.frgps.bs.state"
(command bound to event)
The "Known problems" page on the gpsman website
<http://www.ncc.up.pt/gpsman/wGPSMan_6.html> acknowledges this problem for
some OS's but doesn't appear to have any known solution for me.
"GPSMan relies on the use of a serial port to communicate with
the GPS receiver. Some Tcl/Tk installations (e.g., in SuSe, Red
Hat and Mandrake Linux distributions), operating system drivers
and even hardware (in some laptops) were reported not to work
correctly with the serial port. Namely, the Tcl error: "bad
option -mode" is a problem of bad configuration of the Tcl/Tk
installation and upgrading to a newer version normally solves
the problem. To help debugging input from a serial port a Tcl/Tk
program is available from here. It must be edited before use to
set the correct path to the serial port."
My tcl/tk packages are up to date and the test program just comes up with
the same arror.
Can anyone suggest how I might be able to get round this problem? Tcl
accesses the GPS receiver OK with Debian and Windows but I'm trying to
migrate from Debian to FreeBSD and I'm trying to reduce my dependence on
Windows.
--
Mike Clarke
Uwe Klein
> I'm running gpsman-6.2.1 on FreeBSD 6.0-RELEASE with tcl-8.4.11,1 and
> tk-8.4.11,2 but I can't get it to communicate with my Garmin Etrex receiver
> on the second serial port, (which I assume is /dev/cuad1 ?)
>
> The error message I get is:
>
> bad option "-mode": should be one of -blocking, -buffering, -buffersize,
> -encoding, -eofchar, or -translation while executing
getting bad option : "-mode"
means that tcl is certain this is not a serial device
which i have found is sometimes not the complete story.
possibilities ( IMHO ):
/dev/cuad1 did not exist and is now a plain file
/dev/cuad1 is a serial device with no hardware behind it
( had this on linux might be the same problem on bsd* )
what does ( at a shell prompt ) "file /dev/cuad1" tell you?
uwe
Mike Clarke
> getting bad option : "-mode"
> means that tcl is certain this is not a serial device
> which i have found is sometimes not the complete story.
>
> possibilities ( IMHO ):
> /dev/cuad1 did not exist and is now a plain file
> /dev/cuad1 is a serial device with no hardware behind it
> ( had this on linux might be the same problem on
> bsd* )
>
> what does ( at a shell prompt ) "file /dev/cuad1" tell you?
>
owl:/home/mike% file /dev/cuad1
/dev/cuad1: character special (0/55)
owl:/home/mike% ls -l file /dev/cuad1
ls: file: No such file or directory
crw-rw---- 1 uucp dialer 0, 55 Jan 19 16:16 /dev/cuad1
--
Mike Clarke
Mike Clarke
> owl:/home/mike% file /dev/cuad1
> /dev/cuad1: character special (0/55)
> owl:/home/mike% ls -l file /dev/cuad1
> ls: file: No such file or directory
> crw-rw---- 1 uucp dialer 0, 55 Jan 19 16:16 /dev/cuad1
Oops - finger trouble, should have been:
owl:/home/mike% ls -l /dev/cuad1
crw-rw---- 1 uucp dialer 0, 55 Jan 19 21:08 /dev/cuad1
--
Mike Clarke
Uwe Klein
the tty char-devices i found on the net had another major number ( not 0 ).
what i found usually had major:28 and minor 128,129...
are you ( as the user of the script you start) in the dialer group
i.e. is your account name in /etc/group listed under dialer
have a look at this url:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/serial.html#FOUND-SERIAL
can you verify that both SIO devices are found?
what info do get with
file /dev/cua*
and
ls -l /dev/cua*
uwe
Rolf Schroedter
Tcl builds distributed with some Unix'es.
Rebuilding Tcl was the solution ...
Rolf.
--
---------------------------------------------------------------
Rolf Schroedter, German Aerospace Center
Remove .nospam to reply: mailto:Rolf.Sc...@dlr.de.nospam
Ian Bell
> I'm running gpsman-6.2.1 on FreeBSD 6.0-RELEASE with tcl-8.4.11,1 and
> tk-8.4.11,2 but I can't get it to communicate with my Garmin Etrex
> receiver on the second serial port, (which I assume is /dev/cuad1 ?)
>
> The error message I get is:
>
> bad option "-mode": should be one of -blocking, -buffering, -buffersize,
> -encoding, -eofchar, or -translation while executing
Are you sure the serial port is open. here is a snippet from a serial comms
app of my own which checks port existence and ownership before opening the
port and then configuring it:
if { [file exists $device ] } {
if { [file owned $device ] } {
set serialfd [open $device {RDWR NOCTTY} ]
fconfigure $serialfd -mode $params -buffering none -blocking 0
-translation binary
fileevent $serialfd readable rxchar
HTH
Ian
Mike Clarke
> the tty char-devices i found on the net had another major number ( not 0
> ). what i found usually had major:28 and minor 128,129...
I was initially puzzled by seeing cuad* instead of cuaa* in /dev but it
appears that it's a change brought in with FreeBSD 6.0. I've still got 5.4
on another partition and when I boot into that I see cuaa0 and cuaa1 with
major 239 and minor 128,129 as opposed to cuad* with 0 and 49,55. I can't
access the serial port with that version either :-(
> are you ( as the user of the script you start) in the dialer group
> i.e. is your account name in /etc/group listed under dialer
Yes I'm in the dialer group.
> have a look at this url:
>
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/serial.html#FOUND-SERIAL
> can you verify that both SIO devices are found?
Yes:
owl:/home/mike% dmesg | grep sio
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
> what info do get with
> file /dev/cua*
> and
> ls -l /dev/cua*
owl:/home/mike% file /dev/cua*
/dev/cuad0: character special (0/49)
/dev/cuad0.init: character special (0/50)
/dev/cuad0.lock: character special (0/51)
/dev/cuad1: character special (0/55)
/dev/cuad1.init: character special (0/56)
/dev/cuad1.lock: character special (0/57)
owl:/home/mike% ls -l /dev/cua*
crw-rw---- 1 uucp dialer 0, 49 Jan 20 12:57 /dev/cuad0
crw-rw---- 1 uucp dialer 0, 50 Jan 20 12:57 /dev/cuad0.init
crw-rw---- 1 uucp dialer 0, 51 Jan 20 12:57 /dev/cuad0.lock
crw-rw---- 1 uucp dialer 0, 55 Jan 20 12:57 /dev/cuad1
crw-rw---- 1 uucp dialer 0, 56 Jan 20 12:57 /dev/cuad1.init
crw-rw---- 1 uucp dialer 0, 57 Jan 20 12:57 /dev/cuad1.lock
--
Mike Clarke
Mike Clarke
> Are you sure the serial port is open. here is a snippet from a serial
> comms app of my own which checks port existence and ownership before
> opening the port and then configuring it:
>
> if { [file exists $device ] } {
> if { [file owned $device ] } {
> set serialfd [open $device {RDWR NOCTTY} ]
> fconfigure $serialfd -mode $params -buffering none -blocking 0
> -translation binary
> fileevent $serialfd readable rxchar
>
I've added a couple of puts diagnostic lines to the gpsman script:
proc OpenSerialFailed {baud} {
# open serial port at given baud rate, and log file if needs be
# return 1 on failure
global MESS SRLFILE SERIALPORT InBuff Polling Eof tcl_platform
if { [catch {set SRLFILE [open $SERIALPORT r+]}] } {
GMMessage [format $MESS(badserial) $SERIALPORT]
return 1
}
puts "SERIALPORT = $SERIALPORT SRLFILE = $SRLFILE"
switch $tcl_platform(platform) {
unix {
set Polling 0 ; set InBuff ""
puts "fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 -translation binary"
fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 \
-translation binary
fileevent $SRLFILE readable ReadChar
}
windows {
# Tcl/Tk 8.0p2 does not support I/O from/to serial ports
set Polling 1 ; set InBuff ""
fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 \
-translation binary
# after 0 ReadPollChar
after 0 ReadChar
}
default {
GMMessage $MESS(badplatform)
return 1
}
}
set Eof 0
OpenSerialLog
return 0
}
The output I get is:
SERIALPORT = /dev/cuad1 SRLFILE = file4
fconfigure file4 -blocking 0 -mode 9600,n,8,1 -translation binary
The original Tcl error was:
bad option "-mode": should be one of -blocking, -buffering, -buffersize,
-encoding, -eofchar, or -translation
So it looks like there's something wrong with using "-mode 9600,n,8,1" and
the baud rate etc should be specified by some other means.
As an experiment I deleted "-mode 9600,n,8,1" from the fconfigure call and
managed to stop the error from appearing. Gpsman then went through the
motions of accessing the receiver and brought up the expected dialog box
but didn't transfer any data, I assume that's because it was using a
default baud rate that wasn't suitable.
With my very limited Tcl experience I don't know what the correct parameters
should be so I'd welcome any advice on what to try next.
--
Mike Clarke
Uwe Klein
Hi Mike, i am slightly/majorly stumped
> owl:/home/mike% ls -l /dev/cua*
> crw-rw---- 1 uucp dialer 0, 49 Jan 20 12:57 /dev/cuad0
> crw-rw---- 1 uucp dialer 0, 50 Jan 20 12:57 /dev/cuad0.init
> crw-rw---- 1 uucp dialer 0, 51 Jan 20 12:57 /dev/cuad0.lock
> crw-rw---- 1 uucp dialer 0, 55 Jan 20 12:57 /dev/cuad1
> crw-rw---- 1 uucp dialer 0, 56 Jan 20 12:57 /dev/cuad1.init
> crw-rw---- 1 uucp dialer 0, 57 Jan 20 12:57 /dev/cuad1.lock
>
if i have understood BSD docs right the sios should be major 28 ...
crw-rw---- 1 uucp dialer 28, 128 Jan 20 12:57 /dev/cuad0
crw-rw---- 1 uucp dialer 28, 129 Jan 20 12:57 /dev/cuad0.init
crw-rw---- 1 uucp dialer 28, 130 Jan 20 12:57 /dev/cuad0.lock
>
from :
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html
what does
stty -a -f /dev/cuad0.init
stty -a -f /dev/cuad0
and
stty -a -f /dev/cuad1.init
stty -a -f /dev/cuad1
tell you?
should look similar to this:
<output stty>
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
-iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
</output stty>
uwe
Ian Bell
>> SERIALPORT = /dev/cuad1 SRLFILE = file4
> fconfigure file4 -blocking 0 -mode 9600,n,8,1 -translation binary
>
> The original Tcl error was:
> bad option "-mode": should be one of -blocking, -buffering, -buffersize,
> -encoding, -eofchar, or -translation
>
> So it looks like there's something wrong with using "-mode 9600,n,8,1" and
> the baud rate etc should be specified by some other means.
>
The -mode option to fconfigure is only valid if you are referring to a
serial port. If it does not exist or fails to open for some reason
(privileges for example) then fconfigure will fail.
Ian
Mike Clarke
> if i have understood BSD docs right the sios should be major 28 ...
> crw-rw---- 1 uucp dialer 28, 128 Jan 20 12:57 /dev/cuad0
> crw-rw---- 1 uucp dialer 28, 129 Jan 20 12:57 /dev/cuad0.init
> crw-rw---- 1 uucp dialer 28, 130 Jan 20 12:57 /dev/cuad0.lock
> >
> from :
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html
Yes, that's what I would have expected but when I did a Google search
for /dev/cuad and FreeBSD I came across lots of references to things being
changed because of renaming cuaa* to cuad* but nothing which appeared to
apply to my problem. I understand that updating the handbook sometimes lags
a bit behind the software.
> what does
>
> stty -a -f /dev/cuad0.init
> stty -a -f /dev/cuad0
> and
> stty -a -f /dev/cuad1.init
> stty -a -f /dev/cuad1
>
> tell you?
>
> should look similar to this:
> <output stty>
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2
> = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
> lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl
> -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck
> -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
> vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt echoctl echoke </output stty>
Looks similar but slightly different, but I suppose it does confirm that
they are serial ports:
owl:/home/mike% stty -a -f /dev/cuad1.init
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
owl:/home/mike% stty -a -f /dev/cuad1
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
The results for cuad0 look the same.
As a pure shot in the dark I've also tried specifying cua1.init as the port
but get the same error.
I suspect the cuaa - cuad issue is probably not related to this problem
because I get the same problem with FreeBSD 5.4 which does have /dev/cuaa1.
I'm inclined to think it's related to the use of "-mode 9600,n,8,1" in the
fconfigure call, but that's an area I've no experience with.
--
Mike Clarke
Mike Clarke
> If I recall correctly, a while ago there has been an issue with wrong
> Tcl builds distributed with some Unix'es.
> Rebuilding Tcl was the solution ...
Looks like that might be worth a try. I'm going to be away from this PC for
the next week but it's on the list of things to try after I get back.
--
Mike Clarke
Mike Clarke
> The -mode option to fconfigure is only valid if you are referring to a
> serial port. If it does not exist or fails to open for some reason
> (privileges for example) then fconfigure will fail.
So I suppose it looks like Tcl doesn't think /dev/cuad1 is a serial port.
There's been some discussion about /dev/cuad1 as opposed to cuaa1 further
up the thread with Uwe Klein. It certainly looks as though these are serial
ports as far as the OS is concerned but perhaps Uwe's doubts are justified
in that these new devices aren't compatible with what Tcl expects?
--
Mike Clarke
Ian Bell
Well, in your last post you certainly got back a valid file descriptor when
you opened the port so I have to concur with your reasoning. Which means
the next step is a quick foray into the source code. Strange thing is, I
have this working fine with USB/serial convertors under Linux.
Ian
Uwe Klein
> Mike Clarke wrote:
>
>
>>Ian Bell wrote:
>>
>>
>>>The -mode option to fconfigure is only valid if you are referring to a
if -mode ... produces an error "wrong option" tcl thinks "this is NO tty"
if -mode ... produces an error "bad value for -mode" you have botched the baudrate...
look into tclUnixChan.c look for
^TtySetOptionProc and ^TtyParseMode
>>>serial port. If it does not exist or fails to open for some reason
>>>(privileges for example) then fconfigure will fail.
>>
>>So I suppose it looks like Tcl doesn't think /dev/cuad1 is a serial port.
>>There's been some discussion about /dev/cuad1 as opposed to cuaa1 further
>>up the thread with Uwe Klein. It certainly looks as though these are
>>serial ports as far as the OS is concerned but perhaps Uwe's doubts are
>>justified in that these new devices aren't compatible with what Tcl
>>expects?
>>
>
>
> Well, in your last post you certainly got back a valid file descriptor when
> you opened the port so I have to concur with your reasoning. Which means
> the next step is a quick foray into the source code. Strange thing is, I
> have this working fine with USB/serial convertors under Linux.
>
> Ian
Couple of years ago i ran into this on linux.
The char special file had the right major,minor numbers
but the hardware (8way PCI serial card) was not bound properly with setserial.
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/956b3e75a5ae586a/
is there an strace in FreeBSD? try that and look for the open/ioctl/termio calls
to the system.
uwe
Mike Clarke
Clarke <UCEb...@milibyte.co.uk> wrote:
I've just had the chance to try a different FreeBSD 5.4 PC and got the
same problem (with /dev/cuaa1 as opposed to cuad1 with 6.0). I
uninstalled the Tcl/Tk 8.4.7 packages and rebuilt 8.4.12 from source.
This has cured the problem.
The FreeBSD 6.0 box was running Tcl/Tk 8.4.11 and had the same problem
so, unless there a major difference between 8.4.11 and 8.4.12 it looks
as though it's a problem with the FreeBSD binary packages. I'll rebuild
from source on the FreeBSD 6.0 box when I get back there and report back
in a week or two's time.
--
Mike Clarke
Mike Clarke
> I'll rebuild
> from source on the FreeBSD 6.0 box when I get back there and report back
> in a week or two's time.
That appears to be the solution.
I'm back on the FreeBSD 6.0 box where I've just uninstalled the Tcl & Tk
packages and rebuilt from the sources of the FreeBSD ports for version
8.4.11 and everything works fine now.
I'm puzzled why this should be so because it's exactly the same versions as
the pre-compiled packages I was using and which would have been built from
the same source code. All I did was to rebuild the port "out of the box"
without making any adjustment to the configuration.
Thanks to everyone for all your suggestions. It's a few years since I last
dabbled with Tcl and this has been a great help in re-familiarising me with
it.
--
Mike Clarke