5
\$\begingroup\$

I am investigating if the CAN bus will work for the projects I am building at the moment.

I want to create a bunch of input/output controllers that will accept/buffer commands, execute them and then report back progress. My feeling is that a master and slave setup will not work best for project, but I am not sure if the CAN bus works on that principle.

\$\endgroup\$
  • \$\begingroup\$ This is all clearly answered in the CAN protocol spec, and even in the datasheets of most microcontrollers that have CAN peripherals. What part of the spec specifically are you confused by? \$\endgroup\$ – Olin Lathrop Apr 16 '14 at 19:58
10
\$\begingroup\$

A CAN bus is multi-master and automatically arbitration free. The whole point is that you don't need a single master or main controller to take care of everything. Each message that is sent has a priority, and higher priority messages trump lower priority ones (a lower priority message will wait until there isn't a high priority message being sent). So there are no slaves. It's kind of similar to a peer to peer network, in that it's decentralized. The reason this is done is to reduce failure points. If a single main controller failed, so would the entire network. If there is no central controller, a single component can fail and the rest of the system will keep going.

For your network, you should assign priorities to each command sent depending on what's most important. The Wikipedia article is actually quite good: https://en.wikipedia.org/wiki/CAN_bus

\$\endgroup\$
  • 1
    \$\begingroup\$ I'll mention (as it's counter-intuitive) - due to the way the CAN physical layer is set up - low-numbered identifiers have highest priority. \$\endgroup\$ – Martin Thompson Apr 16 '14 at 10:34
2
\$\begingroup\$

CAN only has masters. One node transmits at a time - if multiple nodes being a transmission at approximately the same time, they will collide, and the node transmitting the lowest ID will win arbitration. The other nodes will listen to the winning node's message and then after some backoff time re-try their own transmissions.

And of course, there's nothing to stop you building some kind of master/slave protocol on top of the low-level message-moving that CAN provides you with.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the clarification. Silly question... Am I correct that each node does not have an Unique Address ID like I2C? And that they can send messages with any id and react to any message ID's as per the logic you apply in the MCU code you write? \$\endgroup\$ – Bertus Kruger Apr 16 '14 at 22:28
  • \$\begingroup\$ Yes, that's spot on. \$\endgroup\$ – Martin Thompson Apr 17 '14 at 9:19
2
\$\begingroup\$

CAN is a low-level protocol, somewhere around the data-link layer of the OSI model (layer 2). Thus it is only concerned with transferring generic data frames. CAN does not specify a network topology, nor how data gets passed around, nor the nature of the data etc etc.

So CAN is not a master/slave protocol for the same reason as UART isn't one.

On top of the standard CAN protocol frames, you need higher layers that define the communication. The far most common ones for CAN are:

  • CANopen (most common, generic)
  • DeviceNet (generic, mainly used in the automotion industry)
  • J1939 (trucks, tractors, heavy vehicles)

These work in entirely different ways.

CANopen for example, doesn't define a master as far as the data traffic is concerned. Data communication between nodes on the bus is only a concern of the nodes involved: there is no master directing data traffic and every node can be configured to speak/listen to any other node.

But CANopen does define a "network manager" master, who is in charge of supervising the nodes on the bus: making sure they start correctly and remain alive and functional etc.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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