# Communication between multiple microcontrollers

I'd like to start implementing a system consisting of N microcontrollers (N >= 2 MCUs), but I would like to know the possibilities to let them communicate one with the other.

Ideally, (N-1) microcontrollers are placed inside the house acting as clients, while the last (the "server") one is connected to a PC via USB. The problems I have right now is how to connect these (N-1) microcontrollers to the "server". The clients MCUs perform very simple tasks, so it may not be a good solution to use ARMs to do such simple jobs just because they provide CAN / PHY-MAC.

The communication will not happen more than once every few minutes for most of the devices and on demand for others. The speed is not very critical (message is short): 1 Mbit/s I think is WAY overkill for my purposes.

The MCUs I plan on using are the following.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3/M4
• (Possibly Atmel AVR UC3 - 32-bit)

I'd like to avoid PICs if possible (personal choice), simply because there are less possibilities to program them (all the above have more or less open source tools as well as some official tools).

I know some ARMs provide CAN functionality and am not so sure about the others.

Right now I came up with these possibilities:

1. Simple GPIO to send data (say > 16 bits at HIGH to indicate start of message, > 16 bits at LOW to indicate end of message). However it has to be at a standard frequency << (frequency_client, frequency_server) to be able to detect all bits. Only need one cable per client MCU.
2. RS-232: I think this is by far the most commonly used communication protocol, but I don't know how well it scales. I'm considering up to 64 client MCUs right now (probably more later)
3. USB: AFAIK this is mostly like RS-232, but I don't think it scales very well in this case (though USB supports lots of devices - 255 if I remember correctly - it may be overly complicated for this application)
4. RJ45 / Ethernet: this is what I'd really love to use, because it allows transmission over long distances without a problem (at least with shielded >Cat 6 cable). The problem is the cost (PHY, MAC, transformer, ...). I don't know if you can actually solder it well at home though. This way I wouldn't need a client MCU
5. Wireless / ZigBee: modules are very expensive, though it may be the way to go in order to avoid "spaghetti" behind the desk
6. RF modules / transceivers: I'm speaking of those in the 300 MHz - 1 GHz band, so they should be difficult to solder at home. The modules are all built-in, but they are quite as expensive as the ZigBee (at least the RF's modules at Mouser, at Sparkfun there seem to be cheaper ones).
7. CAN? It seems to be very robust. Even though I don't plan to use it in automotive applications, it may still be a good alternative.
8. I²C / SPI / UART? Again - better avoid "spaghetti" with the cables if possible
9. PLCs are not really an option. Performance degrade pretty fast as the length increases and depends on the capacitance load of the power network. I think price-wise is about the same as Ethernet.

Furthermore, which protocol would be "better" in case of simultaneous transmissions (let's assume the rare case that at the very same instant two devices begin transmitting: which protocol provides the best "conflict management system" / "collision management system"?

To sum it up: I'd like to hear what may be the best solution for a distributed client system that do very light data communication, considering both flexibility (max number of devices, conflict / collision management system, ...), price, easy to make at home (soldering), ... I'd like to avoid spending 20$on just the communication module, but at the same time having 30 wires behind the desk would suck. The solution I'm imaging right now would be to do basic communication between near MCUs by GPIO or RS-232 (cheap!) and use Ethernet / ZigBee / Wi-Fi on one MCU per "zone" to communicate with the server (expensive, but it is still a lot cheaper than one Ethernet module per each client MCU). Instead of cables it may as well be possible to use fiber optic / optical fibers. Though additional conversions are necessary, and I'm not sure if it'd be the best solution in this case. I'd like to hear additional details on them. • There are PICs with CAN functionality and there are free official tools to program them with documentation. – AndrejaKo Jul 15 '12 at 12:43 • @AndrejaKo PIC don't really have an open source compiler like AVRs or at least MSP430s. Its true that they often provide more features than the MCUs I listed above for the same price. I don't really like these big differences between the 12/16/18/24/32 families and that some of those don't have a free compiler at all (I think it's PIC18). – user51166 Jul 15 '12 at 12:49 • Actually PIC18 does have gratis compiler and so do others. The main bonus of other families is that they work with GCC. In the open source camp, there's the Small device C compiler which should support PIC 16 and PIC 18 devices. – AndrejaKo Jul 15 '12 at 13:00 • If you are not experienced with any of the uCs you mentioned yet, be warned that ARM is much harder to start with than e.g. PICs or AVR, especially if you want to go open source. With ARM the vendors don't design the core, and also don't generally provide an IDE, which can make the whole thing a bit more complex. It's nice to have e.g. Microchip provide and support everything in the case of PICs. – Oli Glaser Jul 15 '12 at 13:40 • @OliGlaser Well ... while it's true that open source tools for ARM can be a little hard to use (I've tried a STM32 Discovery board and it didn't work very well), many vendors offer an IDE which is - with its pros & cons - eclipse based and free-limited: LPCXpresso (NXP) and Code Composer Studio (TI) for instance (not open-source, but they're supported at least). AVRs are on the other hand pretty good supported on the open source side, as well as in ATMEL STUDIO 6. No experience with PIC whatsoever. Coded only AVR (assembler) and ARM (C, on the NDS). – user51166 Jul 15 '12 at 13:52 ## 8 Answers CAN sounds the most applicable in this case. The distances inside a house can be handled by CAN at 500 kbits/s, which sounds like plenty of bandwidth for your needs. The last node can be a off the shelf USB to CAN interface. That allows software in the computer to send CAN messages and see all the messages on the bus. The rest is software if you want to present this to the outside world as a TCP server or something. CAN is the only communications means you mentioned that is actually a bus, except for rolling your own with I/O lines. All the others are point to point, including ethernet. Ethernet can be made to logically look like a bus with switches, but individual connections are still point to point and getting the logical bus topology will be expensive. The firmware overhead on each processor is also considerably more than CAN. The nice part about CAN is that the lowest few protocol layers are handled in the hardware. For example, multiple nodes can try to transmit at the same time, but the hardware takes care of detecting and dealing with collisions. The hardware takes care of sending and receiving whole packets, including CRC checksum generation and validation. Your reasons for avoiding PICs don't make any sense. There are many designs for programmers out there for building your own. One is my LProg, with the schematic available from the bottom of that page. However, building your own won't be cost effective unless you value your time at pennies/hour. It's also about more than just the programmer. You'll need something that aids with debugging. The Microchip PicKit 2 or 3 are very low cost programmers and debuggers. Although I have no personal experience with them, I hear of others using them routinely. ## Added: I see some recommendations for RS-485, but that is not a good idea compared to CAN. RS-485 is a electrical-only standard. It is a differential bus, so does allow for multiple nodes and has good noise immunity. However, CAN has all that too, plus a lot more. CAN is also usually implemented as a differential bus. Some argue that RS-485 is simple to interface to electrically. This is true, but so is CAN. Either way a single chip does it. In the case of CAN, the MCP2551 is a good example. So CAN and RS-485 have pretty much the same advantages electrically. The big advantage of CAN is above that layer. With RS-485 there is nothing above that layer. You are on your own. It is possible to design a protocol that deals with bus arbitration, packet verification, timeouts, retries, etc, but to actually get this right is a lot more tricky than most people realize. The CAN protocol defines packets, checksums, collision handling, retries, etc. Not only is it already there and thought out and tested, but the really big advantage is that it is implemented directly in silicon on many microcontrollers. The firmware interfaces to the CAN peripheral at the level of sending and receiving packets. For sending, the hardware does the colllision detection, backoff, retry, and CRC checksum generation. For receiving, it does the packet detection, clock skew adjusting, and CRC checksum validation. Yes the CAN peripheral will take more firmware to drive than a UART such as is often used with RS-485, but it takes a lot less code overall since the silicon handles so much of the low level protocol details. In short, RS-485 is from a bygone era and makes little sense for new systems today. The main issue seems to be people who used RS-485 in the past clinging to it and thinking CAN is "complicated" somehow. The low levels of CAN are complicated, but so is any competent RS-485 implementation. Note that several well known protocols based on RS-485 have been replaced by newer versions based on CAN. NMEA2000 is one example of such a newer CAN-based standard. There is another automotive standard J-J1708 (based on RS-485) that is pretty much obsolete now with the CAN-based OBD-II and J-1939. • building my own custom board is useful when integrating the MCU with the hardware it has around it. For development purposes I agree a development kit is a better way. My reason for avoiding PICs is their lack of open source compilers (there are some free, but not for PIC18 for instance) rather than a lack of public available schematics, though they provide some additional features you may not find in other MCUs (Ethernet, CAN, ...). And I2C is a bus AFAIK. – user51166 Jul 15 '12 at 13:15 • @user51166 - There are free PIC18 compilers provided by microchip. See the MPLAB XC Compilers product page. It also lists the compilers for the 16bit and 32bit uC. – PetPaulsen Jul 15 '12 at 13:33 • @user51166 There's also the free C18 compiler too. – AndrejaKo Jul 15 '12 at 13:39 • @PetPaulsen Strange. I'm pretty sure I saw a month ago a page that listed all compilers freely available to download (PIC16/24/32), with the exception of the PIC18 that wasn't because of some licensing issue they had. Probably that was solved with the transition MPLAB C Compiler -> MPLAB XC Compiler although I'm not sure. Furthermore they "only" offer a freeware edition which doesn't optimize your code, not a fully open source compiler. Still that's better than nothing ;) – user51166 Jul 15 '12 at 13:46 • @user: I believe all the Microchip compilers have free versions that differ only from the full ones in that some of the optimizations are disabled. The assembler, librarian, linker, and simulator are all included in the free MPLAB package. There is really no issue here. – Olin Lathrop Jul 15 '12 at 13:48 I would recommend controller with CAN as this feature are meant exactly for the controller networking purpose. RS232 can be implemented easily but it will get real challenging if you try to implement communication more than 2 nodes (cause it's not build for this purpose). Ethernet can be a sweet option too since you mentioned some host and clients interconnections which is natural to Ethernet implementation. • What are the advantages of CAN over Ethernet for instance? Cheaper probably, but other than that, what else? – user51166 Jul 15 '12 at 12:50 • @user51166 - CAN is not just cheaper but much cheaper. It is not only easier, but much easier. – Rocketmagnet Jul 15 '12 at 18:51 • @Rocketmagnet: please explain a bit more. In most cases you need an integrated IC anyway (though PICs and ARMs and others? often integrate CAN feature, they're a bit expensive). From a hardware point of view I don't see how this can be much cheaper since the ICs can be found for 0.5-1.0$ a piece. I suppose you mean easier from a software point of view, right? CAN has a maximum distance of ~ 500 meters which is surely enough in my case, but - just for information - would there be similar alternatives for longer distances (optic fiber maybe)? – user51166 Jul 16 '12 at 5:29

RS-485 using multiple wires could work well here, if there's a possibility to wire the same line to all devices.

If for example it's used with traditional category 5e network cable, you could have two pairs to work for data transmission in both directions (using a full duplex module), have one pair or maybe even single wire as the common ground and the rest to negotiate which device is going to transmit in which moment. It's a bit more complicated that RS-232, but the modules are cheaper than CAN and Ethernet and the cable limit is 1200 m. The downside is that you'll have to make your own conflict resolution protocol. Maybe have the device which wants to transmit check one dedicated wire and see if it's high. If it isn't, bring it high and start communicating and if it is, wait for a random time period. Still I'm not sure how well this would work on long distances.

• Not to worry about too long distances, I don't plan going over 100m at the moment. – user51166 Jul 15 '12 at 13:18
• Why BTW does today stackexchange not accept @<username> ? Each time I put one, it gets completely deleted (not just the @ symbol) ... – user51166 Jul 15 '12 at 13:21
• @user51166 - The creator of the answer is automatically notified, so the "\@-noise" is automatically removed. (My \@user51166 was not removed, because you are not the creator of this answer) – PetPaulsen Jul 15 '12 at 13:28
• The interesting thing is that I didn't receive notifications for any of the comments here. – AndrejaKo Jul 15 '12 at 13:38

I would choose a RS-485 bus working with Manchester Encoding data.

RS-485 because:

• Is cheap
• Is easy to implement
• Is uses lo power
• Allows for long distances (up to 1200 meters)
• High data rates (up to 10 Mbps)
• High immunity to interferences
• There are transceivers that allows up to 256 devices on the same bus
• Low part count

Manchester encoding because:

• Is easy to implement
• Is self-synchronizable

For data integrity the message can include a length and a CRC field.

Example of a CRC function:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
unsigned long i;
unsigned char crc;

crc = CRC_INIT;

for (i=0;i<size * 8;i++)
{
crc = (crc << 1) | (crc >> (7));

if (buffer[i/8] & (0x80 >> (i%8)))
{
crc ^= CRC_POLY;
}
}

return crc;
}


CRC_INIT and CRC_POLY are arbitrary values that are used to compute the CRC.

Example of a message with length and CRC fields:

• Any suggestion for such good transceivers, possibly cheap ? – user51166 Jul 15 '12 at 15:01
• Furthermore as @AndrejaKo suggested RS-485 doesn't seem to offer conflict resolution protocol. – user51166 Jul 15 '12 at 15:05
• The choice of transceivers depends on the voltage you intend to use. The conflict resolution have to be made in software with CRC check, line monitoring or both. – Bruno Ferreira Jul 15 '12 at 15:07
• If you have one master you could also implement some kind of addressing, or turn based transmission. – Bruno Ferreira Jul 15 '12 at 15:10
• Not really a master. Just the "server" which acts like an interface to the PC via USB. The clients have to send messages to him automatically however ... – user51166 Jul 15 '12 at 15:14

Let me compare your preferred choice, Ethernet, with my preferred choice, CAN.

Components required:

• Ethernet: RJ45 connector, magnetics, Phy chip (unless integrated into MCU). Also need switches and a cable from the switch to each node. Each PCB needs quite a few capacitors and terminating resistors, possibly ferrites too. Needs good PCB design.
• CAN: Transceiver chip (cheap), any connector, cheap cable can hop from one node to the next in a loop around the site. Need only one capacitor for the transceiver, and one terminating resistor at each end of the bus.

You're talking about \$1 microcontrollers. There is much more to the cost of the bus than the MCU. You'll have to add up the total cost of each solution to know which is actually cheaper. Add up the cost of the MCU, connectors, transceivers, passive components, PCB, cables, etc.

LPC11C24 from NXP has also tha CAN transceiver integrated, and CANOpen supported in ROM (not eating away your 32 K data Flash). LPCXpresso 11c24 board is 20 EUR (has provided space for DB9 connector), so you really just add wires :-)

Repost from another similar question. Low cost simple communication between two microcontrollers

TLDR: Not particularly cheap but reliable fit in some use cases.

Looking outside the box, there might be some other solutions here such as following chip that I bumped into lately. Of course, it all depends on what you want to do. Something like UART comes to mind if you got them both MCUs on the same board or even planning to ESD protect them manually if separated.

Master and Device Solution for IO-Link Applications

L6360   Master
L6362A  Device


When would you consider a solution such as this:

1. The frontier chips come Fully protected which would be important if you have each MCU on a separate board and dealing with exposed pins e.g. screw terminal.
• Reverse polarity
3. Integrated regulator Vcc(in) 7~30v, Vdd(out) 3.3/5v