Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Nov 2002 15:07:26 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        the evil toor <xride@x12.dk>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: sio howto
Message-ID:  <3DD0382E.2C531F72@mindspring.com>
References:  <20021111171109.P13478-100000@x12.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
the evil toor wrote:
> I just followed the recent sio thread, but it did not answer my questions.
> I have a program that needs to set RTS and DTR and then later set them
> again and again.. I could go for the open /dev/io and then the IO adr of
> the serial port.. but as far as i've seen it would lock up the kernel, but
> is there a good way to this?

DTR is set when you open the port.  It is reset on last close.

RTS is set when the low receive buffer is empty/below the low
watermark, and reset when it is full/above the high watermark;
RTS follows DTR on open/close (i.e. it is not asserted unless
th port is open).

To directly control RTS, you must disable CTS/RTS flow control,
which is on by defaults (see the "XXX" comment at ~ line 2286 in
/sys/isa/sio.c).

Assuming you have done this, you may control it using TIOCMSET,
a "Terminal I/O Control", using ioctl().

Assuming the port is open, you can control DTR via TIOCSDTR;
this assumes you can live with DTR coming high between the time
you open the port, and the time you disable it.  The same is
true of RTS, which follow DTR at initial open, as the default
state of the device.

There are no protections against RTS state changes when input
hardware flow control is enabled: that is, if you have input
flow control enabled, and are above the low watermark, and you
disable RTS, when the pending data causes the buffer to drop
below the low watermark, RTS will be reasserted automatically
(this is analogous to trying to use the loop control variable
for temporary storage in a "for.." loop).

See the serial driver source code for details.


If you want to be useful, you can force an interlock on the
CTS/RTS behaviour, and hardware flow control state, and add
device flags which may be specified on the device in the kernel
to control the initial state of these attributes on the device,
if it is not open or initialized (e.g. so that they don't go
high the moment you open the device, by default).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DD0382E.2C531F72>