From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-embedded+bounces-3321-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1NVHMK-0000B3-Qf
	for garchives@archives.gentoo.org; Thu, 14 Jan 2010 04:31:01 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id C5515E0439;
	Thu, 14 Jan 2010 04:30:31 +0000 (UTC)
Received: from mail.osagesoftware.com (osagesoftware.com [216.144.204.42])
	by pigeon.gentoo.org (Postfix) with ESMTP id 7B103E09F1
	for <gentoo-embedded@lists.gentoo.org>; Thu, 14 Jan 2010 04:30:31 +0000 (UTC)
Received: from osage.osagesoftware.com (osage.osagesoftware.com [192.168.1.10])
	by mail.osagesoftware.com (Postfix) with ESMTP id 086287BC52
	for <gentoo-embedded@lists.gentoo.org>; Wed, 13 Jan 2010 23:30:31 -0500 (EST)
Date: Wed, 13 Jan 2010 23:30:30 -0500
From: David Relson <relson@osagesoftware.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] serial port handling question
Message-ID: <20100113233030.21b059e8@osage.osagesoftware.com>
In-Reply-To: <20100114025507.8044.qmail@stuge.se>
References: <20100113185240.4bc9d721@osage.osagesoftware.com>
	<20100114025507.8044.qmail@stuge.se>
Organization: Osage Software Systems, Inc.
X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-embedded@lists.gentoo.org>
List-Help: <mailto:gentoo-embedded+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-embedded+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-embedded+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-embedded.gentoo.org>
X-BeenThere: gentoo-embedded@lists.gentoo.org
Reply-to: gentoo-embedded@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 6e986222-a94a-4e84-98f7-6a726eb794d3
X-Archives-Hash: 2ec0ded33bf4b6803779a98651932a7e

On Thu, 14 Jan 2010 03:55:07 +0100
Peter Stuge wrote:

> David Relson wrote:
> > I'm porting some old DOS code to Linux for a medical device that is
> > being upgraded.
> 
> Interesting, this business.

And it feels so good when one stops banging one's head against the wall.


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

Not sure (insufficient documentation).  The functions setting and
clearing RTS have names like RS485_RTS_Receiver_Enable and
RS485_RTS_Transmitter_Enable.  My query as to the meaning/purpose of
the routines is awaiting an answer..
 
> 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.

The RS485 routines mentionned above only change RTS.  DTR remains on.
Attempts to change both (using CRTSCTS and tcsetattr()) didn't work.
 
> 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.

I'm well aware of the hackish nature of my "solution".  It'll be
interesting to see what unwanted side effects show up to bite me.

David