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:[email protected]] Sent: Thursday, January 14, 2010 1:08 PM To: [email protected] 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
