I think this might be a useful place to post this...hope so.

I am running Linux (kernel 2.6.9) and need to talk out the serial port.
The catch is I need to send data out the serial port, but before any
data is sent, I need to assert the RTS line, then after the data is
send (and buffer actually empty) de-assert the RTS line and then the
responses will come from the 4 remote RS485 boards I'm talking to.

Another catch is I need the RTS line un-asserted quickly after we are
done with the last character. By quickly about 2 ms or less.

I believe I can control the RTS line with ioctl() and such, but I don't
think there is any guarantee on when Linux will get around to doing
that function call, and if I'm on the bus too long, then I miss the
data coming back, since the remote devices will be tx-ing back yet I'm
still on the bus.

I have found lots of good information about this exact problem, but all
from '94-'99, and the files which were modified aren't even named the
same in recent distos. I am using Gentoo Linux, if that matters.

I think if I just tell the serial port I want to use hardware (RTS/CTS)
flow control then that should be ok, I'll have to pull CTS up when RTS
goes up but I can easily do that (wire the two together), but I think
the decision/timing about RTS needs to be done at a lower level than
just user-space code.

Any ideas/hints would be greatly appreciated!!
Thanks,
Mark Brodis

mabrodis [at] scream [dot] com

fj40rockcrawler@gmail.com wrote:
You can change the RTS-line, but it cannot be *guaranteed* to be done
within 2ms, 1s, 1h, or whatever time limit.

Of course there is a guarantee. ioctl() is a systemcall.
If you call it, it gets called.

Some of the #defines for the iocntls may have been changed since then, IIRC.

You are confused. You *can* control the voltage on the lines from
userspace. the ioctl() is your interface.
Maybe you don't even *need* to control the lines yourself, but let the
terminaldriver do it for you.

HTH,
AvK

moi wrote:
I doubt that will work. Note the 2 ms spec, which is probably not
taut enough. He seems to be using the RTS as a control to turn the
RS485 line direction around. The RTS really needs to be tied to a
UART line specifing the emptyness of the transmit buffer. This
often doesn't exist.

A dirty solution is to bias the '485 lines appropriately, and only
turn on the transmit connection drivers on a 0 bit, which includes
the start bit. This preserves the differential receivers, but
abandons the differential drivers. No specific turn around needed.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson