i am looking to communicate text ( 40 char for each message ) between N arduino and a central one ( Communication is one way slaves to Master).I am looking for wire communication with 1 to 5 m distance.Does anyone know the best approach to do that ?



You have quite a few options available to you as your requirements are filled by quite a few protocols, I am not going to list all. You can use things such as I2C, CAN, RS-485, RS-232.

You can find a few good examples from this EE.SE post from a search.

The CAN option is quite a good one for your application and is easy to set up and there are quite a few libraries available for the common chip MCP2525 and MCP2551. Yo can also get a 'shield' with this functionality from sparkfun.

The other options are discussed in the linked EE.SE post with regards to RS-485.

I2C can be implemented with the Wire library of arduinos and other libraries.

You can use RS-232, but I don't think it will be immune to noise at the distance you want, but you can still try. What you can do is use a multiplexer, such as this one CD74HC4067, and use it to multiplex the TX line from each node to the RX of the master.

From SFE's site:

For example, you could use it to connect the TX pins of 16 devices to one RX pin on your microcontroller. You can then select any one of those 16 devices to listen to. If you want two-way communications, you can add a second board to route your microcontroller’s TX line to 16 device’s RX lines. By using multiple boards, you can create similar arrangements for I2C, SPI, etc.

You will probably want to add some sort of checksum/CRC to the data you send over the network too.


IMHO you should first decide your network topology.

If you want a "star" network, i.e. a network when every node is directly connected to the central one, you can use any protocol. Maybe even a multiplexed serial interface.

If you want a daisy chain interface or a bus one use can or RS485.

Personally I'd avoid I2C (it's good for on-board communication, but if the device is a few meters away the noise can break it).

My suggestion: use serial over half duplex RS485: you can get very low price physical interfaces. Since it is half duplex, only one can "speak", so the master first sends an address, then puts itself in listen mode and waits. The slave whose address was told puts itself in sending mode and sends the data.

This way you will have a bus (so you can simply attach a node to another node without having to place a wire till the masater) and you'll have a simple bus logic which will prevent the information to collide. And, most important, RS485 is very strong (up to 1km if I remember well).

CAN can (sorry) be simpler to use, since the anti-collision is "embedded" in the protocol, but it's a bit more complicated to use (you'll need a transceiver and to implement the whole logic in the microcontroller instead of using a dedicated peripheral like the serial interface).

  • Hello,Thanks for your answer,I am looking at a star network topology ( i don't want to have the complexity of collision management).It seem more complex than i thought because RS485 will require quite some component outside the micro-controller.I may have been naive thinking i could just code something in the micro-controller and they will talk together ( like I2C ). – Vincent Diallo-Nort Jan 15 '16 at 23:03
  • With a star network topology you will have to use N interfaces on the uC or a multiplexer. N interfaces are fine if N < 4-5, but if it is larger you will need a multiplexer. And if you use that, well, you will definitely need a sort of handshaking (you don't want to turn the multiplexer in the middle of a "packet"). So you will have to deal with something analogous to collisions. As for other hardware, RS485 transceiver are usually 8 pin ICs that do not require external components. And I2C is a bus network where you need handshaking (just one master and N slaves) so the problem remains – frarugi87 Jan 16 '16 at 16:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.