Identifiers
Unlike ‘node-oriented’ or peer-to-peer messaging, where a message is transmitted between two specific nodes, the transmission of messages via CAN is based on the so-called ‘producer-consumer’ or broadcast principle. A message sent by one node is received by all other CAN nodes.
To achieve this, messages are not assigned a delivery address as in physical addressing, but instead an unambiguous message identifier; CAN therefore uses functional addressing. Sending messages to all nodes in a network is also known as ‘broadcasting’.
In the standard CAN protocol, messages normally have an 11-bit identifier. This means that 2,048 different types of message can be defined within a system. This is more than sufficient for most applications.
In order to make CAN available for the SAE J1939 standard at the time, the extended frame was added. This uses 29-bit identifiers, thereby offering the possibility to define more than 512 million different messages.
Every node can send messages and can use any identifier (=Id) for this purpose. IDs are therefore not the exclusive property of a particular node. As already indicated, all other nodes receive this message. What a typical ID signifies is entirely up to the application itself, and thus the underlying software.
If desired, for example, certain IDs could be interpreted by just one node; the other nodes would, of course, also receive the message, but would take no action on it. In this way, for instance, physical addressing can be emulated via software.
Incidentally, a node can program the CAN controller in such a way that only certain, desired IDs are passed on to the microcontroller. In this way, a node can filter relevant messages from the message stream on the bus. To this end, the CAN controller chips provide mechanisms – known as acceptance filters – which are implemented in hardware. These mechanisms are primarily intended to prevent smaller microcontroller systems, with limited processing capabilities, from being overburdened with too many unnecessary messages.
Standard and Extended frames may be used interchangeably. They are also unrelated to one another. Id=000hex (11-bit) is a different identifier from Id=00000000hex (29-bit).
Multimaster
Any node within a CAN network can begin transmitting a message as soon as the bus is free. The node transmitting a message is referred to as the Master whilst the transmission is in progress. The other nodes, which receive this message, are the Slaves at that moment. There can only be one Master at any given time. If more than one node within the network simultaneously wishes to initiate the transmission of a message, an arbitration process is required. This process ensures that only one node actually becomes the Master and sends a message. This is always the node wishing to transmit the lowest ID.
As soon as another node subsequently wishes to send a message, it becomes the Master. The original Master then reverts to being one of the listening slaves. Because every node can send messages, direct message transmission between all nodes within the network is also possible, without the need for centralised control or coordination. Consequently, it is also possible to send messages only when necessary, that is, when a relevant event has occurred. Compared with cyclic message transmission, this results in a significantly lower bus load or a reduction in the required data transmission rate.
Data bytes
A CAN message can contain a maximum of 8 data bytes. This means that a message may also contain no data bytes at all.
In principle, the number of data bytes sent in a message with a specific ID can vary. The CAN standard permits this, but some CAN controllers do not. These typical controllers operate with a kind of dual-memory system in which all CAN messages to be processed are predefined. This is set during start-up and cannot be changed.
Remote Request
In addition to the data frame described above, a CAN node can also send what is known as a Remote Request frame (RTR). A Remote Request is, as it were, a request for a specific CAN message. The intention is that the node which ‘owns’ the relevant CAN ID should, in response to an RTR, send a CAN message containing the desired ID and current data. RTR messages can be useful for data which, for example, is rarely or never sent, or for nodes that join the bus later and wish to be up to date.
Some CAN controllers store the current data for the CAN IDs they are capable of transmitting internally. Such CAN controllers can respond autonomously to an RTR. For other CAN controllers, the software must handle an RTR.
