From: Peter Stuge <peter@stuge.se>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] serial port handling question
Date: Thu, 14 Jan 2010 03:55:07 +0100 [thread overview]
Message-ID: <20100114025507.8044.qmail@stuge.se> (raw)
In-Reply-To: <20100113185240.4bc9d721@osage.osagesoftware.com>
David Relson wrote:
> I'm porting some old DOS code to Linux for a medical device that is
> being upgraded.
Interesting, this business.
> The sensor is controlled (in part) by setting RTS on and off.
What is controlled, exactly? What is RTS being used for? If it is
indeed flow control then you are lucky and can simply enable hardware
flow control for the serial port, and Linux will then take care of
everything for you.
If not flow control and some other signalling, you have to write a
line discipline driver. I have done both this and serial drivers
(also related to DOS era equipment) and documentation is not the
greatest. Let me know if you would like some help.
> I looked high and low (pun intended) for an ioctl or similar call
> that would allow this level of control and couldn't find anything.
The best thing out there is tcsetattr() and friends.
By switching between baud rate 0 and something else you can reliably
and easily control both RTS and DTR, and nothing but RTS and DTR, but
always both at the same time.
Line disciplines can call the tty_throttle() and tty_unthrottle()
functions in the serial driver, which will then control RTS
accordingly, but the default TTY line discipline does not expose any
API that will result in throttle function calls.
> outb(inportb(MCR) | 0x02, MCR); //DTR,RTS=ON
> outb(inportb(MCR) & ~0x02, MCR); //DTR=ON,RTS=OFF
>
> Directly tweaking the I/O port runs against the grain, but it's the
> only thing I've found that works.
Not only against the grain, it can mess up internal state in the
kernel serial layer and worst case lead to a kernel BUG_ON (kernel
hangs) or best case serial port hang (unhang e.g. by closing all file
handles for the port and opening again). It is not at all nice to
change these signals behind Linux' back.
//Peter
next prev parent reply other threads:[~2010-01-14 2:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-13 23:52 [gentoo-embedded] serial port handling question David Relson
2010-01-14 2:55 ` Peter Stuge [this message]
2010-01-14 4:30 ` David Relson
2010-01-14 5:08 ` Peter Stuge
2010-01-14 10:53 ` Peter Bell
2010-01-14 2:56 ` Daniel Stonier
2010-01-14 3:47 ` Peter Stuge
2010-01-14 4:09 ` David Relson
2010-01-14 10:05 ` Bob Dunlop
2010-01-14 12:29 ` David Relson
2010-01-14 16:17 ` Peter Stuge
2010-01-14 16:21 ` Relson, David
2010-01-14 16:29 ` Peter Stuge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100114025507.8044.qmail@stuge.se \
--to=peter@stuge.se \
--cc=gentoo-embedded@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox