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

2 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.

3 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.

4 4069A CAN02/04
 ATMELS MICROCONTROLLER FOR CONTROLLER AREA NETWORK (CAN)

Figure 1. CAN message Frame format

Bit Stuffing

SOF

ACK
del

del
Bus Frame ARBITRATION CTRL DATA CRC EOF IFS

Duration in Data Bit 1 12- 32 6 064 15 1 1 1 7 3

SOF Start of Frame EOF End of Frame RTR Remote Transmission Request
CRC Cyclic Redundancy Code IFS Inter Frame Spacing SRR Substitute Remote Request
del Delimiter ID Identifier RB0/1 Reserved bits
ACK Acknowledge IDE Identifier Extension DLC 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 Node 3 loses

loses Arbitration 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.

5 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

del
Bus Frame ARBITRATION CTRL DATA CRC EOF IFS

Duration in Data Bit 1 12- 32 6 064 15 1 1 1 7 3

SOF

RB0
IDE
RTR
CAN - V2.0A ID DLC DATA

Duration in Data Bit 1 11 1 1 1 4

ARBITRATION CTRL
SOF

CAN - V2.0B

RB1

RB0
RTR
SRR

IDE
ID[28..18] ID[17..0] DLC DATA

Duration in Data Bit 1 11 1 1 18 1 1 1 4

ARBITRATION CTRL

SOF Start of Frame EOF End of Frame RTR Remote Transmission Request
CRC Cyclic Redundancy Code IFS Inter Frame Spacing SRR Substitute Remote Request
del Delimiter ID Identifier RB0/1 Reserved bits
ACK Acknowledge IDE Identifier Extension DLC 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.

6 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 CANh
Do minant
CAN CAN CANh
Controller RXd Transceiver CANl Recessive
CANl
Do minant

RXd

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 Device Device Device

#1 #2 #3 #n

7 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.

8 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.

9 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 Monitoring
Controller Controller
Cross-check
Serial Serial
Port 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 AVR 8-Bit RISC

T89C51CC01 T89C51CC02 AT89C51CC03 AT90CAN128

Introduced in Y2000 Y2001 July 2003 February 2004

MIPS 5 5 5 16
Flash Program/Boot 32KB/2KB 16KB/2KB 64KB/2KB 128KB/up to 8KB
EEPROM 2K x 8 2K x 8 2K x 8 4KB
RAM 1.2K x 8 0.5K x 8 2.2K x 8 4KB
Power Fail Detect No No Yes Yes
CAN Controller 15 message objects 4 message objects 15 message objects 15 message objects
SPI No No Yes Yes
Supply (V) 3 to 5.5 3 to 5.5 3 to 5.5 2.7 to 5.5
ADC 10-bit, 8 channels 10-bit, 8 channels 10-bit, 8 channels 10-bit, 8 channels
PCA 5 channels 2 channels 5 channels No
Timers Timers 0/1/2 Timers 0/1/2 Timers 0/1/2 Timers 0/1/2/3
UART 1 1 1 2

Port Port 0/1/2/3 Port 1/2/3 Port 0/1/2/3 Port A/B/C/D/E/F/G

same UART / CAN
Bootloader UART / CAN UART / CAN as T89C51CC01 UART / CAN

TQFP44, PLCC44, SOIC24, SOIC28, TQFP44, PLCC44,

Packages CA-BGA64 TQFP32, PLCC28 CA-BGA64 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. CAN in Automation http://www.can-cia.com

2. 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

3. 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/

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