I’m building a bus with 6 sensors. Each sensor has its microcontroller. We call it a node. There will be a master micro which will communicate with all the nodes. 

Sensor -> Sensor microcontroller <-> Master microcontroller 

The idea is to add more sensors in the future and to avoid the need to do a firmware upgrade in the field. 

Somehow there should be some auto addressing/IDs technique to deal with the different sensors and be flexible in case of adding more. Like some sort of plug and play mechanism. 

What communication scheme, firmware/hardware techniques would help here? I’m thinking of RS-485/Modbus or CANbus/CANopen. Modbus is master-slave and CAN is multi-master. CANopen may be overkill. I've heard of RDM protocol which uses the unique ID found in some microcontrollers. At the end I would go for one protocol which allows me to easily configure nodes. CAN actually has good features on collision and error management. Cable length and speed are not critical aspects. It’s a small system. I’m just trying to not overdesign.  Any suggestions?

I use the 9-bit UART RS485 protocol as discussed and referenced by Matthew. My 'nodes' are Arduino Nanos all connected to an Arduino Mega2560 which in turn is connected to a PC with a control application. The nodes are hard coded with an address which can be altered remotely if desired and stored in EEPROM. Each drop will handle 32 nodes giving a total of 96 possible connection off the Mega. Works fine.

As others have mentioned, SPI is a really nice interface and quite faster that I2C.  However it requires that you know ahead of time what will be the maximum numbers of devices you will ever need.  This is because it requires a select line, for each sensor, which must be physically routed on the board and routed to the connector(s).  I2C on the other-hand, can easily be extend by placing the address selection on each sensor board using a group of resistors.  In theory you can have 127 devices, of course real world will much less due to capacitance, but still quite a few.

The RS485 is a good choice also and can be extend like the I2C without adding additional wires.  When used in a master/slave mode, where the slave does not talk until spoken to, then collisions on the bus should not occur.  If you choose the right driver chips this can run high speeds such as 30 Mbps.  Although I would not recommend that speed for a MCU interface.

It's just my humble opinion, but CAN really needs MCU's that have a built in CAN Controller.  Otherwise the MCU is too busy handling the communications protocol.  If you have a built in CAN controller then it does perform well, but as you have alluded too, it seems a little heavy for this scenario.

Been doing I2C since before uCs had the module, but my colleague favored SPI. A recent project finally pushed me to SPI for low latency.

If the chips used have onboard addressing then 1 select line can choose N chips. An MCP23S08 has 2 onboard so 1 select allows 4 devices. One trick to this is you Must enable on chip addressing First. THEN you can initialize each chip for I/O assignments etc.  G.H. <<<)))

I've seen something similar with SPI, which is probably what I would try to use today on first glance, mainly because it is nice to have the master provide the clock, which might be useful if those sensor microcontrollers need to change in the future. That being said, the Barr article below points to some of the downsides on the slave side. I've always been on the master side of that equation, so interesting to think about that further.

Obviously CAN is widely used so will have a great deal of support.

This looked like a decent overview of CAN vs SPI:

https://barrgroup.com/embedded-systems/how-to/can-...

I also designed a similar system early in my career using a multi-drop 9-bit protocol UART, where the 9th bit indicated an address byte. Kinda like this: https://www.electronicdesign.com/technologies/embe...  In that case, make sure the UART component in the microcontroller supports such a protocol, especially if you can get an interrupt only on a matching address byte, that helps reduce CPU usage, etc. In this case, the bus itself provided the address based on which slot a slave was plugged into. The master was then configured with the new slave address, etc, via a higher level system configuration tool.

Good luck!

Matthew

https://covemountainsoftware.com/services/consulti...

Have you given I2C any thought. This network is somewhat like SPI. I haven't used SPI lately, but I can't help but think that it involves setting Chip Select signals to choose which node is being addressed. I2C includes the target node address in the packet as a part of the preamble. You send a node address, a command and data (if required) and get a response. 

You can hang more than enough nodes to the network. The connections are CLOCK, DATA and GROUND.

I've used the STM and MicroChip libraries for I2C. MicroChip is just slightly easier to implement.

It is possible to use spi transport with an i2c type addressing mode, instead of dedicated select lines.

I agree with your comment on CANopen. MODBUS is straightforward but plug-and-play is problematic because the single Master must initiate all communications. You plug in a new slave and it just sits there.

You might consider a MODBUS-like "roll-your-own" packet format and protocol on top of CANbus. You need some way to create unique slave addresses. Some processors or devices have a guaranteed unique device identifier pre-programmed at the factory, this can be a handy source of unique slave addresses.

One exception to strict master-slave ala MODBUS might be an advertising message from the sensor when it is not getting polled by the master, it could advertise its presence and slave address to get polling started. The master can dynamically acquire and maintain its list of sensors. A nice aspect of CANbus controllers is that they will retransmit in the event of a collision, so if an advertising message collides with a poll to another slave it will resolve.

Given unique sensor addresses, it isn't hard to devise a scheme to stagger advertising request timing so that it resolves quickly at bus power-up.

All good suggestions so far. Since speed isn't an issue I2C would be a candidate, but SPI is Much faster. Since you have a micro per node, you can just assign addresses at build time and increment as new ones are required. The max number of nodes will guide protocol choice: embedded in protocol itself or as part of data packeting. There's really no wrong choice, just degrees of ease and flexibility. You haven't mentioned robustness or latency considerations. Good Hunting.. <<<)))

If full-duplex communication is a must, I'd go for UART which needs fewer wires than SPI. Since CAN and I2C are semi-duplex interfaces they are limited to question-answer like transactions. CAN is robust with its protocol, any micro with HW CAN support would be a good choice.

Fully automatic addressing like plug-anywhere-and-off-you-go can be a tricky piece of job. Especially if the nodes can be hot-swappable. The unique ID of each node is inevitable in this case. Secondly some functionality sort of periodic checking and registering at the master side will be necessary.

Have you considered AS-Interface ( https://en.wikipedia.org/wiki/AS-Interface )?