RS485, multidrop protocol

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 are hundreds ways of doing it. Pick your own standard :-).

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

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.

^^^^^^^^^^^^^

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.

Some RS485 info:

Tom Woodrow

Ian McCrum MI5AFL wrote:

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

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

Myren

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

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

Thanks again, Ian McCrum

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

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.

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.

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

============================== 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,

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

-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

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

Ok, I'll go look at slip, I have only worked with PPP before ( Seiko firmware chip)

In practice collisions would be unlikely, a datalogging application will look after the polling, that just leaves other miscellaneous things I'd like to run, tftp and NFS. There would probably be a "master" computer anyway

I'd probably want to run TCP applications over the link, e.g SSH, TELNET or VNC so using a standard TCP/IP stack makes the applications easier to get. And the off timeout wouldn't matter, or could be got around.

Once you have a network, you'd use it for lots of things...

Regards and Thanks again Ian

Running ALOHA on a bus which can be actively driven both high and low at different units, is not a good idea. When one transmitter is driving "1" and the other "0", a quite large short circuit current will flow between Vcc and ground. While the short circuit current limit will protect the devices against permanent physical damage, the transceivers can run quite hot or produce other nasty side effects.

A better solution would be to use some kind of dominant/rescessive system as used in CAN (Controller Area Network). Prior to the availability of dedicated CAN transceivers, ordinary RS-485 chips were used in CAN.

Connect the transmitter data input to a permanent "0" level and connect the serial Tx signal to the Tx-driver enable signal in such a way that the "0" serial data will activate the driver and send out the fixed "0" level (dominant state). When the "1" is to be sent, the RS-485 driver is disabled and the fail safe termination will pull the line to the "1" (recessive) state.

If there is a collision, the dominant "0" driver will override the recessive "1" termination. If you keep the receiver enabled all the time, you can monitor, if some other station caused a collision which overrided your recessive state.

Paul

I've come across this thread rather late so I don't know what's been said, but has anyone mentioned Bitbus? for some stuff.

Paul Burke

try:

Modbus-RTU is horrible, because it relies on inter-character timing for frame delimiting. It is far more easy to use a modified SLIP, where you use 0xFE as start,

Meindert

Modbus is simple and may be appropriate. It comes in two flavors- RTU and ASCII. Google for more.

Best regards, Spehro Pefhany