Introduction to CAN
CAN Introduction
The CAN (Controller Area Network) is an ISO defined serial communications bus that was originally developed during the late 1980's for the automotive industry. Its basic design specification called for a high bit rate, high immunity to electrical interference and an ability to detect any errors produced. Not surprisingly due to these features the CAN serial communications bus has become widely used throughout the automotive, manufacturing and aerospace industries.
The CAN communications protocol describes the method by which information is passed between devices. It conforms to the Open Systems Interconnection model which is defined in terms of layers. Each layer in a device apparently communicates with the same layer in another device. Actual communication is between adjacent layers in each device and the devices are only connected by the physical medium via the physical layer of the model. The CAN architecture defines the lowest two layers of the model: the data link and physical layers. The application levels are linked to the physical medium by the layers of various emerging protocols, dedicated to particular industry areas plus any number of propriety schemes defined by individual CAN users. Perhaps the best example of an industry-standard CAN-based protocol is Allen-Bradley's DEVICEnet, designed for the networking of PLCs and intelligent sensors.
The physical medium consists of a twisted-pair with appropriate termination. In the basic CAN specification, it has a transmission rate of up to 250 KBaud whilst full CAN runs at 1 MBaud.
The physical and data link layers will normally be transparent to the system designer and are included in any component that implements the CAN protocols. There are some microcontrollers with integral CAN interfaces, for example, the 8051-compatible Infineon C505C processor and the 16-bit SAB-C167CR. The 81C91 is a standalone CAN controller which directly interfaces to many microcontrollers. The connection to the physical medium can be implemented with discrete components or with the 82C250 integrated circuit or similar. Standalone CAN controllers are also available from Infineon, NEC and Intel.
Traditionally, CAN has been a network for coupling microcontroller-based devices meaning the cost per node is not particularly low. An interesting development is the concept of a "SLIO" module. This is a single chip which can act as a dumb input/output gateway on a CAN network, able to turn messages into real digital IO signals. It can also read IO pins and transmit the data as message plus use an integral A/D convertor to generate messages for introduction into a network. These devices are extremely cheap and are ideal for driving remote sensors, actuators or gathering digital and analog data. They can be viewed as remote add-ons to a central microcontroller. Currently, only basic CAN SLIOs are available but undoubtedly Infineon and other full CAN specialists will produce full CAN equivalents.
CAN has exists in two forms; a basic CAN and a higher form with an "acceptance filter". Basic CAN has a tight coupling between the CPU and the CAN controller, where all messages broadcast on the network have to be individually checked by the microcontroller. This results in the CPU being "tied up" checking messages rather than processing them, all of which tends to limit the practicable baud rate to 250 KBaud. The introduction of an acceptance filter masks out the irrelevant messages, using identifiers (ID) and presents the CPU with only those messages that are of interest. This is usually referred to as "Full CAN". Philips is the leading proponent of basic CAN whilst Intel and Infineon only subscribe to full CAN. The Full CAN protocol allows for two lengths of identifiers: part A allows for 11 message identification bits, which yield 2032 different identifiers (16 are reserved), whilst extended CAN (part B) has 29 identification bits, producing 536870912 separate identifiers.
Part A devices such as the Philips PCA82C200 are only able to transmit and receive standard CAN protocol. Used on an extended CAN system in which 29 bit IDs are present, the device will cause errors and crash the entire network. The Infineon 81C90 and 81C91 are similarly part A devices (11 ID bits), but have the ability to be used with extended CAN without causing no bus errors. This is achieved by simply ignoring the extended CAN frames and are thus known as "part B passive" devices. The data-link layer defines the format and timing protocol with which the messages are transmitted. There are two descriptor bytes and up to eight data bytes. The descriptor bytes are particularly important as they define the priority of the message and the type of message being transmitted.
The identifier field contains 11 bits and is used for identification of the message as well as for determining its bus access priority. The priority is defined to be highest for the smallest binary value of the identifier. The allocation of priorities to messages is a feature of the CAN bus that makes it particularly attractive for use within a strongly real time control environment. All the bits of the identifier field define the message priority. This means that messages can have a priority number between 16 (high priority) and 2032 (low priority) in an 11-bit system. The CAN specification guarantees the latency time associated with priority values.
Coping With Message Collisions
As has been said, a fundamental CAN characteristic is that the lower the message number, the higher its priority - a identifier consisting entirely of zeros is therefore deemed to be the highest priority message. Thus if two nodes begin to transmit simultaneously, the first source to send a zero when the other source attempted a one, gets control of the CAN bus and goes on to complete its message. This use of "non-destructive bitwise" arbitration is coupled with the capability of each node to able to monitor its own transmissions. Thus if a transmitter 'A' is overruled by a source 'B' sending a higher priority message, the fact that the message read back does not match the message that 'A' attempted to send means that it will temporarily halt. Another attempt will subsequently be made to send it once the bus is released. This functionality is part of layer 1 and is contained entirely within the CAN controller device. It is therefore transparent to the CAN user.
It is possible to send a request for data to a specified address, and the remote transmission request (RTR) bit defines whether the message sent is a request for data or the actual data. The data-length code tells the receptor how many data bytes the message contains. In the case of data requests, no data bytes follow and therefore the data-length code has no direct relation to the number of data bytes.
The maximum number of nodes on a CAN bus is typically 32 but the ultimate number is determined by the characteristics of the physical layer employed. The limit of messages per second ranges from about 2000 to about 5000 on a bus with 250 KBaud transmission rate, depending on the number of bytes per message.
CAN may use a number of physical media such as twisted wire-pairs, fiber-optics etc.. As long as the physical drivers are basically "open collector" and each node can hear itself and all others, then CAN should function. The commonest method is the twisted pair. The signalling is carried out using differential voltages and it is from this that CAN derives much of its noise immunity and fault tolerance. The two signal lines are termed 'CAN_H' and 'CAN_L' and in the quiescent state, sit at 2.5V. A logical '0' is denoted by CAN_H being above CAN_L and as such is termed a 'dominant' bit whilst a logical '1' has CAN_L just above CAN_H, yielding a 'recessive' bit.
The use of voltage differentials allows CAN networks to function when one of the signaling lines is severed, or in extremely noisy environments. With a simple twisted pair, the differential CAN inputs effectively cancel out noise, provided it is within the common mode range.
Cheap interfaces are available from Siliconix amongst others, which translate from 5V logic levels to the balanced line required by CAN.
Customising CAN To Specific Industries
The allocation of message numbers (and hence priorities) is up to the individual user but as has been indicated, certain industry groups are mutually agreeing the significance of certain messages and the exact protocol to be used. For example, manufacturers of motor drives might decide that message 0x10 is the winding current feedback signal from any motor on a CAN network and that 0x11 is the tacho speed. As 0x10 has a zero before 0x11, messages relating to current values will overrule those concerned with tacho readings.
In the case of DEVICEnet, PLCs from various manufacturers can be linked together. Peripheral devices such as pressure and temperature sensors can be added to the CAN network. As the messages generated by the sensors has been pre-defined, the PLCs will know that a certain message always relates to temperature, regardless of who actually manufactured it.
Situations Where CAN Is The Solution
CAN is ideal for any situation where microcontrollers need to communicate either with each other or with remote peripherals. In its home environment, the car, CAN was originally used to allow mission-critical real time control systems such as engine management systems and gearbox controls to exchange information. Here, CAN's short and guaranteed message latency times allowed each end of the network is working with current data, even where this may be changing on a hundreds of microsecond time-scale. These systems all utilize full CAN in that the CAN controllers filter out unwanted messages to reduce the host CPU load. However, the appearance of low-cost standalone full CAN devices such as the Infineon 81C91 has allowed less time-critical tasks such as door systems (window lifters, mirror controls etc.) to become part of the CAN network. Indeed, the entire conventional wiring harness has been replaced in some instances by two-wire CAN networks in which even mundane devices such brake lights and indicators are just additional nodes.
In the meantime, basic CAN with 11 bit identifiers has become widely accepted as a general purpose network in the industrial control field. Developed and promoted mainly by Philips it allows very simple communication between microcontrollers and peripherals at up to 250 KBaud. Indeed, the cheap SLIO device can provide up to 16 IO pins which may be assigned as up to 6 channels of 10-bit A/D or D/A, plus ordinary IO pins. SLIOs have unique identifiers, set via external resistors. Thus they can recognize messages intended for them and generate messages based on inputs received.
Industrial applications can also benefit from full CAN at 1 MBaud by using full-CAN equipped microcontrollers from Infineon and Intel who also produce add-on CAN controllers for ordinary microcontrollers. However, the basic philosophy of full CAN is that it should be reserved for very high speed data interchange between microprocessing units rather than communication down to a low-speed IO port level.
The CAN Bus Protocol In Detail
The CAN bus was designed as a multi-master architecture with a maximum transfer rate of 1Mbit/sec. Unlike a traditional network, CAN does not send messages point to point i.e. from node A to Node B. In a CAN message it is the data not the node that is given an identifier; the message is broadcast to the network and any node that is interested in the message can pick up the data. For example in a car, one node may be transmitting wheel speed. This data may then be picked up simultaneously by the ABS unit, the instrument cluster and the engine management system, who will have no knowledge of where the information came from.
Typically in an embedded system, it is necessary to transmit a small amount of important data which must arrive within a critical timeframe in contrast to non real time networks such as file transfer as in a PC LAN. Consequently, the CAN message packet allows a maximum of eight bytes of data to transferred and the method of bus arbitration ensures that an important message will arrive within a guaranteed time slot.
CAN has been specifically designed to work in electrically harsh environments where messages may be lost or corrupted. The CAN protocol implements five methods of error detection and correction so that if a message is corrupted, this will be detected and the message ignored by all nodes on the network; it will subsequently be retransmited until it is correctly received.
From a designers point of view, a major attraction of the CAN protocol is that the whole protocol is implemented on a chip and to a programmer, it looks like a considerably enhanced multi-channel UART. All of the error detection transmission and reception techniques are carried out transparently by the CAN controller chip in hardware.
A typical CAN node will have a microcontroller with a dedicated CAN controller memory mapped into its external address bus. Some controllers are designed to interface either as parallel devices on the address bus or by serial interface onto a controller UART or even a couple of port pins.
The CAN controller is interfaced to the bus with a line driver. Typically, the bus will be a twisted pair, terminated at either end with a 120 Ohm resistor. The CAN transceiver has both a transmit and receive side, so that it may both write and read to the bus simultaneously. This capability is important for both error detection and bus arbitration. The CAN transceiver and physical layer is not defined by the CAN specification but as long as it meets the above requirement, any implementation may be used such as RS485 drivers or OP AMPS. A dedicated CAN driver chip is available from Philips, Siliconix and Texas which implements the CAN transceiver is a available in an 8 pin surface mount or DIL package.
On the CAN bus there are four communication objects: a message frame which contains the application data, a remote frame which requests data from the network, an error frame which reports errors each node and an overload frame which is used to delay transmission of a CAN frame if the receiver circuitry of a node is not ready.
The message frame has a “start of frame” field followed by an identifier. The identifier can be either 29 bits long (extended CAN or CAN 2.0B) or 11 bits long (CAN 2.0A). When a message is received by a node, this identifier, depending on the make of CAN controller being used, will be compared to an acceptance filter or to a table of user-defined identifiers within the CAN controller. If the identifier passes the acceptance filter or matches an identifier in the table, it will be received by the node and an interrupt generated for the CPU. Thus the same message can be received by as many nodes as the designer requires. The Identifier is also used as the arbitration field and the lower the identifier number, the higher the priority of the message. The identifier is followed by the control field which contains the data length field where the DLC specifies the number of bytes contained in the data field - the RTR field will be discussed shortly. The remaining fields are generated by the CAN controller and include a 15 bit cyclic redundancy check carried out over the preceding fields plus an acknowledge slot.
The acknowledge slot is a gap in the message packet which allows a node which has correctly received a message to assert an acknowledge. This tells the transmitter that the message has been correctly received. If the transmit node does not get an acknowledge, it will continue to retransmit the message.
The remote request frame is a truncated form of the message frame. It is used to request data from the network. The identifier of the data required is transmitted with the remote transmit request (RTR) bit set. The node with the matching identifier will then transmit a message frame with the data requested. It is important to note that the DLC in the remote frame is not zero but is set to the length of the expected number of bytes of data to be received. Typically, the remote frame is used in networks with a low bus loading where a master will poll the network for data. This simplifies the overall design of the system and avoids collisions on the bus.
Both of the above frames are subject to bit stuffing rules whereby if there is a sequence of more than five ones or zeros, a bit of the opposite polarity is inserted to prevent a net DC level. The error is a violation of this rule. We will examine error handling after examining how bus arbitration works.
The CAN bus physical layer is normally a twisted pair. When a logic ‘1’ is written to the bus, the two wires sit at 2.5V and is termed a “recessive” bit. When a logic ‘0’ is written to the bus, one wire is pulled to 5V (CAN high) and the other is pulled down to ground ( CAN low). This is called a ”dominant” bit. If a dominant bit and a recessive bit are written to the bus at the same time by different nodes, a dominant bit is asserted on the bus, so that a dominant bit overules a recessive bit and is the basis of collision detection within a CAN network.
When the nodes start to transmit their respective messages, each bit of the identifier is written onto the bus and also read back by each node. If a node writes a recessive bit but reads back a dominant bit, it knows that another node with a lower identifier number (and higher priority) is accessing the bus. It will stop transmitting its message and continue to receive the more important message. This technique is called non-destructive bitwise arbitration. It ensures that if a high priority message is sent, it will win arbitration and get to its destination nodes within a guaranteed time frame, controlled by the system designer. It should be noted that if two nodes send data using the same identifier, both will get arbitration on the bus and start to transmit data. At some point, the data will differ and generate an error. Both nodes will then back off and then retransmit restarting the whole process; in extreme cases, this can lock up the network!
The CAN protocol has five methods of error checking; three at the message level and two at the bit level. If a message fails, any one of these error detection methods at a given node it will not be accepted and an error frame will be generated which will cause all of the frames to ignore it and the transmitting node will resend the message.
At the message level, we have seen the CRC check and the acknowledge slot. The CRC check is a 15 bit CRC carried out over the Descriptor fields and the Data bytes. The acknowledge field is two bits long and consists of an acknowledge bit and an acknowledge delimiter bit. The transmitter will place a recessive bit in the acknowledge field. Any node that receives the message correctly will write a dominant bit in the acknowledge field. Unless the transmitter reads back a dominant bit in the acknowledge field, it will generate an error frame and retransmit the message. Finally, at the message level there is a form check. This check looks for fields in the message which must always be recessive bits. If a dominant bit is detected then an error is generated. The bits checked are the start of frame, end of frame, Acknowledge delimiter and the CRC delimiter bits.
At the bit level each bit is monitored by the transmitter. If a bit is written onto the bus and its compliment is read an, error is generated. The exceptions to this rule are the identifier field, which is used for arbitration and the acknowledge slot, which requires a recessive bit to be overwritten by a dominant bit. The final method of error detection is via the bit stuffing rule. When a message is de-stuffed, if after five consecutive bits of the same logic level the next bit is not a compliment, then an error is generated.
The active error frame consists of six dominant bits which is a violation of the bit stuffing rule and is interpreted as an error by all of the CAN nodes which will then generate their own error frame so that an error frame can be from six to twelve bits long. The error frame is followed by a delimiter field of eight recessive bits and a bus idle period before the corrupted message is retransmitted. It is important to note that the message will still have to contend for arbitration on the bus before it can be successfully received.
CAN was originally designed for automotive systems where a bus length would typically be around 5 to 10 metres. However since CAN is now finding its way into many systems where an increased bus length is required, the ultimate transmission range is of increased interest. The standard drivers will be able to drive a bus up to around 1 kilometre. The above table gives an idea of the expected transfer rate versus transmission length.
Despite its relative youth, CAN is already supported by a huge range of development tools. These range from simple development boards to full scale CAN analyzers. PHYTEC of Mainz in Germany produces a wide range of CAN-equipped microcontroller boards based on the C500 and C166 architectures. These comprise microcontroller + external CAN controller (Infineon 81C91) or CAN microcontroller-only (C505C, C515C). The boards can be programmed in C or assembler and can host state-of-the-art debuggers such as Hitex's HiTOP. PHYTEC also offers small SLIO modules.
Softing of Munich produce a range of CAN tools and interfaces. These include CAN-PCMCIA and VME slots plus a full CAN analyzer, based on a conventional PC card or a miniature PCMCIA module - ideal for CAN debugging in the field.
Being so tightly coupled to microcontrollers, existing tools such as in-circuit emulators are able to provide useful facilities such as real time monitoring of input and output data to CAN controllers, whether on-chip or off-chip.
We hope this gives you some idea what CAN is and how it is used. If you want to know more, please contact Trevor Martin at Hitex.
