The CAN Protocol Tour
		CAN Messages page 3 of 3
		Basic CAN vs. Full CAN The terms "Basic CAN" and "Full CAN" originate from the childhood of CAN. Once upon a time there was the Intel 82526 CAN controller which provided a DPRAM-style interface to the programmer. Then came along Philips with the 82C200 which used a FIFO- (queue-) oriented programming model and limited filtering abilities. To distinguish between the two programming models, people for some reason termed the Intel way as "Full CAN" and the Philips way as "Basic CAN". Today, most CAN controllers allow for both programming models, so there is no reason to use the terms "Full CAN" and "Basic CAN" - in fact, these terms can cause confusion and should be avoided. Of course, a "Full CAN" controller can communicate with a "Basic CAN" controller and vice versa. There are no compatibility problems. Bus Arbitration And Message Priority The message arbitration (the process in which two or more CAN controllers agree on who is to use the bus) is of great importance for the really available bandwidth for data transmission. Any CAN controller may start a transmission when it has detected an idle bus. This may result in two or more controllers starting a message (almost) at the same time. The conflict is resolved in the following way. The transmitting nodes monitor the bus while they are sending. If a node detects a dominant level when it is sending a recessive level itself, it will immediately quit the arbitration process and become a receiver instead. The arbitration is performed over the whole Arbitration Field and when that field has been sent, exactly one transmitter is left on the bus. This node continues the transmission as if nothing had happened. The other potential transmitters will try to retransmit their messages when the bus becomes available next time. No time is lost in the arbitration process. An important condition for this bit-wise arbitration to succeed is that no two nodes may transmit the same Arbitration Field. There is one exception to this rule: if the message contains no data, then any node may transmit that message. Since the bus is wired-and and a Dominant bit is logically 0, it follows that the message with the numerically lowest Arbitration Field will win the arbitration. Q: What happens if a node is alone on the bus and tries to transmit? A: The node will, of course, win the arbitration and happily proceeds with the message transmission. But when the time comes for acknowledging... no node will send a dominant bit during the ACK slot, so the transmitter will sense an ACK error, send an error flag, increase its transmit error counter by 8 and start a retransmission. This will happen 16 times; then the transmitter will go error passive. By an special rule in the error confinement algorithm, the transmit error counter is not further increased if the node is error passive and the error is an ACK error. So the node will continue to transmit forever, at least until someone acknowledges the message. Message Addressing And Identification It is worth noting once again that there is no explicit address in the CAN messages. Each CAN controller will pick up all traffic on the bus, and using a combination of hardware filters and software, determine if the message is "interesting" or not. In fact, there is no notion of message addresses in CAN. Instead, the contents of the messages is identified by an identifier which is present somewhere in the message. CAN messages are said to be "contents-addressed". A conventional message address would be used like "Here's a message for node X". A contents-addressed message is like "Here's a message containing data labeled X". The difference between these two concepts is small but significant. The contents of the Arbitration Field is, per the Standard, used to determine the message's priority on the bus. All CAN controllers will also use the whole (some will use just a part) of the Arbitration Field as a key in the hardware filtration process. The Standard does not say that the Arbitration Field must be used as a message identifier. It's nevertheless a very common usage. A Note On The Identifier Values We said that 11 (CAN 2.0A) or 29 (CAN 2.0B) bits is available in the Identifier. This is not entirely correct. Due to compability with a certain old CAN controller (guess which?), identifiers must not have the 7 most significant bits set to all ones, so only the identifiers 0..2031 are left for the 11-bit identifiers, and the user of 29-bit identifiers can use 532676608 different values. Note that all other CAN controllers accept the "illegal" identifiers, so in a modern CAN system identifiers 2032..2047 can be used without restrictions.   << CAN Messages page 2 of 3 - (3/9) CAN Physical Layers - (5/9)>>