RS485, multidrop protocol

I wonder if there is documentation on standard RS485 protocols
anywhere for download?

I have homebrewed a couple of these in the past but is there a
standard way of doing this?

I am interested in using the serial port of a linux machine, with
RS485 line drivers/receivers and probably RTS control to effectively
network a number of machines together. 

Two possible applications spring to mind, my own custom (udp) system
or trying to get TCP/IP sort of working, NFS or TFTP booting for
example, I'd accept atrocious performance just for the convenience of
it all. typically only a pair would be busy at once...

The SLIP and PPP protocols are not multidrop of course. 

It may be possible to modify a TCP driver to provide a ALOHA type
connection ( there being no "collision dectect" on a simple system) 

It may be possible to encode data so that 8 bits gets transmitted as
16 (20 actually if you include stop/start). E.g send each bit as a
dibit, 01 or 10. Then arrange to pad the line and use a token passing
mechanism so that each machine only transmits when the line is quiet.
I could even add hardware to provide a "sort of " collision detect but
it all seems a bit complicated.

There may be implementations already done... was localtalk rs485? (
old apple) or maybe versions of modbus, profibus or somesuch.  I don't
know anything about modbus, profibus or localtalk, maybe someone here
can comment...

Tia
Ian McCrum

On Sun, 14 Nov 2004 20:46:59 +0000, Ian McCrum MI5AFL
<IJ.McCrum@ulster.ac.uk> wrote:

>I wonder if there is documentation on standard RS485 protocols
>anywhere for download?

There is no such thing as standard RS-485 protocols. The RS-485 is
simply the electrical specification as would RS-232 or 20 mA current
loop.

>I have homebrewed a couple of these in the past but is there a
>standard way of doing this?

There are hundreds ways of doing it. Pick your own standard :-).

>I am interested in using the serial port of a linux machine, with
>RS485 line drivers/receivers and probably RTS control to effectively
>network a number of machines together. 

If you intend to use it with any decent transmission speeds, do not
even dream of using the standard 16550 etc. UART, since it does not
generate an interrupt, when the last stop bit has actually been
transmitted from the shift register. The 16550 family only generates
an interrupt, when the last character has been transferred into the
shift register, but this is too early to turn off the transmitter. Use
a UART that automatically controls the Rx/Tx through the RTS etc.
signal or at least a UART that will generate an interrupt of the
actual transmission of last stop bit from the shift register.

Paul

>>I am interested in using the serial port of a linux machine, with
>>RS485 line drivers/receivers and probably RTS control to effectively
>>network a number of machines together. 
>
> If you intend to use it with any decent transmission speeds, do not
> even dream of using the standard 16550 etc. UART, since it does not
> generate an interrupt, when the last stop bit has actually been
> transmitted from the shift register. The 16550 family only generates
> an interrupt, when the last character has been transferred into the
> shift register, but this is too early to turn off the transmitter. Use
> a UART that automatically controls the Rx/Tx through the RTS etc.

You definitely want one that does automatic half-duplex control
of RTS.  The 16850 family will control RTS automatically.  The
register interface is a nightmare since they've tried to keep
it backwards-compatible with the 16550.

Several years ago, I hacked up the Linux 16550 driver to do RTS
control.  It worked with some chipsets but not with others.
Apparently, motherboard chipstes aren't very consistent about
when they set the shift-register-empty bit.  Some of them seem
to do it before the final stop bit has been sent.

> signal or at least a UART that will generate an interrupt of the
> actual transmission of last stop bit from the shift register.
                         ^^^^^^^^^^^^^

That's the key.  I've had problems with UARTs that generated
the shift-register empty status at the _start_ of the final
stop bit.

-- 
Grant Edwards                   grante             Yow!  Yow! I want my nose
                                  at               in lights!
                               visi.com            

Some RS485 info:

http://home.planetinternet.be/~pcoleman/techinfo/Rs232/spec.htm

Tom Woodrow

Ian McCrum MI5AFL wrote:
> I wonder if there is documentation on standard RS485 protocols
> anywhere for download?
> 
> I have homebrewed a couple of these in the past but is there a
> standard way of doing this?
> 
> I am interested in using the serial port of a linux machine, with
> RS485 line drivers/receivers and probably RTS control to effectively
> network a number of machines together. 
> 
> Two possible applications spring to mind, my own custom (udp) system
> or trying to get TCP/IP sort of working, NFS or TFTP booting for
> example, I'd accept atrocious performance just for the convenience of
> it all. typically only a pair would be busy at once...
> 
> The SLIP and PPP protocols are not multidrop of course. 
> 
> It may be possible to modify a TCP driver to provide a ALOHA type
> connection ( there being no "collision dectect" on a simple system) 
> 
> It may be possible to encode data so that 8 bits gets transmitted as
> 16 (20 actually if you include stop/start). E.g send each bit as a
> dibit, 01 or 10. Then arrange to pad the line and use a token passing
> mechanism so that each machine only transmits when the line is quiet.
> I could even add hardware to provide a "sort of " collision detect but
> it all seems a bit complicated.
> 
> There may be implementations already done... was localtalk rs485? (
> old apple) or maybe versions of modbus, profibus or somesuch.  I don't
> know anything about modbus, profibus or localtalk, maybe someone here
> can comment...
> 
> Tia
> Ian McCrum
> 

>> I wonder if there is documentation on standard RS485 protocols
>> anywhere for download?

> There is no such thing as standard RS-485 protocols. The RS-485 is
> simply the electrical specification as would RS-232 or 20 mA current
> loop.

There is no standard RS-485 protocol but i dare say there are some 
standard protocols built upon RS-485.

ROBIN - ROBot Independent Network - springs to mind
http://www.bdmicro.com/code/robin/

Wish it was around when I started my rs485 project. ;)

Myren

On 14 Nov 2004 22:26:57 GMT, Grant Edwards <grante@visi.com> wrote:

>Several years ago, I hacked up the Linux 16550 driver to do RTS
>control.  It worked with some chipsets but not with others.
>Apparently, motherboard chipstes aren't very consistent about
>when they set the shift-register-empty bit.  Some of them seem
>to do it before the final stop bit has been sent.

Turning off the transmitter _during_ the last stop bit is usually not
a problem in half duplex protocols, since the driver has actively
driven to the "1" state at the beginning of the stop bit. Turning off
the transmitter during the stop bit has no effect on the line state,
since now the "fail safe" termination will start to pull the line to
the idle "1" state a bit earlier.

This becomes a problem only if you start the next transmission in a
full duplex protocol (or broadcast) before the stop bit period has
elapsed, does the UART even allow this?

Even if the driver is slave-rate limited and you turn off the
transmitter exactly at the start of the stop bit, the "fail safe"
termination will passively pull the line to the "1", hopefully before
the middle of the stop bit at which point the remote receiver is
sampling it.

If you have had problems with some chip sets when polling the
shift-register-empty, it actually has been set long before the start
of the stop bit, e.g. at the end of the actual data byte, but before
the parity and stop bit(s), in which case a "0" parity bit could be
lost.

Paul

Consider IrDA. It is:

- Half duplex
- Has discovery
- CheckSum (HDLC)
- Is well documented
- Can be small
- Multiple baudrates
- Need some minor modifications
- Easy design platform (if you first start with the ir implementation).
- etc.

I'm also using it for a RS485 network and is works great. The slave (sec) is
about 4K of rom and about 220 bytes of ram (8051 as target) with the IAS.
You need some small modifications such as the discovery mechanism (after a
sec. is found the master tells the sec. that it must stop respond to
discovery frames for a while, if it's completely quite during the discovery,
all the slaves are found ).

The prim. also need some small modifications so that it can handle multiple
lap conections etc.

Gerard / StackTools



"Ian McCrum MI5AFL" <IJ.McCrum@ulster.ac.uk> wrote in message
news:67gfp0dr2na07h75ic7i939d15r2pelcf5@4ax.com...
> I wonder if there is documentation on standard RS485 protocols
> anywhere for download?
>
> I have homebrewed a couple of these in the past but is there a
> standard way of doing this?
>
> I am interested in using the serial port of a linux machine, with
> RS485 line drivers/receivers and probably RTS control to effectively
> network a number of machines together.
>
> Two possible applications spring to mind, my own custom (udp) system
> or trying to get TCP/IP sort of working, NFS or TFTP booting for
> example, I'd accept atrocious performance just for the convenience of
> it all. typically only a pair would be busy at once...
>
> The SLIP and PPP protocols are not multidrop of course.
>
> It may be possible to modify a TCP driver to provide a ALOHA type
> connection ( there being no "collision dectect" on a simple system)
>
> It may be possible to encode data so that 8 bits gets transmitted as
> 16 (20 actually if you include stop/start). E.g send each bit as a
> dibit, 01 or 10. Then arrange to pad the line and use a token passing
> mechanism so that each machine only transmits when the line is quiet.
> I could even add hardware to provide a "sort of " collision detect but
> it all seems a bit complicated.
>
> There may be implementations already done... was localtalk rs485? (
> old apple) or maybe versions of modbus, profibus or somesuch.  I don't
> know anything about modbus, profibus or localtalk, maybe someone here
> can comment...
>
> Tia
> Ian McCrum
>

Thanks for the replies and interest shown

It is standard protocols that use rS485 that I am interested

I am not too worried about exactly when to turn the line around, or at
least enable transmitters, I can do this and slight inefficiencies
don't matter, It WILL depend on the actual hardware, it is often
enough to listen to yourself transmitting, provided you clear all
double buffers etc.,

Want I really want is a LLC and MAC based on RS485 that will allow
easy use of standard TCP/IP protocols/applications. I can put up with
atrocious performance initially provided I have the convenience the
standard applications. Perfromance can be improved later...


>Ian McCrum MI5AFL wrote:
>> I wonder if there is documentation on standard RS485 protocols
>> anywhere for download?

>> or trying to get TCP/IP sort of working, NFS or TFTP booting for
>> example, I'd accept atrocious performance just for the convenience of
>> it all. typically only a pair would be busy at once...

>> 
>> There may be implementations already done... was localtalk rs485? (
>> old apple) or maybe versions of modbus, profibus or somesuch.  I don't
>> know anything about modbus, profibus or localtalk, maybe someone here
>> can comment...

Thanks again, 
Ian McCrum

- wrote:

> Consider IrDA. It is:
> 
> - Half duplex
> - Has discovery
> - CheckSum (HDLC)
> - Is well documented
> - Can be small
> - Multiple baudrates
> - Need some minor modifications
> - Easy design platform (if you first start with the ir implementation).
> - etc.
> 
> I'm also using it for a RS485 network and is works great. The slave (sec) is
> about 4K of rom and about 220 bytes of ram (8051 as target) with the IAS.
> You need some small modifications such as the discovery mechanism (after a
> sec. is found the master tells the sec. that it must stop respond to
> discovery frames for a while, if it's completely quite during the discovery,
> all the slaves are found ).
> 
> The prim. also need some small modifications so that it can handle multiple
> lap conections etc.

  IrDA has a new 16MBaud standard, now ramping, and at that speed the 
hardware layers will become real candidates for isolated control busses.
  We just need to wait for the small uC to catch up, and include the 
faster IrDA codecs :)

-jg

Ian McCrum MI5AFL wrote:
>>Ian McCrum MI5AFL wrote:
> 
>>>or trying to get TCP/IP sort of working, NFS or TFTP booting for
>>>example, I'd accept atrocious performance just for the convenience of
>>>it all. typically only a pair would be busy at once...
> 
> 
> Thanks again, 
> Ian McCrum
Here is a fun one,
Hack PPP and add an address field to it, along with a token passing 
scheme and a master.

Look at the older parallel port protocol for linux PLIP.
There could be some interesting reading along with methodology for 
stuffing your serial protocol to work with the built in TCP/IP of linux.
T.