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
