CAN bus 2-way communication methods?

[GigaNerdTheReckoning]

Hi,

I wanted to get some information on the CAN bus (control area network), when communicating between 2 or more Arduino's bi-directional, as there isn't much information I can find online.

I don't have a specific project in mind for it, it's just out of interest for now.

I have read that if 2 MCU's in a CAN network attempt to send a message to each other at the same time, and they collide, the node with higher priority gets to send their message first, and once their message is sent, the lower priority node will get to send their message.

Does this then mean that you could have 2 or more Arduino's communicating with each other, in both directions, without the need to ensure that there's only 1 node as a transmitter, with the rest as receivers, at a given time?

For example, In a 3 node network; Node 1 can send something (lets say 10 bytes) directly to node 3, and node 2 can send something (e.g. 5 bytes) directly to node 1, without the need for additional programming to ensure that there's only 1 transmitter, at any given time.

If there is a collision, then if node 1 has a higher priority than node 2, node 1 will send its message first, and then node 2 will send its message once node 1 is finished.

If that doesn't actually work very well, what would be some another ways to program the 2-way communication in a CAN bus network?

This would differ from a communication method I've seen used in an RS485 network (I think it's called a star topology), where there is a single master, which makes a request for data from only 1 slave in a queue at a given time, and then requests data from the next slave in the queue, and so on, and then returns to the start of the queue once all the slaves in the queue have been requested, and repeats. That allows for only 1 transmitter (and the rest as receivers) at a given time.

Thanks.

[mikb55]

In simple terms it's like a "food fight". If you aren't familiar with the term it's a bit like this video

FOOD FIGHT AT BELMONT HIGH SCHOOL!!!! (Security Camera Footage)

The job of the CAN controller if to pickup whatever is on their plate and fling it around the room as fast as possible, subject to the rules surrounding prioritization and collisions.
You as the programmer pickup whatever food lands on your table and then you decide if it's worth eating or should be discarded. From time to time you puts more food on the plate for the CAN controller to throw.

Whatever gets thrown always lands on all tables, so there's no selectivity, you cannot target a particular table.

[gilshultz]

Good job, you have most of it figured out. CAN is a multiple access, carrier detect, non destructive arbitration bus. The bus has two modes besides broken, active (dominate) and passive (recessive). Let's make it simple, our interface module is a transistor (open collector logic or configuration) and a resistor on each end of the bus. Each transistor represents a bus driver. There is also a connection from the bus to an input pin on the bus to the controller allowing it to monitor what it is sending. Draw several of these and all of the collectors go to the bus which has a pull up. With all of the transistors off the bus is in the recessive (off) state. If any of the transistores turns on they place the bus in the dominate state (active). There is no limit or order to how many come on. CAN normally does logically exactly the same thing with a special driver using a differential bus.

Before transmitting the unit(s) one or more monitor the bus and if there is no activity they start sending their message (others can try as well nothing to stop them. The priority etc is now determined by who is left. Each unit asserts one of two states, dominant or recessive (part of the CAN header and message) if it does not see what it is trying to send it shuts up, goes away, and tries again later. At the end only one will get through. As long as the bits match they will keep sending however when one is sending a recessive bit and the other a dominate it shuts up letting the dominant one continue. This process is very deterministic and keeps from destroying the message.

All modules receive all transmissions and all can transmit, there is no master of slave, just priority. The messages can be targeted to a specific device or broadcast to a group of devices, this is in the protocol. The arbitration part of the protocol will separate the higher priority unit. It is possible if there is a lot of bus traffic some low priority message will take time before it actually can be sent.

Partway through the message there is a time slow that another unit on the bus, not the transmitter must acknowledge the message. That confirms the connection is correct and more. The transmitting unit places the bus in the passive state during this bit time and the acknowledging unit places it in an active state. Any unit other then the transmitter must ACK the message or it fails. There is nothing responds telling the sender that the message was received by the intended target, that has to be part of user software.