RS-485 addressing

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

Translate This Thread From English to

Threaded View
Hello.

I want to understand how a 3-node, master/slave, half duplex, RS-485
network would work.  Specifically, how does addressing work under
RS-485?  Is there a spec which covers addressing?  Are there RS-485
chipsets which have built-in addressing support?  I have read the
RS-485 spec but it does not cover addressing.

Can someone direct me to a spec or a FAQ which covers this topic?  I
am familiar with RS-232 and CAN bus and MIL-STD-1553.

Thank you.

Re: RS-485 addressing
RS485 is just a Layer 1 specification that specifies signals
differential, half-duplex ....

RS485 does not know anything about addressing it is up to
protocol you choose like MODBUS or else...

Quoted text here. Click to load it



Re: RS-485 addressing

Quoted text here. Click to load it

Hi,

RS-485, as well as RS-422 or RS-232 are electrical specifications only. They say
nothing about transfer protocols, addressing or similar. You can use the well
known asynchronous protocol that's used by most PC or ÁC UARTs (often falsely
called "RS-232") or any other data transfer protocol you like. In every case you
have to send data in packets, containing a destination address and the payload
data. As on all multi drop busses, all devices on the bus are in listening mode
in idle state and only master devices can start a transmission. All devices
receive the packet from the master currently transmitting and decode the packet
address, but only the device that was addressed will react to the data, e.g by
send an answer.
As an example, some UARTs offer a 9-bit mode so if you use that protocol you can
take that bit to mark a byte as the device address. Often UARTs that support
9-bit transfers have a mode that generates a reception interrupt only if the
nineth bit in the received data word is set. Or you can define a minimum idle
time between packets after wich the first byte received is taken as the device
address. Not as secure as the nine bit method but you can connect a PC's UART
(via a RS232/RS485 converter) to that bus. Or you can use any other protocol you
like as long as it supports addressing  of devices and arbitration among
multiple masters, like CAN bus protocol, Ethernet or token passing protocols.

HTH,
Jens


Re: RS-485 addressing
Quoted text here. Click to load it

As noted above, many microcontrollers (PIC, 8051 to my knowledge, probably
others) have a 9-bit UART mode.  To use this all slaves on the bus listen to
data transmitted by the master for a byte with the 9th bit set to a 1.  This
signifies that the byte is an address not data.  The UART can be configured
so that when it receives such, it generates an interrupt.  If data is being
transmitted, it ignores it.

Once an address has been detected the Interrupt function in the slave must
check to see if it is its own address.  If not, it simply ignores it and
terminates immediately.  However, if the address is its own address,
subsequent data bytes (9th bit = 0) are received and processed.  You will
need to decide what constitutes the end of the data stream (specific end
byte, repeat of current address with bit 9 = 1, fixed data length etc).

The above means that several slaves can be attached to the bus, and none
(other than the addressed slave) will need to do any processing whilst data
is being transferred.  All processors will have a small amount of processing
when an address is transmitted.

If the master in such a system is a PC, you will have some considerable
difficulty in transmitting 9-bit data.  However, it is possible to send data
with a fixed (0 or 1) parity byte, which is effectively what is required.
Unfortunately controlling this under Windows is non-trivial.  Using a pre
written library, such as COMM-DRV from http://www.wcscnet.com/Software.htm
is to be recommended.




Re: RS-485 addressing
Quoted text here. Click to load it

Thanks for the lengthy response.  It helped to confirm some things I
suspected were true, but wasn't sure about.

Let me take the dialog in a slightly different direction:

Suppose I am the slave on a "network" of two embedded (not PC) nodes
connected together with half-duplex RS-485 running at 500Kbps

The master is going to send one fixed-length message packet every 20ms
(on average; see more on this later).  I am to send a response if and
only if I receive a valid (defined later) message packet from the
master.  I must start my response no later than 1 ms after the master
has completed transmission of the message packet.

Even though the average rate at which the message packets will be sent
by the master is one every 20ms, the precise time at which they arrive
can vary by as much as 10ms.

Within a message packet there are no gaps between the bytes.  Between
message packets there is always a time gap of at least 8ms.

A valid packet is one which a)has no time gaps between its bytes, b)is
preceded by a time gap of at least 8ms and followed a time gap of at
least 0.5ms, c)has the correct length, correct checksum, and no parity
or framing errors, and d)perhaps some other error checks.

The slave must be robust against packet errors.  For example, if for
some reason a message is received which is one byte short, the slave
should not think the first byte from the next packet is the last byte
of the short packet.  Instead, it should recognize the short packet
for what it is, and discard it, and successfully recognize the next
good packet.

The slave must run a very time-critical real-time task at 200Hz
controlling some external device, so it cannot afford to sit in a
high-speed polling loop examining the incoming data looking for
message packets.

I can solve the problem by adding a separate processor to monitor the
incoming byte stream, looking for the inter-message time gaps to
detect message packet boundaries.  The extra processor does all the
error checking, and when a valid message is received, it grabs the
necessary information from a buffer (stuffed by the main processor)
and sends a response.  Other than taking the usual precautions
necessary when two processors are running asynchronously and
exchanging data, this seems like a robust and straightforward
solution.

But the question is, is there an equally robust and straightforward
approach which does not require the additional processor?  I've
considered an event-driven approach, interrupting the main processor's
task whenever a byte is received, but this seems to suffer from at
least two significant drawbacks:  1) I need to detect the time gap at
the end of the incoming packet and this method does not seem
well-suited to that, and  2) I don't want a failure mode where a
"babbling" master (continuously spewing bytes) could cause my
real-time task to overrun.

Am I missing something or is the additional processor the best
solution even though it adds recurring cost and hardware complexity?

Re: RS-485 addressing

Quoted text here. Click to load it

[...]

Quoted text here. Click to load it

How about CAN?  Microchip has SPI interface CAN controllers for
$1.60 each.  You can use RS-485 drivers if you want...

--
Grant Edwards                   grante             Yow!  Can I have an IMPULSE
                                  at               ITEM instead?
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
Quoted text here. Click to load it

Sorry, I wasn't clear enough in my original posting.  What I meant was
"is there an equally robust and straightforward approach which does
not require the additional processor, subject to the constraints laid
out in the posting".  In other words, I have to work with what was
given.  I cannot change the behavior of the master.

Also, somebody told me (or maybe I read somewhere) that RS-485 is not
really well suited for CAN.  RS-485 drivers are designed to have one
transmitter active at a time.  Some of them can tolerate collisions,
but they are not designed to do so on a continuous basis.  Is that not
true?

Re: RS-485 addressing

Quoted text here. Click to load it

No.  There is, IMO, no way to do what you want with a normal UART.  You'll
have to dedicate a processor or some sort of FPGA or PLD to the
gap-detection task.

Quoted text here. Click to load it

Generally, yes.


I think they're spec'ed to tolerate indefinite short-circuit or miswiring,
but that's moot for the CAN bus usage.

To use them for CAN bus, you hard-wire the data inputs to one state (the
"dominant" state), and you use pull-up/down resistors to make the bus float
in the recessive state.  Then you drive the "enable" pin on the RS-485
driver with your TX data bit-stream.  You have multiple drivers active at a
time, but they're all in the same output state (dominant) so no worries. Now
that "real" CAN bus transceivers are available, there isn't any compelling
reason to do the RS-485 trickery, but it's an interesting hack.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
Quoted text here. Click to load it

Given a fast enough processor, it can be done IMO. When you program a
hardware timer to interrupt on overflow, you can relod load the timer each
time a character is received. When the timer expires, your gap has arrived.

Meindert



Re: RS-485 addressing

Quoted text here. Click to load it

That sounds a useful trick if you want to try to make a product that
can connect to a broad range of industrial busses, with a single
"universal" serial port. RS232/485/CAN.



--

John Devereux

Re: RS-485 addressing

Quoted text here. Click to load it

NB: I've never thried the above setup -- it's just something I've read
    about.  And I don't remember that anybody claimed the RS-485
    dominant/recessive scheme would inter-operate with a real CAN
    transceiver.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing

Quoted text here. Click to load it
The IX1 chip from M2C in Hamburg may still be available. It
is a fieldbus controller which can emulate (in software) any
serial protocol at up to 1 Mbps. Most implementation I have
seen had 8-pin sockets for the physical layer interface.

Stephen
--
Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
Quoted text here. Click to load it

OK.  I just wanted to make sure I wasn't missing something really
obvious before I made a fool of myself and questioned the approach
being proposed.

Quoted text here. Click to load it

Thanks for the detail.  I'm not a EE, but I think I get the gist of
what you're saying, and now it makes more sense to me.  I didn't
understand before how 485 could be used for this.  Is there a FAQ or a
technical article that you are aware of that goes into greater detail?
 For example, I'd like to understand how the bits are monitored for
arbitration in this scheme.

Thanks.

Re: RS-485 addressing
Quoted text here. Click to load it
     What is the problem with timestamping each subsequent received
byte? (This assumes each rec'd byte generates an interrupt). If the
difference is > 2ms, you declare a gap and discard the packet if
incomplete, etc. The only thing needed is a high enough resolution
system time (at least 1ms). The limiting factor will be how much
processing needs to be done after a valid packet, so that your real-time
task does not choke.


Re: RS-485 addressing

Quoted text here. Click to load it

You've obviously never tried this approach.  The problem is it
means you can't use an rx FIFO.  You have to service a receive
interrupt every 20 microseconds.  Go ahead, try to design a
system that can reliably service a 50KHz interrupt.

Quoted text here. Click to load it

An obviously unrealistic assumption.

Quoted text here. Click to load it

No, the limiting factor will be the 50KHz interrupt rate:
designing a system with less that 20us of interrupt
latency and an interrupt routine that can execute in a couple
microseconds.

The only way you can do that gap timing is in hardware.  You'll
need an FPGA.

I still say use CAN controllers.

--
Grant Edwards                   grante             Yow!  The PILLSBURY
                                  at               DOUGHBOY is CRYING for
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing

Quoted text here. Click to load it

    I've obviously used this approach, on a UART that had no FIFO
(8251A). There was no other way to service that. True, the BAUD rate was
much lower ;)


Quoted text here. Click to load it
     The OP didn't mention what CPU he'll be using, or what RTOS, if
any. _I_ could design a system to service that, YMMV.

Quoted text here. Click to load it
     That depends on who is doing the assuming ;)

Quoted text here. Click to load it
     Not the only, but it sounds like a nice and easy way out.


Re: RS-485 addressing

Quoted text here. Click to load it

IIRC, the MC68302 can get the bytes silently into internal ram and
give you an interrupt after something like 3 bit idle. If you are
using UART mode, of course. No need to track single chars.

Andreas
--
Good judgment comes from experience.  Unfortunately, the experience
usually comes from bad judgment.


Re: RS-485 addressing
Quoted text here. Click to load it

If I wait for the first byte of the next packet to generate an
interrupt and then detect the time gap, it's too late.  The time gap
between packets can be well over 10ms.  I'm supposed to start
responding to the packet within 1ms of receiving the last byte of the
packet.

[snip]

Re: RS-485 addressing

Quoted text here. Click to load it
     No, you will respond right after the last byte of a correct packet
has been received, on the interrupt it (the last byte) generates. The
wait will be only if the packet is incomplete for some reason, and then
you can safely discard it (the partial packet) on the first rec'd byte
after the gap.


Re: RS-485 addressing
Quoted text here. Click to load it

The problem is, I don't know if it's the last byte until I detect a
time gap after it.  Maybe I'm not understanding what you are saying.


Quoted text here. Click to load it

Site Timeline