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...

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

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

is to be recommended.

As a previous poster has intimated that such serial standard is the hardware layer.

It is only a suggestion but why don't you implement a UDP scheme since the header has all the information you require to sent a small packet from one device to another? It has source and destination addresses, no of bytes. I think only the header has a checksum but you can ignore this if you wish. At least it is a recognised standard which anyone associated with networks will know. It also doesn't require any unusual features such as having an extra data bit. For instance, the Rabbit 2000 can't even cope properly with

8 bits data and parity. Only a suggestion!

As the others say or imply, you are pretty much on your own.

If you send me an email and convince me this isn't a homework assignment, I can send you portions of a spec we have used. It will work on any processor with either RS-485 or RS-232 and does not require 9-bit capability.

Scott

However you want it to. RS-485 is a physical layer spec that states things like volts and milliamps and ohms.

No. You can impliment any number of protocols, all of which use different addressing methods.

No.

Then you already know that RS-485 doesn't define any addressing.

You can run CAN bus'es MAC layer on RS-485 if you want.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                               visi.com

As others has pointed out, RS485 just defines physical interface. Others have proposed some solutions based on some UART's capabilities (that 9 bit scheme I mean). I used RS485 in a three pairs (one for data, two for handshake) multi-drop poll select scheme and implemented a fairly complex protocol on top of it. If I were to design it today, I would use SDLC and an 82C30 (or some more modern similar). The real solution will depend on how robust your system has to be.

Regards.

Elder.

Have look at:

Regards Zoran

Thanks for all the responses. It was just what I needed.

Your responses confirmed what I already thought to be the case, but what I lacked was specific experience with RS-485, and thought maybe I was missing something obvious. Guess not.

I love the usenet community.

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?

[...]

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?
                               visi.com

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.

--- clip clip ---

Please *do not* base your packet framing on time gaps between characters in a message transferred on an asynchronous interface (like Modbus binary format). It's nearly impossible to stick to the spec in a PC (especially if it's running Windows of any flavour).

Use a flag byte based scheme instead - like that of PPP in HDLC-like framing (RFC 1662, part 4, Octet-stuffed Framing).

Been bitten by Modbus framing.

HTH

Tauno Voipio tauno voipio @ iki fi

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.

An obviously unrealistic assumption.

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
                               visi.com            an END to BURT REYNOLDS
                                                   movies!!

Me too. The only way to do it is with an interrupt on _every_ rx byte. At high baud rates, that sucks royally. The whole gap-timing debacle made ASCII modbus look like a good design -- at least there was a unique delimiter byte.

--
Grant Edwards                   grante             Yow!  You were s'posed
                                  at               to laugh!
                               visi.com

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?

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.

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??
                               visi.com

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]

You could use a periodic timer interrupt to look at your receive data buffer. If the amount of data in it is less than or equal to the last time the ISR ran, there's gap. In that case, read any data remaining in the uart receive fifo into your buffer. Then check the message to see if it is valid, and reply if it is. The timer interval must be less than 1 msec and greater than 500 usec plus the number of bytes in the receive fifo times the transmission time per byte.

Jim McGinnis