Re: [gentoo-embedded] serial port handling question

[Peter Stuge <peter@stuge.se>]

David Relson wrote:
> > > 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.

That definately suggests that RTS/CTS would be used for flow control.


> My query as to the meaning/purpose of the routines is awaiting an
> answer..

Hopefully they will confirm that it's for flow control.

Then you can simply ignore everything related to RTS, as Linux will
take care of it for you. Just read from the opened tty device and
you'll get data when there is some. Linux also buffers writes, so if
a write() call succeeds then data will eventually go out on the port.


> The RS485 routines mentionned above only change RTS.  DTR remains on.
> Attempts to change both (using CRTSCTS and tcsetattr()) didn't work.

With tcsetattr() you'd use B0 in the CBAUD field to unset both
signals, and any B value other than B0 to set them. You can use
cfsetispeed() and cfsetospeed() to conveniently change only the
baudrate in a struct termios, but since it will also affect DTR I
don't think that this will work.


> I'm well aware of the hackish nature of my "solution".

What happens if you remove the code that touches the registers and
simply let Linux handle flow control? I suspect you could remove some
of the code surrounding the outb() calls as well, since the Linux
serial layer implements very thorough flow control.


> It'll be interesting to see what unwanted side effects show up to
> bite me.

Unfortunately the problems may not show up until far into the future,
with lots of installations possibly out in the field..


//Peter