RS485 protocol

Go To Last Post
33 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I had been reading avrfreaks topics about this subject, but I still have some doubts about what I should use in a project I'm working on.
I'm going to describe it:

One central board(brain) and several other boards(user keypad) all connected in a network.
The brain talks to all boards, but the keypads only talk to the brain and not among them.
The brain can start talking to a keypad to make it beep, as well as the keypad can start talking with the brain to ask it some information to display.
So, all of them can act as master or slave.

Each board has an ATMega128 and I'm thinking in using RS485 as the network physical layer.

Can you advise me which protocol should I implement?

Modbus would be the perfect solutions if I hadn't the need for multi-master. On the other hand, SNAP allows multi-master but lacks collision avoidance.

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would go RS485.

I would NOT allow the remotes to send any time they want to. I would have the master poll the slaves (Do You Have Any Data?). Each slave would have an address (perhaps set by a DIP switch). You can run the system at a high enough rate that it appears instantaneous to users.

Make your own protocol. What you describe is pretty simple.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But a keypad is an input device to the avr. You mentioned something about a display and a beep, so your slave terminals are really a keypad, display, and beeper. What does the master do? Is this a psych experiment? I need the big picture to do a good brainstorm.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In our alarm systems we have a master and multiple slaves. The master does a global poll, and any slave with info responds to the poll. The master then asks the slave what it has, and gets a response.

If a message needs to be sent, the master stops polling, and sends the data to be displayed to either a specific slave, or to all slaves. The slaves can differentiate between a global poll and other types of information.

--Rich

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like the OP already has the start of a protocol.
I am guessing the keypads will store any keypress and then deliver when there is a Master request for that address. I would also add some sort of checksum to help identify bad transmit/receive data.
Are you using ready to go RS-485 boards or are you building your own? How many slaves?

I'll believe corporations
are people when Texas executes one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all!

I guess I'd better explain the whole functionality, so you can better understand and give the best advice.
It might be long, but at least you would get the whole idea.

This would be a specific project mainly to provide employee clock-in/clock-out and some other user operations such as scheduling/viewing vacations, etc.
There would be a main board which would store the whole information. Terminals spread through the building, with a display and a keypad would communicate with the main board through RS485.
A user types his/her own password on a terminal keyboard, the keyboard asks the main board if this password is correct. If so, then the user has access to several options in the terminal. For instance, if the user chooses to clock-in, then the terminal sends this information to the main board, where it would be stored.
Terminals would have the minimum of intelligence, but it should be capable of reading a user password and just send a packet to the main board with the user identification and the password. The main board answer would be a code ok or code wrong, for instance.

It should be possible to add more terminals to the network during normal operation. It would be necessary to type an installer password in the new terminal, so it would be activated in the main board.

The main board would have ethernet interface, so that a terminal emulation software could run in a normal PC and act just like a RS485 terminal to the user.

The network would have 32 node maximum.

All boards, including the main board and terminals would be built from scratch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it were a few years ago, I'd say go with RS485. Nowadays, ethernet is so cheap and easy to implement, i'd go that way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman:
You're right, but RS485 is still cheaper and simpler to implement, so I guess I'd rather use RS485.
Ethernet would be used just in special cases.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any ideas for the RS485 protocol?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about every packet has flag, address, opcode, bytecount, bytecount bytes of payload. Flag is always something like 0xAA, address is 1-32, opcode is 1 to whatever, bytecount is 0-255, payload databytes is obviously, the payload databytes.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
ethernet is so cheap and easy to implement, i'd go that way.

Ethernet for inter µC communication?! Why!?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
How about every packet has flag, address, opcode, bytecount, bytecount bytes of payload. Flag is always something like 0xAA, address is 1-32, opcode is 1 to whatever, bytecount is 0-255, payload databytes is obviously, the payload databytes.

And what about single-master/multi-master?
Would it be better to have single master polling all slaves and no collision problem, or multi-master and collision detection (this would be much more complex)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It may be off interest of the OP to also consider using an off the shelve R-232 to RS-485 converter.
www.bb-elec.com and www.rs485.com. Could speed up the development cycle until production starts.
bb-elec.com also has online app notes that can be useful.

I'll believe corporations
are people when Texas executes one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tubecut wrote:
It may be off interest of the OP to also consider using an off the shelve R-232 to RS-485 converter.
www.bb-elec.com and www.rs485.com. Could speed up the development cycle until production starts.
bb-elec.com also has online app notes that can be useful.

Not necessarily. I would use a MAX485 rather than a MAX232 in all boards.
However, it might be useful if testing each board with the PC, i.e., connecting the PC to the RS485 network.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just design the request opcodes and the slave responses so that only the master or the addressed slave talks. Dont have an opcode like 'all nodes report'. Make em like 'node 1 send inputs' then turn the line around and wait for a few ms.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would consider the protocol suggested by Bob Gardner.
Some use the 9th bit for address data to select a remote, that can get a little tricky compare to just having a start sequence which contains the address and perhaps the op code....

I'll believe corporations
are people when Texas executes one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would go with single master, multiple slaves.

Suppose that you have 32 slaves. Suppose that the slave query packet (following Bob's suggestion) is 6 bytes and your system is running at 9600 baud. That means 960 bytes per second or 130 packets per second. Thus, in a quiet system, every slave will get polled once every 8ms or so. Since a human cannot really detect a time lag less than about 10ms, this will appear instantaneous And, even if the system slows down due to several slaves being active at the "same" time, and the response time grows to once every 30ms, most users will hardly notice it. Only if it gets down to 100ms or longer will most users even notice it!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, a further note:

I would combine the address and the data byte count into a single character and add a CRC or simple check-sum at the end. Also, consider a terminating flag byte, though that is not so critical, especially, if the system is single-master.

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bob:
The protocol you suggest is very similar to SNAP. It also contains CRC or checksum, as suggested by Jim.
I guess I'm going to use it.

Single master polling the slaves seems to be the best choice, since collisions are avoided.

Jim:
According to your calculations, 130 packets per second means that with 32 slaves, I would have each slave polled 4 times a second.
But you should consider that the slave must answer with: "I have no data" or "check this password". So, polling a single slave must take 12 packets or more. This reduces the polling time to 2 times in a second, or 500ms.
Even so, this way the master won't be available to perform other tasks, such as serving as web server, which might be time consuming.

The baud rate could be increased (up to 115kbps in a 4000ft line) but it might not be enough.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not every transaction will take 12 packets. On the average, it will take only a few more than 2.

Further, 500ms is really not a big deal. People WILL complain if they push a button and character takes that long to appear on a display. But, between entering a password and opening a door is much less of a problem.

If you need a web server, I sincerely suggest that, at the very minimum, you put a second micro on the host platform just for that purpose.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Logic_bit,

Remind me why you need a master board in between your PC and the network of slave devices. It seems to me that you should be able to simply use the PC (fitted with an RS485 output) to act as the master and doing your lookups and record keeping; much faster.

Cheers

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ross:
The master board is to avoid the need of a PC. It would require some kind of maintenance, as opposed to the master board.
With the ethernet/webserver feature, data could be accessed anywhere where internet is available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim:
I was thinking in using an ethernet chip with i2c interface. But even this way I might need some time to read and send http packets.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whats the crc do? Has anyone ever seen a protocol that used the crc at the end? Dont intel hex files have a checksum at the end? There isnt a rom burner anywhere in the world that pays any attention to it. Has anyone ever seen a ethernet packet error due to a crc error?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course you will need time. Time should not bee the issue. It is whether or not it is too much time for the human client out there at the remote site.

I frequently get off on an unproductive direction like this, worrying about execution speed. It has almost never been the real problem I imagined it to be. I suggest that you make a rough estimate of the time required for a full transaction in an otherwise quiet system, then look at what happens as the system loading increases.

I'd bet that you will find that a real system will have only a few remotes loaded. And those will saturate at the rate that transactions can be handled. It won't go above that because people will just queue. That pattern also will not last long because people don't like to queue and they will spread out their arrival to reduce waiting.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Has anyone ever seen a protocol that used the crc at the end?
Yes :) my RS485 protocol does. (16 bit similar to Modbus)

The only thing I do if the CRC does not match is to throw the packet away.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

logic_bit - an ethernet chip with i2c? SPI is fine as you can run spi as fast as you like whereas i2c is limited to 400kHz. Nevertheless, I still stand behind my earlier suggestion of ethernet - think of it like a comms co-processor. An enc28j60 is quite cheap - I pay <$4AUD for 1 off, a 25mhz crystal, some r & C and a magjack. Sure -not quite as cheap as RS485 but the installed cost may be cheaper by the time you consider connectors , cabling etc. With ethernet eveything is commodity product - routers, switches, cabling etc. Another compelling reason is standardisation -installation, power etc. I've used RS485 for years in indutrial and building apps and I've had little reason to regret it. But now, everyhting ends up cummunicating over ethernet in my apps, so I might as well take it down to the microprocessor. The cost is now competitive and to implement is not a major issue. You also get 'multimaster' for free.

As for CRC - my floppy disk uses CRC! Modbus, Novatel binary (GPS receivers) Hard drives used to use CRC. As for ethernet packet CRC errors - they're normally silently discarded. Some drivers keep tabs for you, but I normally don't look! I get CRC errors using Modbus on RS485, but this is normally due to transients.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ethernet crc is checked in the ethernet chip. I suppose there is some status bit or interrupt if there is an error. If the bad packet is part of a UDP payload, it can be discarded just like you said. If its in the middle of some TCP sliding window, theres a bunch of acks and nacks and retransmissions that have to happen. I think we are all 'real sure' that some smart device driver dude that was getting $150 an hour did his job real good and all that dirty error checking is just working magically so we dont have to worry about it.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I had some CRC errors with downloaded zip files, not sure though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Organize the lay out of the data packects as "bobgardner" suggests.

Shift those data in and out with the SPI (provided that all the reripherals do have SPI) and use the RS485 as the physical layer to incrise the distance between the peripherals.(The RS485 specification, specifies only the physical layer. The rest is up to you.)

Concerning the bitrates, there are RS485 tranceivers capable of up to 2Mps (however a bitrate about 200Kbps and a tranceiver which is slewing rate limited to about 200Kbps, seem to be sufficient and less EMI sensitive)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ccharala - with SPI you also need to send the clock - more interface ics and wires - unless you encode the data using manchester. Much better off using the uart. As for slew rate limited tranceivers - the slew rate limiting is to limit EMI generation, not reception.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote: " Much better off using the uart"

Indeed! Whoever the SPI is multidrop by design as well as the RS485; and the UTP-4pair cable is a good option.
(This way or the other, the upper layer depends on the design and the designer)
-------------------------------------------------------

Kartman wrote: " the slew rate limiting is to limit
EMI generation, not reception."

Indeed! Whoever the slower a receiver is, the less it receives fast trancients (including EMI).
Additionally the EMI source closer to the RS485 reciever is the same RS485 transmitter, and..., and...
, and..., and...

Keeping the bandwidth of receivers and transmiters to the minimun sufficient is not a bad practice.
Combine this with the inherent EMI rejection capabilities of the FTP/UTP cable (dew to the twists)together with the differential input of the tranceiver and you are close to the physical layer you need, on whatever serial interface and data packet lay out you prefer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should be very careful with your design. I don't think it's a good idea to have master confirm access ID for each slave. If something goes bad with your cabling then imagine what angry people locked in their offices can do to you once you finally come on site. ;-)
I think it's better to download list of access ID's to each slave and make slaves somewhat independent. Your master should be there to talk to all slaves (download their events and upload access data), and talk to host PC. Take a look at www.spica.com/products/TS-hardwa... - this might be a good reference for you in both hardware architecture and software. With this arcitecture you can also avoid multi masters and go with single master multi slaves.

I am a MODBUS fun, but if your project grows over a certain limit, then you will see that you need a protocol of your own because of flexibility reasons.