Implementing communication over RS-485

Hello,

I need to implement a proprietary network of various devices connected
over the RS-485. No third party device needs to be interfaced, all the
devices will contain the firmware written by me.

1. Is there any specification which tells me how the devices can be
addressed over the network and messages can be accepted by them ? Also,
are there any error correction methods recommendable for this network.

2. I have read that may be ModBus protocol could be used. Can I
communicate directly to the RS-232 send and receive routines from the
Modbus module or do I need more layers of software in between ?

Please help.

Thanks and regards,
Mehul

mehulag wrote:
> Hello,
>
> I need to implement a proprietary network of various devices connected
> over the RS-485. No third party device needs to be interfaced, all the
> devices will contain the firmware written by me.
>
> 1. Is there any specification which tells me how the devices can be
> addressed over the network and messages can be accepted by them ? Also,
> are there any error correction methods recommendable for this network.
>
> 2. I have read that may be ModBus protocol could be used. Can I
> communicate directly to the RS-232 send and receive routines from the
> Modbus module or do I need more layers of software in between ?

I can't tell you if the ModBus protocol will work for you or how many
layers you need.  You have not defined your requirements at all.  But I
can tell you that one fundamental difficulty in working with RS-485 or
any half duplex protocol is knowing when the bus is free.

I once worked on an RS-485 bus where the designer of the bus did a poor
job of defining how to turn the bus around.  The result was that there
were collision problems.  Typical UARTs will tell you that the buffer
register is empty (useless for this purpose) or that the transmit
register is empty (the stop bit is still being timed) but they won't
tell you when the stop bit has finished timing out.  So most systems
have to use timers and other means external to the UART to control the
transmit/receive output to the driver chip.

There are a few MCUs with UARTs that can directly control the RS-485
driver enable.  Be sure to use one of these.  The slave will also have
to pad at least a bit time to make sure it does not turn on its driver
before the master has disabled its driver.  This is purely a software
issue.

"mehulag" <mehul@hcl.in> wrote in message 
news:CNSdnRtzmY80Pp_YnZ2dnUVZ_rCdnZ2d@giganews.com...
> Hello,
>
> I need to implement a proprietary network of various devices connected
> over the RS-485. No third party device needs to be interfaced, all the
> devices will contain the firmware written by me.
>
> 1. Is there any specification which tells me how the devices can be
> addressed over the network and messages can be accepted by them ? Also,
> are there any error correction methods recommendable for this network.

There is no specification as such; how you use it is up to you. However a 
typical scenario would be as follows:

 - Each device on the bus has an address in the range 1-32 (typically set in 
hardware with e.g. DIP switches or a rotary switch - or in Flash so long as 
you have a means of setting the address before connecting to the bus).

 - Each transmission from the master includes the device address as part of 
the packet. Each device checks the address, and responds only to its own 
address. (You could also have a broadcast mode if you need it, so long as 
none of the devices are expected to reply.)

 - The architecture is master/slave; i.e. all comms are initiated by the 
master, and slaves respond only to messages addressed to them.

 - All messages include a checksum or CRC field to allow error-detection 
(not necessarily correction). You could either allow for a NAK-type 
response, or simply timeout (assuming the master will retry).

> 2. I have read that may be ModBus protocol could be used. Can I
> communicate directly to the RS-232 send and receive routines from the
> Modbus module or do I need more layers of software in between ?

Sorry, I don't know. Bear in mind that RS-485 differs from RS-232 in that 
you need to take care of releasing the bus (i.e. enabling/disabling the 
transmitters). The above scenario is effectively half-duplex, so you could 
use either the usual 3-wire RS-485 or the 5-wire variant a la RS-422 (but 
still using RS-485 transceivers - they're superior to RS-422 devices in all 
respects).

(I have used Modbus over RS-485, but it was too long ago to remember the 
details...)

HTH some,

Steve
http://www.fivetrees.com 

In article <072dnaUtQIQmJp_YnZ2dnUVZ8smdnZ2d@pipex.net>, 
steve@NOSPAMTAfivetrees.com says...
> "mehulag" <mehul@hcl.in> wrote in message 
> news:CNSdnRtzmY80Pp_YnZ2dnUVZ_rCdnZ2d@giganews.com...
> > Hello,
> >
> > I need to implement a proprietary network of various devices connected
> > over the RS-485. No third party device needs to be interfaced, all the
> > devices will contain the firmware written by me.
> >
> > 1. Is there any specification which tells me how the devices can be
> > addressed over the network and messages can be accepted by them ? Also,
> > are there any error correction methods recommendable for this network.
> 
> There is no specification as such; how you use it is up to you. However a 
> typical scenario would be as follows:
> 
>  - Each device on the bus has an address in the range 1-32 (typically set in 
> hardware with e.g. DIP switches or a rotary switch - or in Flash so long as 
> you have a means of setting the address before connecting to the bus).

Please note that there are several "fractional load" transceivers on the 
market which allows over 100 devices to safely co-exist on an RS-485 
network, so an addressing scheme should accomodate that...

--Gene
 

mehulag wrote:
> Hello,
>
> I need to implement a proprietary network of various devices connected
> over the RS-485. No third party device needs to be interfaced, all the
> devices will contain the firmware written by me.
>
> 1. Is there any specification which tells me how the devices can be
> addressed over the network and messages can be accepted by them ? Also,
> are there any error correction methods recommendable for this network.
>
> 2. I have read that may be ModBus protocol could be used. Can I
> communicate directly to the RS-232 send and receive routines from the
> Modbus module or do I need more layers of software in between ?

Yes, ModBus is a workable solution.  You will need to be able to sense
when the last bit of a message has been sent so you can switch the
transmitting device over to receive mode.  In the past I have done
RS-485 ModBus using a variant of the 16550 serial device which could
generate an interrupt on "last bit sent".  It all worked just fine.

"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:1157811417.323232.68980@b28g2000cwb.googlegroups.com...
> Yes, ModBus is a workable solution.

You must be joking. A protocol that relies on inter-frame times for
delimiting the frames is a major PITA.
It is much easier to either use escapes for frame delimiters or a 9th bit to
flag an address- and end-of-frame byte. Most controllers offer a 9 bit
scenario and often with automatic address recognition as well.

Forget ModBus. Period.

Meindert

Meindert Sprang wrote:
> "Mike Silva" <snarflemike@yahoo.com> wrote in message
> news:1157811417.323232.68980@b28g2000cwb.googlegroups.com...
> > Yes, ModBus is a workable solution.
>
> You must be joking.

No, my jokes are funnier.

>A protocol that relies on inter-frame times for
> delimiting the frames is a major PITA.

This was quite simple to implement, using an available onboard timer.
Not even close to "major PITA".

> It is much easier to either use escapes for frame delimiters or a 9th bit to
> flag an address- and end-of-frame byte. Most controllers offer a 9 bit
> scenario and often with automatic address recognition as well.
>
> Forget ModBus. Period.

The OP asked about ModBus.  It's a workable solution.  There are also
other workable solutions.

"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:1157813165.393601.102470@p79g2000cwp.googlegroups.com...
> >A protocol that relies on inter-frame times for
> > delimiting the frames is a major PITA.
>
> This was quite simple to implement, using an available onboard timer.
> Not even close to "major PITA".

It costs you bandwith and it is almost impossible to implement on a UART
with a fifo.
And it costs a timer.

Meindert

On Sat, 9 Sep 2006 16:25:05 +0200, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:

>"Mike Silva" <snarflemike@yahoo.com> wrote in message
>news:1157811417.323232.68980@b28g2000cwb.googlegroups.com...
>> Yes, ModBus is a workable solution.
>
>You must be joking. A protocol that relies on inter-frame times for
>delimiting the frames is a major PITA.

It is not that bad. Point to point connections using RS-232/422
connections can be easily implemented by just monitoring the contents
of the message. The traffic is half duplex after all.

The multidrop master can also be implemented this way, however, when
using the stupid 16550 UART series, you really have to poll the Tx
shift register empty bit before turning off the RS-485 transmitter. 

Slaves in a multidrop network with inaccurate pause detecting will
communicate reliably, as long as the master communicates with the same
slave using multiple transactions.  However, when the last response
from slave 1 is transmitted and then the master starts to send the
next command to slave 2, if slave 2 does not detect the pause between
response from 1 and the next command to slave 2, it will not detect
the command addressed to it. However, the master will timeout and send
the command again. This kind of problems with some slaves can be
avoided, if the master exaggerates the pause before sending the next
command to a new slave.

Some Motorola/Freescale processors contain the QUICC I/O processor,
which has a nice Rx idle timeout interrupt feature and it is quite
easy to get nearly perfect pause timing with it.
  
>It is much easier to either use escapes for frame delimiters or a 9th bit to
>flag an address- and end-of-frame byte. Most controllers offer a 9 bit
>scenario and often with automatic address recognition as well.

The 9 bit system is a mess, if you want to monitor the traffic on a
typical PC hardware or communicate with such networks. On simple 5-8
bit UARTs, you would have to fiddle with the odd/even parity setting
on a character by character basis, to select the parity bit in such a
way that you get the wanted 0 or 1 into the parity bit i.e.
address/data bit. On receive, you would have to detect the parity
error on a character by character basis, thus making both the Tx and
Rx FIFO useless. Since most UARTs have a common parity for Rx and Tx,
full duplex operation would be unthinkable.

Paul
 

Meindert Sprang wrote:
> "Mike Silva" <snarflemike@yahoo.com> wrote in message
> news:1157813165.393601.102470@p79g2000cwp.googlegroups.com...
> > >A protocol that relies on inter-frame times for
> > > delimiting the frames is a major PITA.
> >
> > This was quite simple to implement, using an available onboard timer.
> > Not even close to "major PITA".
>
> It costs you bandwith and it is almost impossible to implement on a UART
> with a fifo.
> And it costs a timer.

Well I have no strong feelings either way about ModBus.  The product
demanded it so I implemented it.  Having said that, the bandwidth loss
was maybe one or a few percent with our typical message sizes.  The
timer was free (not otherwise being used) on our micro.  And the
processing overhead to deal with the timeout processing on each
received character was maybe a microsecond.

Which is just to say (for the OP's edification) that none of these
issues are deal-killers.  Any serial protocol has to deal with (devote
HW and/or SW to) the same issues such as what signals a new message,
where is the end of the message, and is it a valid message?