Some notes about the bus signals

CAN bus needs the terminators fitted to the cabling.  If not the signals you see with a scope on the RX side of the transceiver will be wrong!

The CAN bus TX line (pre transceiver) idles high.  

The CAN bus RX line (pre transceiver) see's everything you TX too (it needs to, to be able to detect collisions).

If you have only 1 CAN bus device and you TX something that TX will repeat continuously if viewing on a scope even though you only sent 1 message.  This is because the CAN peripheral expects the message to be acknowledged by at least 1 receiver on the bus.

Deciding On A Protocol

All messages on a CAN bus are broadcast with receiving nodes deciding if they want the data.  It is quite normal for more than one node to act on data passed over a CAN bus by another node.

If there are no errors with a message sent by a node all other nodes will “ack” the message (the transmitter will know that at least one receiver validated the message).

You could have a single master based protocol where a master requests messages from slaves, but there is no need to.  A protocol can instead be based on nodes broadcasting their information as and when they decide to.

Individual nodes must have a unique ID on the bus to allow arbitration to happen (and avoid errors).  When more than 1 node transmits at the same time the node with the lowest ID will always win the arbitration (has the highest priority).  Deciding on IDs to use:

A node transmitting with a lower ID will win arbitration.

Your CAN RX handler will likely have a message acceptance filter and a mask to determine which ID's are received and which are ignored:

Filter bits specify bits that must match the specified pattern.

Mask bits specify bits which can be anything.

You may have more than 1 pair of filter and mask registers to allow you to setup different receive options.

Using this you can specify message / node types within the IC as well as a nodes unique ID/address.

So, thinking this through for an addressing scheme:

ID 0x0001 is higher priority than 0x0100

​If you, say, use left (higher) bits to act as the filter of what nodes will receive or ignore (e.g. message type), and right side bits to let you work out what node ID sent a message you want to receive (e.g. the nodes address), then you get to specify the priority of message types.

E.g. you could have bits 10:8 specify message / node type, bits 7:0 to specify a nodes unique address. The receive mask is set to ignore bits 7:0 and you set the filter for bits 10:8 to match the specific message type you are interested in and want to receive. Message types with a lower value in bits 10:8 will be higher priority, regardless of the lower bits being used for the sending nodes address.