RS485 Communications

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
standard RS232 comm port routines to talk to devices on the rs485 network by
using a 232 > 485 convertor and everything worked great.  Now, however, I
want to use the onboard 485 ports.  I have two questions....

1, my port is a 4 wire, my network is a 2 wire.  This is how I converted.
+TX & +RX Tied together,  -TX & - RX Tied together.    The -TX & -RX hook to
A on the Network, and the +TX & + RX hook to B on the network.  Is this

2.  In my standard Rs232 Routines, I modified to simply Raise RTS, wait 10
ms, then then the string, wait 10ms, lower RTS.
     I don't do anything special at all waiting on chars to arrive.

Problem is, none of this works.  Any pointers?  I assume I can use the
standard Serial Port Routines if I turn off  All flowcontrol and use the RTS
line right?

I find tons of info on the difference in the specs, but not much about
writing to the ports.


Re: RS485 Communications

Quoted text here. Click to load it

At least there has to be a jumper / control bit determining which of the
incoming data buffers is connected to the UART receiver: you cannot feed it
from RS-232 and RS-485 buffers at the same time. The feature is not standard
on a PC serial port, it could be using the extra output bits present on
8250 -series interface chips. Go after the hardware documentation / vendor
for details.


Tauno Voipio
tauno voipio @ iki fi

Re: RS485 Communications says...
Quoted text here. Click to load it

This is why the chief engineer had someone invent oscilloscopes!

1.  10mSec seems like a long delay after transmission.  What is the
baud rate?   You should normally delay only about one character time
after the end of a transmission to switch to receive.   This is
especially true if your device is a system master.  At faster baud
rates,  some devices my have completed their response in 10mSec.
2.  Get a scope and make sure your data is actually being transmitted.
Then see if you can find any responses.
Quoted text here. Click to load it

Then verify the settings with the oscilloscope!  ;-)

Mark Borgerson

Re: RS485 Communications
Got it, Actually after writing this email I broke out the storage scope and
checked it.  Since the RS485 is Com4, IRQ 10 the IRQ Vector was set wrong.
Once I fixed that, I simply use the RTS before sending data and she worked

I just has so many new items I was testing so I had to narrow the problem
down and the trusty Oscope let me know where the problem was.  Again, Thanks
for the help.


Quoted text here. Click to load it
however, I
wait 10

Re: RS485 Communications
Quoted text here. Click to load it

Although I don't know much about RS85 and I don't know the pinout of the
onboard port in RS485 mode, I've had the same problems with ADVANTECH
hardware, trying to talk to industrial I/O ADAM modules from a SBC
motherboard (in the "embedded" product line), by switching the direction
using RTS too (and the RTS toggle mode that sets automatically RTS during a
write operation).
By calling their technical support they explained me that the RS485 ports on
their motherboards don't fully support RS485, especially the automatic
detection of receiving data, a functionality required to communicate with
most RS485-compliant devices.
Then I guess that RTS is unable to switch early enough the line in receive
mode, causing incoming data loss.
The only solution we found was either to buy an extension card with real
RS485 ports, or to use a RS232<-->RS485 adapter like you did.

Quoted text here. Click to load it

I hope it did help you.

Thierry C.

Re: RS485 Communications
Yes, this was an Advantech board.  I fixed it by doing the following:
1st - fixed the IRQ Vector problem  - I was using the wrong value for the
non-standard port.
2nd - Using standard RS232 Comm Routines however I turned off all the port
options (required for modems)
3rd - I simply switch the RTS before sending data, then switch it back
immediately after the send buffer is clear.

I'm communicating okay at 38,400 using Modbus RTU (4 wire to 2 wire setup).
I never used 485 before beside with an 232 to 485 adapter so I wasn't sure
what to expect.


Quoted text here. Click to load it

Re: RS485 Communications

Quoted text here. Click to load it

Try to invert the A & B connection.

I belive that +TX & +RX are to be considered like the A channel. -TX & -RX
are the B channel.

Good luck.

Re: RS485 Communications
Quoted text here. Click to load it

No. TX/RX+ is A and TX-/RX- is B


Re: RS485 Communications
Quoted text here. Click to load it

If your network is (i.e. MUST BE) 2 wire, then yes.  :>

Quoted text here. Click to load it

Presumably, the 232-485 converter used RTS as a "direction control"
(typical).  As such, it caused the 485 transceiver to "drive* the network
when you were "transmitting" data, etc.

Since you don't explicitly mention *discarding* and/or *checking* the
data RECEIVED while transmitting (i.e. a copy of YOUR outgoing data),
I assume the 232-485 converter disabled the 485 receiver while

You've not mentioned the protocol you are using to govern/arbitrate
access to the network so there are big issues unstated...

The first 10ms (before Tx) is probably overkill.  You just need to wait
long enough for the 485 transceiver to "flip" to Tx mode.  The *second*
10ms may be too small (unlikely since you haven't complained about
data being "clipped"), just right, or too long.

Essentially, you want to wait for the last character to *clear* the
portion of the UART before twiddling RTS.  Note that this is usually
one (or more!) "character times" (i.e. 10 or 11 times the "bit time")
AFTER the last "transmit register empty" interrupt.  It depends on the UART
being used (how deep the transmit buffer is, etc.) as well as your actual
bit rate.

Using a fixed "10 ms" may (does?!) work for your current conditions.
But, moving to a slower bit rate, different UART or even changes in
the network cabling can cause that fixed delay to become inadequate
at some future date.

You want to make sure the last bit of the last character transmitted
has cleared the "TxD" pin on the UART *and* had a chance to
propagate through the network (cable length and potential reflections
if improperly terminated) before turning off the transmitter (via RTS)
and relinquishing the wire to other potential masters (transmitting nodes)

Make sure you have terminated the network properly...

Quoted text here. Click to load it

Depends on what the 485 ports on your board are wired as.  You haven't
said if they are the same UARTs that you have been using with 232
(i.e. just some jumpers to handle the 232/485 strapping option) or if they
are implemented with different physical devices entirely, etc.

The vendor/documentation should be able to tell you what controls
the transmitter ("direction") in the 485 transceiver (i.e. RTS, or some
other mechanism).  Your protocol choices will also affect how and
when you drive the wire -- as well as how you respond to activity
*on* the wire (e.g., resolve contention, etc.)

Your vendor may, also, provide sample routines describing how they
*suggest* that you use the ports (though they may be highly simplified
and/or not optimized nor applicable to your particular protocol).  But,
a good place to *start*!

Quoted text here. Click to load it


N.B. Incoming mail is not accepted at this email address.

Re: RS485 Communications

Quoted text here. Click to load it

You may have A/B backwards.  I've used RS-485 for 15 years, and
still can't remember if its A==+ B==- or the other way around.

Quoted text here. Click to load it

Try swapping A/B.

Quoted text here. Click to load it

Maybe.  It depends on how your RS-485 port is wired.  Is RTS
used to enable the drivers?

Quoted text here. Click to load it


Grant Edwards                   grante             Yow!  I will SHAVE and
                                  at               buy JELL-O and bring my
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485 Communications
Quoted text here. Click to load it

Sounds right.  What about the '485 line termination and bias
resistors?  Do you have a separate ground to control the common
mode?  Check the quiescent (no signal, DC) conditions on the line.

Chuck F ( (
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: It's fixed, Thanks
IRQ Vector Issue on the Non-Standard Port.  Tracked it down using the Oscope
and found NO Data was going out.

Thanks again for everyones help.

Quoted text here. Click to load it

Site Timeline