RS485, multidrop protocol

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

Translate This Thread From English to

Threaded View
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


Re: RS485, multidrop protocol
On Sun, 14 Nov 2004 20:46:59 +0000, Ian McCrum MI5AFL

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Re: RS485, multidrop protocol
Quoted text here. Click to load it

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.

Quoted text here. Click to load it
                         ^^^^^^^^^^^^^

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!
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol

Quoted text here. Click to load it

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


Re: RS485, multidrop protocol
Quoted text here. Click to load it


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

Re: RS485, multidrop protocol
Some RS485 info:

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

Tom Woodrow

Ian McCrum MI5AFL wrote:
Quoted text here. Click to load it

Re: RS485, multidrop protocol
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...


Quoted text here. Click to load it



Thanks again,
Ian McCrum

Re: RS485, multidrop protocol
Quoted text here. Click to load it
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.

Re: RS485, multidrop protocol
Quoted text here. Click to load it
I brought up PLIP because it could give you a template of connecting
your serial control protocol with internal TCP/IP transport.

Using PPP(type) packeting allows for an easy way to create begin and end
packet segments for easy packet synchronization.
PPP is point to point, but if you ADD a leading address byte to the
packet structure then you are all set.
You obviously need to add a bunch of code here to make this work. I am
just giving suggestions on where to start looking for pieces that can be
used to transport data in the way you suggest.

T


Re: RS485, multidrop protocol
Quoted text here. Click to load it

The PPP framing is actually a special case of HDLC (ISO 3303)
framing. There is an address byte: the first byte after the
starting flag which is 0xff in PPP. If single byte addressing
is enough for your network, just put the address in there.

It may be worth while to think if the PPP link control
protocols (IPCP & co) are really needed in a special
network like this. The control protocol is needed if the
IP addresses and other network parameters have to get
distributed when the link is established.

The main problem in a RS-485 network is the distributed
control of the transmit enables to keep bus contention
out. If the network is a logical star controlled by a
single master station, the timing can be solely run
by the master.

--

Tauno Voipio (OH2UG)
tauno voipio (at) iki fi



Re: RS485, multidrop protocol

Quoted text here. Click to load it

Is that the correct ISO standard? I looked up ISO 3303 and found that it
relates to "Rubber or plastic coated fabrics - determination of bursting
strength". Nothing at all about HDLC protocols. Perhaps you really meant
ISO/IEC 3309:193 "Information Technology - Telecommunications and
information exchange between systems, High-level data link control (HDLC)
procedures - Frame structures".

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol
Quoted text here. Click to load it

Yes - sorry for the slip. The text was at hand - and I
copied wrong (blush!).

--

Tauno Voipio
tauno voipio (at) iki fi


Re: RS485, multidrop protocol

Quoted text here. Click to load it

It's OK, you are forgiven. I am sure many others would have identified the
correct standard easily enough by googling for it. Generally you are below
the 3% error rate for keyboard entry so no need to blush too redly.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol
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



Quoted text here. Click to load it



Re: RS485, multidrop protocol

Quoted text here. Click to load it

  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


Re: RS485, multidrop protocol
Quoted text here. Click to load it
<SNIP>
Quoted text here. Click to load it

Ian, as you can see from the responses there doesn't seem to be a standard.
We also have homebrewed a couple.  I have placed a zip file in a download
area of our web site of a simple protocol we have used a few times.
http://www.exotech.com/downloads.htm .

I realize this is asking all the NG's old hens to fuss about how it could be
better, faster, simpler, etc.  But the cost is the same, and I can't
remember seeing there offerings.  Although I am willing to host any others
on the site.

Scott




Re: RS485, multidrop protocol
Quoted text here. Click to load it

wrote:
Quoted text here. Click to load it

==============================
Thanks Scott, I have downloaded the .zip I'll give it a good looking
over.

It has been 3 or 4 years since I did my last RS485 network, and it has
always been one computer talking to a number of much smaller
microprocessors. I always used a four wire system. I'll see if I can
dig up the code.

I am running a simple RS485 lab past my students at the University and
it rekindled my interest,
Http://www.eej.ulst.ac.uk/~ian/modules/COM347J1/COM347J1_LAB5.pdf
A mate called Pat Sweeney wrote it, the students are only computer
science students and have no/little hardware expertise so they just
poke a few registers and see a few characters go flying by (at 1
baud!)

plus I am getting an ARM board to play with soon 8-)

In reply to other posters, is IrDA multi-drop?

Actually hacking PLIP or SLIP is fine for point to point, the real
physical media is not of too much importance, but getting multiple
machines to work is harder. PPP does not use addresses!

As a starting point, Jeremy Benthams book on putting TCP/IP on PICs
uses a ethernet card driver (for a 3com 3c509) of only 250 lines of C.
Might be worth a play. If the interface at a driver level is so
simple, e.g in linux then it would be easy to add a simple driver
module that pretended to be an ethernet card.

The driver code could play pass the parcel to get its message around
the network. Even if it meant defeating ARP and using hardwired ARP
tables, or frigging with various timeout timers it might be on...
8-)))
Ian


Re: RS485, multidrop protocol
Quoted text here. Click to load it
<SNIP>

Should work fine for 4-wire also.  We use it primarily on 2-wire in an
industrial control app with 2 to 20 or more devices per network.

Scott



Re: RS485, multidrop protocol
Quoted text here. Click to load it

I've come across this thread rather late so I don't know what's been
said, but has anyone mentioned Bitbus?
<http://www.alfirin.net/flamer/bitbus/ for some stuff.

Paul Burke

Re: RS485, multidrop protocol
-I wonder if there is documentation on standard RS485 protocols
-anywhere for download?

RS485 is an electrical standard. But that's not what you're talking
about. There is no multidrop data link standard.

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

Nope.

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

OK.

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

PPP isn't. But SLIP is nothing other than a trivially modified IP
packet, which of course is routable. There's no technical reason why
you couldn't route addressible packets onto a SLIP link. Run UDP on
top of it and voila! a simple and standard multidrop link.

However you'd still have to implement a speak when spoken to only
duplex protocol on top of this to eliminate collisions.

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

Why not do it in the application layer and leave TCP out of it. Just
send datagrams over the SLIP link and have everyone involved strictly
follow a speak before spoken to protocol?

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

Very complicated. If you're going there when implement a virtual token
system where you can only speak when you have the token.

Collisions are of course the problem. You can't afford to have any.

BAJ

Site Timeline