RE: [gentoo-embedded] serial port handling question

["Peter Bell" <pbell@ink-media.com>]

RS485 is a half-duplex bus, so this looks like a transmit enable rather than
flow control - and generally the transmit enable timing is quite critical,
since you have to leave it asserted until the last bit is sent from the UART
(so the normal "interrupt of THRE or FIFO low" is useless - you have to use
a TDRE interrupt), and then needs to be very quickly turned around before
the addressed device comes back with it's response.

If you don't want to bitbash the control registers in userland you are just
going to have to add a special mode to the driver, I'm afraid - none of the
RS485 implementations I've ever seen will work correctly using the flow
control semantics that the kernel implements.

Pete
-----Original Message-----
From: Peter Stuge [mailto:peter@stuge.se] 
Sent: Thursday, January 14, 2010 1:08 PM
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] serial port handling question

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
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4770 (20100114) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com