1 |
On Thu, 14 Jan 2010 03:55:07 +0100 |
2 |
Peter Stuge wrote: |
3 |
|
4 |
> David Relson wrote: |
5 |
> > I'm porting some old DOS code to Linux for a medical device that is |
6 |
> > being upgraded. |
7 |
> |
8 |
> Interesting, this business. |
9 |
|
10 |
And it feels so good when one stops banging one's head against the wall. |
11 |
|
12 |
|
13 |
> > The sensor is controlled (in part) by setting RTS on and off. |
14 |
> |
15 |
> What is controlled, exactly? What is RTS being used for? If it is |
16 |
> indeed flow control then you are lucky and can simply enable hardware |
17 |
> flow control for the serial port, and Linux will then take care of |
18 |
> everything for you. |
19 |
|
20 |
Not sure (insufficient documentation). The functions setting and |
21 |
clearing RTS have names like RS485_RTS_Receiver_Enable and |
22 |
RS485_RTS_Transmitter_Enable. My query as to the meaning/purpose of |
23 |
the routines is awaiting an answer.. |
24 |
|
25 |
> If not flow control and some other signalling, you have to write a |
26 |
> line discipline driver. I have done both this and serial drivers |
27 |
> (also related to DOS era equipment) and documentation is not the |
28 |
> greatest. Let me know if you would like some help. |
29 |
> |
30 |
> |
31 |
> > I looked high and low (pun intended) for an ioctl or similar call |
32 |
> > that would allow this level of control and couldn't find anything. |
33 |
> |
34 |
> The best thing out there is tcsetattr() and friends. |
35 |
> |
36 |
> By switching between baud rate 0 and something else you can reliably |
37 |
> and easily control both RTS and DTR, and nothing but RTS and DTR, but |
38 |
> always both at the same time. |
39 |
|
40 |
The RS485 routines mentionned above only change RTS. DTR remains on. |
41 |
Attempts to change both (using CRTSCTS and tcsetattr()) didn't work. |
42 |
|
43 |
> Line disciplines can call the tty_throttle() and tty_unthrottle() |
44 |
> functions in the serial driver, which will then control RTS |
45 |
> accordingly, but the default TTY line discipline does not expose any |
46 |
> API that will result in throttle function calls. |
47 |
> |
48 |
> > outb(inportb(MCR) | 0x02, MCR); //DTR,RTS=ON |
49 |
> > outb(inportb(MCR) & ~0x02, MCR); //DTR=ON,RTS=OFF |
50 |
> > |
51 |
> > Directly tweaking the I/O port runs against the grain, but it's the |
52 |
> > only thing I've found that works. |
53 |
> |
54 |
> Not only against the grain, it can mess up internal state in the |
55 |
> kernel serial layer and worst case lead to a kernel BUG_ON (kernel |
56 |
> hangs) or best case serial port hang (unhang e.g. by closing all file |
57 |
> handles for the port and opening again). It is not at all nice to |
58 |
> change these signals behind Linux' back. |
59 |
|
60 |
I'm well aware of the hackish nature of my "solution". It'll be |
61 |
interesting to see what unwanted side effects show up to bite me. |
62 |
|
63 |
David |