12

I'm working on a project that involves a good bit of data communication between a remote Arduino and a computer. The wireless connection is through a pair of XBees, so we have a RS232 link between the Arduino and the computer. For small amounts of data, it's easy enough to throw together some simple communication protocol. For larger projects, though, what are some good simple communication protocols?

I've looked at MODBUS, which seems like a viable option, but I wanted to see if there were other better options.

davidcary
  • 17,426
  • 11
  • 66
  • 115
Computerish
  • 717
  • 2
  • 9
  • 18
  • 2
    What exactly are the requirements? –  May 16 '13 at 19:25
  • Looking for general suggestions. Simplicity and low overhead would be the main goals for the project. – Computerish May 16 '13 at 19:53
  • 1
    Sorry, I also meant: how much data, how fast –  May 16 '13 at 19:54
  • I don't have quantitative measures for that, but not a lot and speed isn't a huge issue. – Computerish May 16 '13 at 20:41
  • 7
    Not a lot and speed not being an issue argue strongly for something human readable, since it makes development & debugging much easier. It's great when you can connect a terminal and substitute yourself for either end of the link. – Chris Stratton May 16 '13 at 22:18

6 Answers6

11

Some embedded system protocols, several of them extremely simple, are listed at Embedded Systems: Common Protocols, including:

Perhaps one of these protocols would be adequate for your application as-is, or with only minor tweaking.

davidcary
  • 17,426
  • 11
  • 66
  • 115
6

I'd vote roll your own, and keep it as simple as possible.

I've dealt with lots of serial protocols for various control applications, and a few things that I can recommend you include are:

  • Start & stop characters which are not used elsewhere
  • Some sort of checksum / error checking
  • Some method of flow control / signalling, especially if you need bi-directional comms.

As a very basic example, you might convert your data to ASCII characters and stick it inside start/stop characters like this:

To send the byte value 0x7A, the data sent would be (7A), where the () are the chosen start/stop chars and 7 and A are two ascii chars. OK it addds a lot of overhead, but it means you can debug with basic terminal software.

John U
  • 7,041
  • 2
  • 21
  • 34
5

If your data is going through XBees, you should put the modules into API mode with escape characters, divide your data into logical packets, and take advantage of the fact that in API mode a packet which is given to an XBee will either arrive intact or not at all. Design your protocol around the transmission of chunks of 1-255 bytes, and let the XBee modules worry about how to deliver the data within each chunk. Don't worry about maintaining the integrity of individual packets or the subdivisions between them. The Digi modules will do a good job of taking care of that. The biggest thing you do need to worry about is the fact that even if the node that transmits a packet believes it wasn't delivered and sends a replacement, the recipient may end up getting it anyhow--possibly even after it gets the replacement. Things may be easiest if you design your protocol so that one side is the "master"; if the master asks for a piece of data, the slave should send it once and not worry about whether the master gets it. If the master doesn't get the data that it wants, it can request it again.

The slave should assign some sort of sequence numbers to data, and the master should assign sequence numbers to requests that the slave change state. If the master's request is of the form "send the first item whose sequence number is greater than XXX", and each piece of data item by the slave includes its own sequence number and that of the previous item (if they're not numbered consecutively), late-arriving packets may cause the slave to redundantly send data to the master, but the master will have no difficulty ignoring the consequent late-arriving responses. If the slave receives a state-change request whose sequence number is below that of an earlier request, it should ignore the that request, since it was superceded even before it was received.

supercat
  • 45,939
  • 2
  • 84
  • 143
4

The O.P. asks for a serial protocol for a situation where "not a lot [of data] and speed isn't a huge issue". MODBUS is mentioned in the O.P. MODBUS over RS-485 is not a fast protocol. While this is not a spec, this gives an idea about the niche.

I can think of only two common standard protocols for this niche:

  • NEMA 0183. Plain text ASCII protocol. Human readable. Point-to point only. Doesn't support multi-drop bus.
  • MODBUS which was already mentioned in the O.P.

Very often, when the embedded programmers are in the situation like the O.P., they design their own serial communication protocols from scratch.

Nick Alexeev
  • 37,739
  • 17
  • 97
  • 230
3

I had a similar question to this and never found anything simple and small enough for little AVRs etc. So I rolled something inspired by CAN. It's called MIN (Microcontroller Interconnect Network):

https://github.com/min-protocol/min

I've blogged about it here:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

There are hooks there for block data, but it's mostly aimed at signals for sensors/actuators. I've defined a JSON format for describing signals and their packing within MIN frames and hope to get a Wireshark dissector that uses it.

Ken Tindell
  • 31
  • 2
3

How about Firmata? It has support for various operating systems and programming languages. Controller side Arduino and PICduino are supported, but that shouldn't be too hard to port to a bare microcontroller.

jippie
  • 33,033
  • 16
  • 93
  • 160