serial port handling question
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.