| 1 |
RS485 is a half-duplex bus, so this looks like a transmit enable rather than |
| 2 |
flow control - and generally the transmit enable timing is quite critical, |
| 3 |
since you have to leave it asserted until the last bit is sent from the UART |
| 4 |
(so the normal "interrupt of THRE or FIFO low" is useless - you have to use |
| 5 |
a TDRE interrupt), and then needs to be very quickly turned around before |
| 6 |
the addressed device comes back with it's response. |
| 7 |
|
| 8 |
If you don't want to bitbash the control registers in userland you are just |
| 9 |
going to have to add a special mode to the driver, I'm afraid - none of the |
| 10 |
RS485 implementations I've ever seen will work correctly using the flow |
| 11 |
control semantics that the kernel implements. |
| 12 |
|
| 13 |
Pete |
| 14 |
-----Original Message----- |
| 15 |
From: Peter Stuge [mailto:peter@×××××.se] |
| 16 |
Sent: Thursday, January 14, 2010 1:08 PM |
| 17 |
To: gentoo-embedded@l.g.o |
| 18 |
Subject: Re: [gentoo-embedded] serial port handling question |
| 19 |
|
| 20 |
David Relson wrote: |
| 21 |
> > > The sensor is controlled (in part) by setting RTS on and off. |
| 22 |
> > |
| 23 |
> > What is controlled, exactly? What is RTS being used for? If it is |
| 24 |
> > indeed flow control then you are lucky and can simply enable |
| 25 |
> > hardware flow control for the serial port, and Linux will then |
| 26 |
> > take care of everything for you. |
| 27 |
> |
| 28 |
> Not sure (insufficient documentation). The functions setting and |
| 29 |
> clearing RTS have names like RS485_RTS_Receiver_Enable and |
| 30 |
> RS485_RTS_Transmitter_Enable. |
| 31 |
|
| 32 |
That definately suggests that RTS/CTS would be used for flow control. |
| 33 |
|
| 34 |
|
| 35 |
> My query as to the meaning/purpose of the routines is awaiting an |
| 36 |
> answer.. |
| 37 |
|
| 38 |
Hopefully they will confirm that it's for flow control. |
| 39 |
|
| 40 |
Then you can simply ignore everything related to RTS, as Linux will |
| 41 |
take care of it for you. Just read from the opened tty device and |
| 42 |
you'll get data when there is some. Linux also buffers writes, so if |
| 43 |
a write() call succeeds then data will eventually go out on the port. |
| 44 |
|
| 45 |
|
| 46 |
> The RS485 routines mentionned above only change RTS. DTR remains on. |
| 47 |
> Attempts to change both (using CRTSCTS and tcsetattr()) didn't work. |
| 48 |
|
| 49 |
With tcsetattr() you'd use B0 in the CBAUD field to unset both |
| 50 |
signals, and any B value other than B0 to set them. You can use |
| 51 |
cfsetispeed() and cfsetospeed() to conveniently change only the |
| 52 |
baudrate in a struct termios, but since it will also affect DTR I |
| 53 |
don't think that this will work. |
| 54 |
|
| 55 |
|
| 56 |
> I'm well aware of the hackish nature of my "solution". |
| 57 |
|
| 58 |
What happens if you remove the code that touches the registers and |
| 59 |
simply let Linux handle flow control? I suspect you could remove some |
| 60 |
of the code surrounding the outb() calls as well, since the Linux |
| 61 |
serial layer implements very thorough flow control. |
| 62 |
|
| 63 |
|
| 64 |
> It'll be interesting to see what unwanted side effects show up to |
| 65 |
> bite me. |
| 66 |
|
| 67 |
Unfortunately the problems may not show up until far into the future, |
| 68 |
with lots of installations possibly out in the field.. |
| 69 |
|
| 70 |
|
| 71 |
//Peter |
| 72 |
|
| 73 |
|
| 74 |
__________ Information from ESET NOD32 Antivirus, version of virus signature |
| 75 |
database 4770 (20100114) __________ |
| 76 |
|
| 77 |
The message was checked by ESET NOD32 Antivirus. |
| 78 |
|
| 79 |
http://www.eset.com |
Archives