Atmel Microcontrollers for Controller Area Network (CAN)

By Michel Passemard, Industrial Control Business Development Director

Summary
Atmel has developed a family of CAN Controllers for the various applications that use this serial bus to interconnect Smart system. With its multi-master capability, built in error detection and correction capability, and large industry acceptance, the CAN bus is an attractive standard with a bright future.

Atmel Corporation 2325 Orchard Parkway San Jose, CA 95131 TEL (408) 441-0311 FAX (408) 487-2600 Web Site: http://www.atmel.com

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Table of Contents
Atmel Microcontrollers for Controller Area Network (CAN)................... 1 Background overview ............................................................................... 3 CAN Bus ..................................................................................................... 4
Controller ........................................................................................................................4 Physical Layer ................................................................................................................7

CAN Applications ...................................................................................... 8

Introduction.....................................................................................................................8 CAN in cars and truck engine control.............................................................................8 CAN in non-passenger cars vehicles .............................................................................8 CAN in maritime applications .........................................................................................8 CAN in avionics system network....................................................................................9 CAN in Factory automations, building automation and other industrial control .............9 CAN in Elevators, Automatic doors................................................................................9 CAN in medical equipments .........................................................................................10

CAN Higher Layers Protocols ................................................................ 11

CANopen detailed description......................................................................................11 Safety Bus ....................................................................................................................12

Atmel Solutions for CAN Networking ................................................... 14

5 MIPS Microcontrollers ...............................................................................................14 16 MIPS Microcontrollers .............................................................................................15 High Speed transceiver ................................................................................................16 Full System Solution.....................................................................................................17 Atmel CAN Offer summary...........................................................................................17

Conclusion ............................................................................................... 18
References ...................................................................................................................18

Editor's Notes .......................................................................................... 19

About Atmel Corporation ..............................................................................................19

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Background overview
Robert Bosch introduced the Controller Area Network (CAN) serial bus in 1986, for automotive engine control communication. Most of todays passenger cars have a CAN bus under the hood. Some also use CAN for body control also called Multiplexing. In the early nineties, two initiatives took place on both side of the Atlantic ocean. In Europe at Holger Zeltwanger initiative, the CAN In Automation (CiA) was created with many Manufacturers from different industries joining forces. Shortly after the CANopen higher layer protocol was defined as a framework for programmable systems. The CANopen communication profile paved the way for the multiple applications dedicated profiles that exist today. At the same time in North America Allen-Bradley and Honeywell teamed up to develop a CAN higher layer protocol for factory automation. The outcome of this initiative was the DeviceNet High Layer Protocol used in most of the factory automation systems in North America nowadays. DeviceNet is now supported by the Open DeviceNet Vendor Association (ODVA). The OSEK higher Layer Protocol has been adopted by the automotive industry. CAN OSEK is a prerequisite for system used by the big three: Ford, GM, Daimler Chrysler. Other specialty CAN higher layer protocols were developed too. Since year 2000, we can see the emergence of CAN in non-traditional applications (i.e. outside Automotive and Factory Automation). This is the result of smaller industries adopting a well proven standard for communications. Credit has to be paid to CANopen which offers a framework and CAN In Automation that promotes and facilitate such initiatives. The CAN deployment in Medical application and the CANopen in operating room are good examples. On a different note, vacationers in Las Vegas riding the monorail up and down the strip shouldnt be surprise to learn that their comfort and safety rely on CAN for the automatic door control. The next step in the CAN story is the definition and introduction of CAN Safety for critical applications. As explained later on in this document, inside a network the critical nodes will carry an extra layer (safety layer) while regular nodes on this given network will run standard CAN.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

CAN Bus
The CAN bus is a 2 wires serial bus with Multi-Master capability. This means that multiple devices sitting on a single 2 wires bus can talk to one another. CAN includes a CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Each device can transmit a message and will retry if it loses the arbitration to another device. Each device listen to the bus and thus a device trying to transmit can determine easily if the message ongoing is the same than the one it tries to transmit. If it is different, it will release the bus immediately. This arbitration mechanism insures that one master will always win, thus no messages will be lost to a collision. This mechanism differs significantly from Ethernet LAN bus. In Ethernet, a device trying to transmit a frame will monitor the line and wait until the line is available then starts transmitting. If 2 or more transmitters start, a collision will occur. All transmitters will stop. Each transmitter will then wait a random time interval before attempting a transmission again. In summary, there is a lost of time and frame transmission is aborted every time a collision occur on an Ethernet LAN. This explains why in most of todays Ethernet LAN applications, nodes are connected point to point to a Bridge or Router. To illustrate this point, lets take the example of a bottling line. On this lines, sensors will be deployed, conveyor will be moved by drives, Valves will be installed, scanners and Programmable Logic Controllers (PLC) will be deployed too. With a CAN implementation, one single cable will probably connect all devices while, with an Ethernet LAN implementation a star cabling scheme will be used to connect each device to a bridge. In CAN, errors are detected with a CRC check. Message are acknowledged at the end of the frame by a special acknowledge bit. Receivers assert the ACK bit acknowledge proper reception. With all the above, The CAN bus can offer a 100% data integrity in the harsh environment found in cars and manufacturing floors. The CAN robustness has a cost. All nodes are synchronized on the same bit time period. The group delay cannot exceed a fraction of the bit time period which lead to the maximum bus throughput being a function of the bus length. The maximum throughput is 1Mb/s with up to 40m bus length and 50Kb/s with up to 1km bus length. With point-to-point Ethernet LAN connection between a device and a bridge with a UTP5 cable 10Mb/s could be achieved up to 100m.

Controller
The CAN controller handles the delineation of incoming frames, and extraction of the various payload information carried by the frame. The CAN controller assembles the frames on the transmit side, then attempts to send it on the bus while monitoring it. It will drop the line if it loses the arbitration. The CAN message Frame format is described in the figure below.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Figure 1. CAN message Frame format

Bit Stuffing
SOF
ACK

del

Bus Frame
Duration in Data Bit

ARBITRATION

CTRL 6

DATA 064

CRC 15 RTR SRR RB0/1 DLC

del

EOF 7

IFS 3

12- 32 EOF IFS ID IDE

SOF Start of Frame CRC Cyclic Redundancy Code del Delimiter ACK Acknowledge

End of Frame Inter Frame Spacing Identifier Identifier Extension

Remote Transmission Request Substitute Remote Request Reserved bits Data Length Code

The arbitration mechanism is explained in the following figure. Figure 2. Arbitration mechanism
Start of Frame Arbitration Field Node 1: TxD Node 2: TxD Node 3: TxD CAN Bus

Node 2 loses Arbitration

Node 3 loses Arbitration

As we can see in the figure above, the node1 wins the arbitration and continues on with its message transmission while node2 and node3 wait the end of frame before re-attempting to send their messages. See below in the Physical Layer paragraph the description the dominant bit 0 / recessive bit 1 mechanism involved in the arbitration. Each messages start with an address field. As addresses are unique, the arbitration will be completed at the end of address transmission on the bus, and only one device will carry-on with the message transmission. CAN protocol have specified 2 addressing schemes: CAN2.0A with 11 bit address CAN2.0B with 29 bit address

11 bit address CAN2.0A is used for small networks with 2048 different addresses maximum. As we will see later on in the Higher Layer Protocol section, simple nodes can use about 10 Addresses (IDE). 2048 different addresses translate in 200 nodes maximum. CAN2.0B with 29-bit address push the limit much farther.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

In CAN the Address Field is called ID/IDE (Identifier: Identifier Extension). Reader familiar with Telecom ISDN will see the similarity with SAPI/TEI. It is curious to note that ISDN LAPD arbitration is somewhat similar to CAN arbitration too. Figure 3. CAN2.0A and CAN2.0B frame formats

Bit Stuffing
SOF
ACK

del

Bus Frame
Duration in Data Bit

ARBITRATION

CTRL 6
RTR RB0 IDE

DATA 064

CRC 15

del

EOF 7

IFS 3

1 SOF

12- 32

CAN - V2.0A
Duration in Data Bit

ID 11
ARBITRATION

DLC 4

DATA

1 CTRL

SRR

ID[28..18] 11

RTR

IDE

CAN - V2.0B
Duration in Data Bit

SOF

RB1

RB0

ID[17..0]

DLC 4

DATA

1 18 ARBITRATION

1 CTRL

SOF Start of Frame CRC Cyclic Redundancy Code del Delimiter ACK Acknowledge

EOF IFS ID IDE

End of Frame Inter Frame Spacing Identifier Identifier Extension

RTR SRR RB0/1 DLC

Remote Transmission Request Substitute Remote Request Reserved bits Data Length Code

The data field is CAN2.0A and CAN2.0B is 8 bytes. This is dimensioned for the short messages exchanged in CAN applications. The DLC field indicates how many data bytes are present in the data field (max 8). higher layer protocols provide a way to exchange messages with more than 8 bytes data. This is called fragmented messages. A simple example to illustrate this feature is the field reprogramming of devices installed on a network. This will be detailed later on and a specific section will deal about Field reprogramming. While the transmitter drive the bus from the Start Of Frame (SOF) to the CRC and Delay bit, the receiver drive the ACK bit. This is the way the transmitter is informed that receivers received the frame. Bit stuffing is implemented on the message as indicated in the figure above. Bit stuffing consists upon adding a bit of the opposite value following a sequence of 5 consecutive bits at the same value. Bit stuffing provides a minimum density of edges to help devices stay in synchronization. Detailed description of the bit field not described here can be found in CAN recommendation or in Atmel CAN controller datasheets.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Physical Layer
The CAN physical medium is a two-wire bus line with common return terminated at both ends by resistors. Differential signal is used for better immunity. The following figure shows a transmit signal from a CAN controller, the differential signal emitted on the line and the receive signal received by the CAN controller to monitor the CAN bus. Figure 4. CAN Physical Layer

TXd TXd CAN Controller RXd CAN Transceiver CANh CANl CANh CANl Do minant RXd Do minant Recessive

A typical CAN bus in a factory automation application is a single line bus with stubs to connect equipments such as PLC, Sensors, Drives etc as illustrated by the figure below Figure 5. Typical CAN bus implementation

CAN Bus (up to 40m @1Mb/ s, up to 1km @50Kb/ s) Stub Device #1 Device #2 Device #3 Device #n

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

CAN Applications
Introduction
Many industries have adopted the CAN bus standard, and gained a lot in reliability and flexibility. For some applications, the cost and speed to deploy or reconfigure a communication network is critical such as a factory floor for instance. A CAN bus can be laid out, then equipments can be added thanks to the plug and play capability of CAN with Higher Layer Protocols.

CAN in cars and truck engine control

CAN is used in the majority of European cars for engine control and body electronic. American and Asian car manufacturers are also implementing the CAN.

CAN in non-passenger cars vehicles

CAN is a natural solution for truck superstructure equipments such as ladder and valves control on fire-trucks, refrigeration system control, tractor to trailer connection. In the many examples of truck systems, the communication bus is used by the truck manufacturer and by the multiple vendors providing equipments connected on the truck platform. Selecting a standard such as CAN and a higher layer protocol is necessary to insure inter-operability. Moreover, if vendors team-up to develop a specific profile such as a CANopen dedicated profile, building block assembly, test and maintenance will be greatly simplified. CANopen and J1839 are the 2 higher layer protocols used in these applications. The same rational apply for construction off-road vehicles and agricultural equipments as well as forklifts. Let us look at the following case study: Manufacturers of electrical vehicle such as Forklift, Airport vehicle, golf court vehicles uses various expensive batteries. On the over side, Battery charger manufacturers have to provide chargers that quickly and securely recharge those batteries. By defining together the CANopen battery and battery charger profile, they gave themselves the right system to exchange charging characteristics, monitor the charges, and store state of charge. Atmel was pleased to help some of those manufacturers providing the right microcontroller and helping in the software development for the battery charger CANopen profile. A lot of small industries contribute in these systems, most of them not large enough to afford CAN HW/SW specialists in house. In this case it is important for a semiconductor company to offer hardware and higher layer protocol software, plus the help of consultants.

CAN in maritime applications

CAN is used for connecting several subsystems in vessels. The system characteristics are somewhat similar to factory automation systems. Some critical systems need an extra safety layer based on redundancy. Some details on Safety bus are given further in this document. CANopen, J1939 and DeviceNet are used on top of CAN in vessels systems.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

A second category of maritime application is fishing industry as well as recreational boat. In such application we can find GPS, radar, sonar, fish finder, control dashboard, display plus various safety sensors. This represents a large volume business with fierce competition, especially in North America where recreation boats are numerous. All above equipments require CAN controllers with low power consumption, a lot of digital I/Os and analog I/Os, field reprogramming capability over the CAN bus, and overall, low cost.

CAN in avionics system network

Company like Airbus, Boeing and NASA use the CAN for backbone network for flight state sensors and navigation systems. Normal Industrial grade components can be used in such systems. Being an active semiconductor vendor in the avionic industry help in getting to the right development teams, and support the customer in the specific ways they want to be supported.

CAN in factory automations, building automation and other industrial control

This is the core of non-automotive CAN applications. The equipments connected on an industrial bus are various. To list a few of them: switches, proximity sensors, photoelectric sensors, Digital I/O, Analog I/Os, motor drives (such as conveyor belt drive), servo motor drives for robots, arms etc, motion controller, valve control, Programmable Logic Controllers (PLC), bar code readers, Displays, control panels, scales, and of course PCs. As many different devices from different vendors will be connected together on the same manufacturing floor bus, It is mandatory that they all use the same high layer software stack directly or through a protocol converter. This explains why ODVA DeviceNet is so important in North America, and CANopen in Europe. Using them is a prerequisite for interoperability. From a semiconductor vendor serving the Industrial Control business, it is extremely important to offer directly or through a third party a CANopen stack and a DeviceNet stack. It is also very important to have a reference in the industry as Atmel did with Rockwell Automation. Rockwell automation had a DeviceNet sensor with Atmel controller on demo at the Amsterdam Nov 2000 CAN conference where the first Atmel CAN controller was launched (T89C51CC01) CAN in factory automation is the leading application driving the Safety bus such as ODVA CIP Safety and DeviceNet Safety. The concept will be explained later in the Higher Layer Protocol chapter. We will illustrate it here with one example. In a manufacturing floor system, the light curtain input device, the PLC controlling the critical system and the output controlling the part of the equipment that can harm an operator will have to have an extra layer of security on top of the higher layer protocol. We will see later that this can be achieve by redundancy and we will see the mechanisms that should be present in CAN controller to support this redundancy.

CAN in elevators, automatic doors

Elevator manufacturers as well as door module manufacturers teamed up to develop a specific CANopen profile for their applications. This represents large volume applications.

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

For instance, a 10 stories building with 2 elevators will roughly have 100 CAN nodes (2 button panels + 2 display panels per floor + 1 button panel and 1 display panel per elevator + 40 proximity sensors + motor control + maintenance panel.). The controllers used in these systems will have to run a full protocol stack + offer digital I/Os and possibly Analog Input and PWM output. A button controller will have nothing more that the protocol stack to run and can use a low pin-count, minimum memory controller. The electric doors at the entrance of the building as well as the elevator doors will control motor drives that require a significant MIPS horsepower and memory (code + data) on top of the higher layer protocol. It will also have Analog Input and PWM control output plus digital I/O to control switches. This can round up to another 50 or so CAN nodes.

CAN in medical equipments

CAN have been used in embedded network in medical devices since several years. Lab automation is not different from manufacturing automation. A significant step was made when key manufacturers started to rethink their networking approach to networking inside the operating room, in the nurse room, the patient room even the patient bed. High cost high maintenance existing proprietary solutions, solutions using declining standard like LON were compared to CAN. The combination of high reliability of CAN, the benefit of an open standard like CANopen, the emergence of fault tolerant CAN transceiver put the CAN on top of the list of considered new solutions. At this time, CAN is deployed by the leader in hospital beds connecting the control panels the various motors, the scale. A hospital bed includes 5 to 10 CAN nodes in new generation of beds to be introduced in 2004 in the marketplace. X-ray collimator, X-ray generator and patient table from a market leader use CAN. CAN with CANopen is deployed in operating room as a result of SIOS: Siemens Integrated OR System.

10

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

CAN Higher Layers Protocols

Various higher layer protocols were introduced earlier in this white paper. We can put OSEK on a side. OSEK is used for automotive application and is not the main application focus in this whitepaper. DeviceNet, CANopen and J1939 have a lot of similarity as they address similar needs. They all cover bus throughput of 125Kb/s up to 1Mb/s. DeviceNet differentiate itself by being CAN2.0A (11 bit address) as DeviceNet favor small clusters connected together by a second CAN layer called ControlNet. One main ControlNet bus will control multiple DeviceNet clusters through gateways. We are seeing now a migration to Ethernet/IP to replace ControlNet as the upper layer cluster controller bus. For a CAN controller it is necessary to support CAN2.0A in order to support the large North American DeviceNet based market led by Rockwell Automation Eaton and others. CANopen is CAN2.0B to support 29-bit address and consequently largely populated bus. With its rich number of application specific profiles, CANopen is the best candidate for a more in depth description in this document.

CANopen detailed description

CANopen supports a maximum speed of 1Mb/s, it uses CAN2.0B 29 bit address Identifier (ID) and 8 byte data. An identifier is unique to a node in the system. CANopen uses an Object dictionary similar to a lookup table. The object dictionary contains the complete state of a slave device connected to a bus. A slave device can be an I/O, an encoder, a drive etc There is a specific CANopen profile for each category of slave devices. A simple device profile such as the battery charger profile contains 49 entries with 21 indexes and need 1024 bytes of RAM. The object dictionary exhaustively describes the device. A CAN controller must have enough RAM to contain the object dictionary to avoid external RAM. An exception to this rule is the Programmable Logic Controller (PLC) for which the necessary RAM is too much to be stored inside a standalone device. PLCs act as master to control peripherals in normal operating mode. PLCs are slave to a configuration master during a network configuration phase. A configuration tool or a master such as a PLC will access all slaves attached to it. Please note that multiple PLCs controlling multiple slaves can sit on the same bus. Each PLC will only talk to the slave under their control. This is an illustration of how the unique ID works. Now that we have defined the state for a device, lets define the way to communicate with it. Service Data Object (SDO) is a point-to-point communication. A Master will use a transmit SDO to request a change in a slave Object Dictionary. The Slave will reply with a receive SDO. Both messages will have a unique ID defined by the protocol. Most of the SDO uses only 8 bytes or less and will reside in a single CAN frame. A Slave device will have 2 SDOs (transmit and receive).

11

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Now that we saw how the master communicate with the slave, lets see how slaves can exchange information directly using Process Data Object Communication (PDO) PDO allow portion of the Object dictionary to be sent. The simplest example is I/O devices that will send the bit value of an input every time a change on this input occur (event driven). Conversely this I/O can respond to a polling request or synchronized with a SYN message. Typical slave applications will have between 5 and 10 different PDOs In total, a typical slave application will have 7 to 12 different Identifiers (PDO+SDO). If a CAN controller can handle the different IDs concurrently this will greatly simplify the software and speed-up the CANopen stack execution time. See the next chapter on the message object description. CANopen like DeviceNet and other protocols support segmented transfer (fragmented messages in DeviceNet). This is the technique used to send a packet of information larger than 8 bytes. A good example of segmented messages is the re-flash system to reprogram a peripheral as defined by the CIA-DSP302 recommendation. In CANopen segmented messages will use the first 4 bytes to carry indexes and control status information while the real data will reside in the remaining 4 bytes data payload. CANopen or DeviceNet Slave implementations typically need 10 to 32Kbytes code. The RAM size is dimensioned by the size of the object dictionary.

Safety Bus
For safety critical applications, redundancy is used to increase the safety. We can identify 2 levels of critical systems nodes. Cost sensitive safety node (significant volume) Highly critical node (limited volume, not cost sensitive)

For the first category, the main controller transmit and receive on the CAN line while a second controller is added to monitor the CAN line. Both controllers then compare their result (compare the frame) exchanging over a dedicated serial line between them (UART or SPI) For highly critical devices, a more complex system will be used. It is under definition at this time.

12

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Figure 6. Safety node

CAN BUS

Transceiver

Transmit

Receive

Transmit

Receive

Main Controller
Serial Port Cross-check

Monitoring Controller
Serial Port

13

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Atmel Solutions for CAN Networking

Atmel has a full system solution for CAN Networking with Flash microcontrollers and a High Speed Transceiver. This is the CANary family.

All CAN Microcontrollers have a set of common features: Flash memory for code E2PROM RAM In Application Programming capability assisted by a bootloader. Same CAN engine to simpliify Software Migration. Low voltage capability (2.7 volts min) Enough MIPS to run high layer protocol + application

5-MIPS C51 core based controllers where first introduced between Y2000 and Y2003. In Y2004 Atmel is introducing the first AVR CAN controller with up to 16MIPS performance, and the set of memories and peripherals necessary to tackle higher-end applications.

5 MIPS Microcontrollers
3 controllers: T89C51CC01, T89C51CC02, AT89C51CC03 exist. With 5 MIPS at 5 volts and 16KBytes to 64KBytes Flash they cover a broad range of slave applications such as proximity sensor, DeviceNet I/O, textile machine I/O and many other applications. For low voltage applications, the 3 controllers maintain up to 3.3MIPS down to 2.7 volts. The T89C51CC02 with 16Kbytes Flash and 0.5Kbytes RAM + a simple 4 message objects CAN engine packaged into a Small Pin Count package cover low end applications where a minimum DeviceNet or CANopen slave stack is used. It is the perfect low cost product for a CAN controller push-button. The 4 message objects of the CAN engine are sufficient to cover simple slave applciations (see the high layer protocol detail description chapter to see the rational between application complexity and number of Message Object. The T89C51CC02 features a 2Kbytes E2PROM and a 2Kbytes Boot Flash for field in application reflashing. The T89C51CC01 was the first product introduced. With 32Kbytes Flash and 1.2 Kbytes RAM it is the perfect match for Slave applications. From 8 to 16 Kbytes of flash and at least 3 MIPS are left for the application on top of a CANopen or DeviceNet stack. The chip sports an 8 channels 10 bit A/D converter 3 timers, 5 high speed input/outpout timer units and 32 I/Os . The 15 message objects and the

14

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

1.2Kbytes RAM make the chip suitable for rather complex I/O systems. See the high layer protocol detail description chapter to see the rational between application complexity and number of message object. As each message objects can be programmed as a transmit or receive and has a unique ID address, it make it possible for a CANopen protocol stack for instance to assign one message object for each and every SPO and PDO which drastically simplify the software, reduce the amount of SRAM and allow the stack to run faster. The T89C51CC01 has a CAN or UART bootloader making it suitable for field in application reprogramming. It also has the 2Kbytes E2PROM necessary to save configuration set-up and data-log requested by higher layer protocol. The AT89C51CC03 is Atmel response to customer using the T89C51CC01 and in need for up to 32Kbytes Flash for the application program itself, and 2Kbytes RAM for larger Object Dictionary. The SPI port included also help in communication with other devices. The 15 message Objects are kept as well as the 2Kbytes Bootloader and 2Kbytes E2PROM.

The 3 controllers above share the same set of tools (C Compilers, Emulators) high layer protocol stacks developed by Software Tool Vendors run on all 3 products.

16 MIPS Microcontrollers
Atmel is introducing a CAN controller using the very successful AVR RISC architecture. The first controller is coming with 128Kbytes Flash, 4Kbytes RAM, and 4Kbytes E2PROM and offer 16MIPS. It immediately positions itself as the high-end controller of the CANary family. All the experience gained by Atmel in CAN applications was used in defining the AT90CAN128, the first CAN controller with AVR architecture. CAN engine: Software tool vendors requested an improvement on the CAN Engine Interrupt system in order to include a hardware sort mechanism which presents value of the first message object channel. This save up to 30S compared to the standard software sort procedure. 30S is 65% of a CAN frame period (@1Mb/s) With this improvement, the risk of frame overflow is eliminated, and software stacks do not need to assign 2 message objects to a single channel to overcome the risk of overflow. Other benefits were found in applications where the CAN controller acts as a CAN coprocessor of a 32-bit processor. The CAN engine also includes a mechanism called buffer. Multiple message objects can be grouped in one buffer. This is especially useful for fragmented message applications. We will use 2 examples to illustrate that Transmit fragmented message in a slave CANopen I/O : A slave I/O may have to reply to a PLC with a part of its Object Dictionary that is larger than 8-Bytes. In this case fragmented messages will be used. A buffer can be set-up with as many message Objets necessary for the buffer to contain in full all data to be returned to the PLC (see in the CANopen detail chapter the description of fragmented/Segmented message). Every time the PLC send a polling request, the I/O will spell out the complete response with a minimum CPU involvement. Receive fragmented message in a slave device : The reflash mechanism for field reprogramming can use fragmented messages. The configurator and the device can negotiate the width of the buffer, then the slave can tie as many message object as necessary into a receive buffer to read block of data.

15

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

In Application programming: Atmel developed for the T89C51CC01 a minimum bootloader program that can be used to reprogram in the field a device without disrupting the activity on the bus. Although this feature was well received, customers asked for a larger boot program, so they could squeeze a minimum DeviceNet or CANopen stack in the boot. This is possible with the AT90CAN128 where a special configurable part of the flash (from 0 to 8Kbytes) can be used for a custom boot program. Code size: Some applications need a large program space on top of the high layer protocol stack, with more than 64KBytes in total. With 128Kbytes flash, the AT90CAN128 perfectly address this request. RAM size: We saw earlier in the CANopen detailed description that typical slave Object Dictionary is using 1Kbytes RAM. This means that higher-end Slave applications will need significantly more, not to mention that the application itself may need a significant amount of RAM too. The AT90CAN128 with 4Kbytes RAM address this request. On chip debug support unit: A lot of applications using CAN, the CAN transceiver and controller are tucked in a small cabinet. It is not always possible to plug an emulator. On Chip Debug Support Unit becomes a very useful feature in such system. AT90CAN128 has a JTAG debug support unit that can also be used for flash programming. Rail-to-Rail Analog to Digital converter: In a lot of applications, analog input signal cover the full GND to VCC range. An Analog to Digital Converter that can convert such a signal is called a Rail-to-Rail ADC. The AT90CAN128 has a Rail-to-Rail ADC with 8 channels and 10 bit precision CAN Safety: As described in the CAN Safety chapter of this document, A fast serial link is required between the main controller and the monitoring controller. On this channel they will exchange the complete payload of a CAN receive message to verify that they both received the same information. If the true, then the main controller will consider the message otherwise it will be ignored. Two AT90CAN128 can be used in a CAN Safety application connected together over the SPI port. The AT90CAN128 is fast enough to support the extra load of the real-time check. The AT90CAN128 has many nice peripherals such as timers; it has a low mW/MIPS ratio. And is compatible with the Mega128 which simplify the development of a CAN application for the many customers and consultant already familiar with the Atmel Mega AVR family.

High Speed transceiver

Atmel has a High Speed CAN Transceiver ATA6660, which can be used with any Atmel CAN controller.

16

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Full System Solution

Since the introduction of the first CAN controller, Atmel has been working closely with software vendors and consultants. Atmel application engineers are very familiar with CANopen, DeviceNet and over protocol stacks. This continuous investment help Atmel understand customer needs above and beyond the pure semiconductor hardware content. It helps find with the customer the right system solution and support for his projects.

Atmel CAN offer summary

The following table summarizes the full Atmel CAN offering Table 1. Atmel CAN offer 8051 Architecture T89C51CC01 Introduced in MIPS Flash Program/Boot EEPROM RAM Power Fail Detect CAN Controller SPI Supply (V) ADC PCA Timers UART Port Bootloader Y2000 5 32KB/2KB 2K x 8 1.2K x 8 No T89C51CC02 Y2001 5 16KB/2KB 2K x 8 0.5K x 8 No AT89C51CC03 July 2003 5 64KB/2KB 2K x 8 2.2K x 8 Yes AVR 8-Bit RISC AT90CAN128 February 2004 16 128KB/up to 8KB 4KB 4KB Yes

15 message objects 4 message objects 15 message objects 15 message objects No 3 to 5.5 10-bit, 8 channels 5 channels Timers 0/1/2 1 Port 0/1/2/3 UART / CAN TQFP44, PLCC44, CA-BGA64 No 3 to 5.5 10-bit, 8 channels 2 channels Timers 0/1/2 1 Port 1/2/3 UART / CAN SOIC24, SOIC28, TQFP32, PLCC28 Yes 3 to 5.5 10-bit, 8 channels 5 channels Timers 0/1/2 1 Port 0/1/2/3 same UART / CAN as T89C51CC01 TQFP44, PLCC44, CA-BGA64 Yes 2.7 to 5.5 10-bit, 8 channels No Timers 0/1/2/3 2 Port A/B/C/D/E/F/G UART / CAN

Packages

TQFP64, QFN64

Companion chip: ATA6660 High speed CAN transciever

17

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Conclusion
CAN networking offers the reliability and large life span of a thoroughly thought solutions with industry leaders committed to it and working to continuously improve it. In return a significant number of semiconductor vendors offer CAN controllers. This makes it an attractive solution for customers looking at piggy-backing on a proven standard rather than inventing their own. This brings new applications some with large volume. The next positive factor is the willingness from customers to jointly specify special application software profiles. This attracts Software vendors to develop them. All together this create a win win situation from which everybody benefit. Atmel is well positioned to support the CAN networking with a state of the art microcontroller flash technology and the experience gained in CAN networking from an early start.

References
1. 2. CAN in Automation http://www.can-cia.com Michel Passemard (Atmel), Bob Pickering (Minit-Charger), Olaf Pfeiffer (ESA): Implementation of the CAN open profile for battery and charger ISO 11783 http://www.can-cia.org/icc/9/index.html ODVA the organization that supports network technologies built on the Common Industrial Protocol (CIP) DeviceNet, EtherNet/IP, CIP Sync and CIP Safety. http://www.odva.org/

3.

18

4069A CAN02/04

ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Editor's Notes
About Atmel Corporation
Founded in 1984, Atmel Corporation is headquartered in San Jose, California with manufacturing facilities in North America and Europe. Atmel designs, manufactures and markets worldwide, advanced logic, mixed-signal, nonvolatile memory and RF semiconductors. Atmel is also a leading provider of system-level integration semiconductor solutions using CMOS, BiCMOS, SiGe, and high-voltage BCDMOS process technologies. Further information can be obtained from Atmels Web site at www.atmel.com. Contact: Michel Passemard Industrial Control Business Development Director, Atmel Nantes, France, Tel: (+33) (0) 2 40 18 19 65, e-mail: michel.passemard@nto.atmel.com

Atmel Corporation 2004. All rights reserved. Atmel, AVR, megaAVR and combinations thereof are the registered trademarks of Atmel Corporation or its subsidiaries. DeviceNet is a trade mark of Open DeviceNet Vendor Association Inc. Other terms and product names in this document may be the trademarks of others.

19

4069A CAN02/04