Controller Area Network (CAN)
Bus for AEAS-7000
Application Note 5223
Introduction
The AEAS-7000 is a 16-bit gray code Absolute Encoder
backbone with SSI (Synchronous-Serial-Interface) com-
munication interface. The SSI interface is a synchronous
serial communication where the master (host) and slave
(AEAS-7000) devices are synchronous to each other and
the data is output 1-bit per clock cycle.
In this application note, it is shown how hardware can be
added to make the AEAS-7000 compatible with the CAN
bus system. Further details are presented in the System
Design Considerations section.
Introduction­­­—
Communication Protocol
Synchronous Serial Interface (SSI)
SSI, as the name suggests, is a serial communication format
where the master and slave devices are synchronous to
each other. The master device provides a clock signal to
the slave device and 1-bit of data either outputs from the
Figure 1. AEAS-7000 SSI Communication State Diagram.
slave or inputs to the slave per clock cycle. For example, to
transfer 16-bits of data, a 16-clock cycle is required to move
the data. The data is latched on either the falling edge or
rising edge of the clock signal based on the device setup.
The communication speed is based on the maximum band-
width of the slave device. The SSI communication speed of
the AEAS-7000 is up to 16 MHz, meaning that it only takes
62.5 ns to transfer 1-bit of data. But the communication
speed varies depending on the master device with which
it is communicating. Figure 1 illustrates the SSI communi-
cation state diagram for the AEAS-7000 absolute encoder.
Based on the SSI communication state diagram as shown
in Figure 1, the data is available at the AEAS-7000 output
at the falling edge of the clock (SCL) signal. The clock high
state is an idle state and the clock low state is an active
state. The chip select (NSL) line is required to be pulled
down in order for the communication to be active; oth-
erwise, no activities are observed even though the clock
(SCL) signal exits.
Controller Area Network (CAN) Bus
CAN, Controller Area Network, was
initially invented by Robert Bosch
in the mid-1980s as a method of
increasing communication robust-
ness primarily for automotive
applications. The goal was to make
automobiles more reliable, safe, and
fuel-efficient, while reducing wiring
complexity and overall vehicle
weight. Not only has the CAN bus
been implemented in automotive
applications, but it has gained popu-
larity in industrial automation, medi-
cal equipment, test equipment, and CAN communication protocol
mobile machines. Figure 2 illustrates implements the OSI (Open Systems
the percentage of communication Integration) standard layer created
field busses presently installed and by ISO (International Standard Orga-
planned for installment in the next nization) to ensure interoperability
12 months for industrial automation. between products from different
manufacturers. Figure 3 illustrates
Some other applications where the OSI Layer Model.
CAN busses have been successfully
implemented include maritime elec-
tronics, avionics/aerospace electron-
ics, uninterruptible power supply
(UPS), elevator control, and exercise
equipment.

Figure 2. Percentage of Communication Field Busses Both Present and Future.

Source: Control Engineering/Reed Research Groups 2003 Industrial Networking Product Focus Study

2
CAN communication protocol only
defines the Data Link layer and the
Physical layer in the OSI model. It is
up to the system designers to define
the remaining physical layers and the
higher layers. Alternatively, they can
be implemented using the existing
non-proprietary higher layer proto-
cols (HLPs) and physical layers.
The HLPs are used to:
1. standardize startup procedures
including bit rates used
2. distribute addresses among
participating nodes or types of
messages
3. determine the structure of the
messages
4. provide system-level error han-
dling routines.
Figure 3. CAN Implementation Using OSI Model.
3
The Physical Medium Attachment
(PMA) and Medium Dependent
Interface (MDI) are two physical
layers that are undefined in CAN
specifications. Physical Signaling
(PS) is defined in the CAN specifica-
tions and the system designers are
free to choose any driver/receiver
and transport medium as long as
the Physical Signaling requirements
are met.
The CAN Controller implements all
the CAN specifications in hardware.
The PMA is undefined in the CAN
specifications, but it is defined by
the ISO-11898. The ISO-11898 is a
standard for high-speed CAN com-
munications in road vehicles and
specifies a 5V differential electrical
bus as the physical interface. The
ISO-11898 also ensures compatibil-
ity with the CAN transceiver.
Control Area Network (CAN) Controller
Basically, the CAN Controller imple-
ments the CAN specifications in
hardware. CAN protocol is a CSMA/
CD (Carrier Sense Multiple Access/
Collision Detection) protocol, which
means:
• Each of the nodes is required to
check the bus activity for a period
before sending messages on the
bus (Carrier Sense).
• If there is no bus activity, all
nodes have an equal opportunity
to transmit a message (Multiple
Access).
• If two nodes start to transmit at
the same time, the nodes will de-
tect the collision and appropriate
actions will be taken (Collision
Detection).
In CAN protocol, the collision is re-
solved by utilizing a non-destructive
bitwise arbitration method. This
means that the messages remain
intact after arbitration is completed,
even if collision is detected and
no delay or corruption is observed
for high priority messages. Non-
destructive bitwise arbitration
method follows:
1. Logic state needs to be defined
as Dominant or Recessive. In CAN
protocol, logic bit 0 is defined as
Dominant bit, and logic bit 1 is
defined as Recessive bit.
2. Transmitting nodes need to
check whether the logic state out
from its node appears in the bus.
3. Dominant bit state always wins
the arbitration over the Recessive
bit state. The lower the value in
the Message Identifier, the higher
the message priority.
4. A node that loses the arbitration
stops transmitting immediately
Figure 4. Non-destructive Bitwise Arbitration Method.
4
and waits for the next period of
no activity on the bus to trans-
mit the message again. Figure 4
illustrates the arbitration method.
CAN protocol is a message-based
protocol where the transmitted
messages are not based on
­addresses where the priority bits
and content of the data are embed-
ded into the CAN message. All the
nodes in the system receive every
message transmitted on the bus and
acknowledge if the messages are
received properly. Each of the nodes
determine whether to discard the
message or perform further pro-
cessing. Each of the nodes can also
request information from each other
with the built-in feature in CAN
protocol known as Remote Transmit
Request (RTR). Instead of waiting for
messages to be received, each node
specifically requests the message to
be sent to it.
Embedded in the CAN messages are
four types of frame:
1. Data Frame transmits data from
a transmitting node to any or all
other nodes, either Standard or
Extended Data Frames. Figure 5
illustrates the structure of a Data
Frame. The Data Frames consist
of fields that provide specific
information embedded in the
messages as defined in the CAN
specifications. They are Arbitra-
tion Field, Control Field, Data
Field, CRC Field, Acknowledge
Field, and an End of Frame. The
Arbitration Field is used to pri-
oritize the messages on the bus.
As mentioned previously, logic
0 bit is defined as the Dominant
bit and logic 1 bit is defined as
the Recessive bit, meaning that
messages with a lower number in
the arbitration field have a higher
priority on the bus. The Arbitra-
tion Field consists of 12-bits
(11-bit Identifier and 1-bit RTR)
or 32-bits (29-bit Identifier, 1-bit
extended data frame identifier,
1-bit unused SRR, and 1-bit RTR),
depending on whether Standard
Frames or Extended Frames are
chosen.
The Control Field consists of six
bits. The MSB bit is the IDE bit
to determine if the messages
are Standard Data Frames or
Extended Data Frames. The IDE
bit is Dominant for Standard Data
Frames. In Extended Data Frames,
the IDE bit is replaced with an
RB1 bit that is reserved. The last
4-bit is the Data Length Code
(DLC) bit which determines the
number of bytes included in the
messages.
 The Data Field consists of data
bytes. The amount of bytes is
defined in the DLC of the Control
Field.
The CRC Field consists of a 15-bit
CRC and a 1-bit delimiter that is
used for checking errors which
occur during transmission.
The Acknowledge Field consists
of a 1-bit ACK bit and a 1-bit
delimiter. Regardless of whether
the nodes process or discard
the data, once the messages are
received correctly, Dominant
bits will be put on the bus in the
ACK bit.
Figure 5. Data Frame Structure.
Figure 6. Remote Frame Structure.
Figure 7. Error Frame Structure.
5
2. Remote Frame is a request for
data from other nodes, either
Standard or Extended Remote
Frames. Figure 6 illustrates the
structure of a Remote Frame.
In order to achieve a Remote
Transmit Request (RTR), a Remote
Frame as shown in Figure 6 is
sent with the identifier of the
required Data Frame. The RTR bit
in the arbitration field determines
whether the frame is a Remote
Frame or Data Frame. If the RTR
bit is Recessive (logic 0 bit), then
the message is a Remote Frame,
and vice versa.
3. Error Frame indicates bus errors
are detected. Figure 7 illustrates
the structure of an Error Frame.
There are five error types defined
in the CAN specifications:
a. Acknowledge Error
b. CRC Error
c. Form Error
d. Stuff Error
e. Bit Error
4. Overload Frame is generated by
nodes that require more time to
process received messages.
Control Area Network (CAN) Transceiver
The Control Area Network (CAN)
transceivers fall under the Physical
Medium Attachment category
specified by the ISO-11898-2 stan-
dard. CAN protocol defines the logi-
cal states as Dominant (logic 0) bit
and Recessive (logic 1) bit, whereas
the ISO-11898 defines a differential
voltage to represent Dominant and
Recessive states. Figure 8 illustrates
the differential bus of the CAN
transceiver. Figure 8. CAN Transceiver Bus Differential.

ISO-11898 does not specify the

mechanical wires and connectors,
but it does specify that the wires
and connectors must meet the Table 1. ISO-11898-2 CAN Transceiver Electrical Specifications Requirement.
specifications. One of the specifica- ISO-11898-4
tions states that a 120Ω (nominal) Parameter Min Max Unit
terminating resistor is required at DC Voltage on CANH and CANL -3 +32 V
each end of the bus. Other specifi-
Transient voltage on CANH and CAL -150 +100 V
cations ensure that the transceiver
Common Mode Bus Voltage -2.0 +7.0 V
can survive harsh electrical condi-
tions. Table 1 shows the ISO-11898-2 Recessive Output Bus Voltage +2.0 +3.0 V
electrical requirements for CAN Recessive Differential Output Voltage -500 +50 mV
transceivers. Differential Internal Resistance 10 100 kΩ
Common Mode Input Resistance 5.0 50 kΩ
The ISO-11898 specifications also
Differential Dominant Output Voltage +1.5 +3.0 V
specify that the transceiver must
Dominant Output Voltage (CANH) +2.75 +4.50 V
be able to drive a 40-meter bus at
1 Mb/s. The bus length can be in- Dominant Output Voltage (CANL) +0.50 +2.25 V
creased by reducing the data rate to
less than 1 Mb/s. The main concern
regarding the bus length is the
propagation delay of the transceiv-
er. The propagation delay greatly
affects the non-destructive arbitra-
tion methodology where each node
that is involved in the arbitration is
required to sample each bit at the
same time. Extreme propagation
delays result in invalid arbitration.
Figure 9 illustrates the propagation
delay transmitted from Node A and
received by Node B.
Figure 9. Propagation Delay Node A ➔ Node B.

6
The propagation delay is calculated
as a roundtrip signal from the trans-
mitter to receiver and back to the
transmitter. Equation 1 explains the
propagation delay mathematically.
tprop = 2 • (tbus + tcmp + tdrv) Eq. 1
where t­bus is physical bus timing,
tcmp is input comparator delay, and
tdrv is output driver delay.
System Design Considerations
The Microchip PIC18F258 with built-
in CAN controller is used to enable
the CAN interface for the AEAS‑7000
module, together with Microchip
MCP2551 CAN transceiver, to ensure
the ISO-11898 is met. Figure 10
illustrates the system block diagram
of AEAS‑7000 with CAN interface.

In order for the CAN system to work

properly, the receivers must synchro-

CAN BUS
nize to the transmitter data stream
to insure messages are properly
decoded. There are two methods
used for achieving and maintaining
synchronization:
1. Hard Synchronization occurs on
the first recessive-to-dominant
falling edge during bus idle con-
dition that indicates a Start-of-
Frame (SOF) condition. It causes
the bit-timing counter to be reset Figure 10. AEAS-7000 with CAN Interface System Block Diagram.
to the SyncSeg that causes the
edge to fall within the SyncSeg.
At this point, all the receivers are
synchronized to the transmitter.
2. Resynchronization is
­implemented to maintain
synchronization between the
transmitter and receiver that was
established by the Hard Synchro-
nization. Without the Resynchro-
nization, the receiver could get
out of synchronization due to
oscillator drift between nodes.
Resynchronization is achieved by
implementing the Digital Phase
Lock Loop (DPLL) function that
compares the actual position
to the expected position and
adjusts the bit time as necessary.

7
Program Flow Chart
Figure 11 illustrates the flow chart of
the AEAS-7000 with CAN interface.

Figure 11. Software Flow Chart.

8
Application Usage
Acquiring AEAS-7000 Absolute Position via
CAN Bus
The user is required to send a CAN
message in Remote Frame format to
the AEAS-7000.

When the Remote Transmit Request

(RTR) is detected, the AEAS-7000 Figure 12. Remote Frame Data Format.
fetches the Absolute Position and
sends the data via the CAN bus in
Data Frame Format.

Figure 13. Data Frame Format.

9
Appendix I
AEAS-7000 Schematic with CAN Bus Interface

10
Appendix II
AEAS-7000 with CAN Bus Interface Software Example

//*******************************************************************
// Title: CAN Bus For AEAS-7000 Absolute Encoder *
// Author: Teng Kong Leong, Senior Application Engineer *
// Date: February 23rd, 2005 *
// Description: Use of PIC18F258 and MCP2515 Can Bus Tranceiver *
// to enable CAN communication for AEAS-7000. *
// *
// Revision: 0.0 Initial Code *
// Use PIC18F458 for initial code. *
//*******************************************************************

#include <p18f458.h> // Include Processor Library

#include “CAN18XX8.h” // Include CAN Bus Library
#include <stdlib.h> // Include General Software Library
#include <spi.h> // Include SPI Library

void Delay_100(void) ;
char Temp_ASCII[10] ;

union
{
unsigned char Bytes[2] ;
unsigned int Word ;
} AD_ALL ;

unsigned char Var1,Var2 ;

unsigned char POS_MSB, POS_LSB ;

unsigned long TX_ID1 ;

BYTE TX_Data_Buf1[2] ;

unsigned long RX_ID1 ;

BYTE RX_Data_Buf1[2] ;
BYTE RX_Data_Len1 ;
enum CAN_RX_MSG_FLAGS RX1_Message_Flag ;

#define OUTGOING_ID 0X210

#define INCOMING_ID 0X200

#define MESSAGE_ID1 0x201

#define RX_Filter0 0x201
#define RX_Filter1 0x300
#define RX_Filter2 0x400
#define RX_Filter3 0x500
#define RX_Filter4 0x600
#define RX_Filter5 0x700
#define RXB0_MASK 0x7ff
#define RXB1_MASK 0x7ff

#define NCS LATAbits.LATA5

void main( void )

{

// *** Port Initialization ***

PORTA = 0x00 ;
TRISA = 0x00 ;
PORTD = 0x00 ;
TRISD = 0x00 ;
TRISBbits.TRISB2 = 0 ; // CANTX
TRISBbits.TRISB3 = 1 ; // CANRX

11
 // *** SPI Communication Setup ***
SSPSTAT = 0b01000000 ; // CKE = 1, SMP @ Middle
SSPCON1 = 0b00110000 ; // CKP = 1, CLK @ 10MHz

// *** CAN Communication Setup ***

// The Sequence of Parameters is SJW,BRP,PHASEG1,PHASEG2,PROPSEG, Mode !!

CANInitialize( 2,8,3,3,1, CAN_CONFIG_LINE_FILTER_OFF &
CAN_CONFIG_SAMPLE_ONCE &
CAN_CONFIG_VALID_STD_MSG &
CAN_CONFIG_PHSEG2_PRG_ON &
CAN_CONFIG_ALL_MSG) ; //Initialize CAN Module

CANSetOperationMode(CAN_OP_MODE_CONFIG) ; //Configuration Mode

CANSetMask(CAN_MASK_B1, RXB0_MASK, CAN_CONFIG_STD_MSG ) ;// Set Mask For Standard Data Frame
CANSetMask(CAN_MASK_B2, RXB1_MASK, CAN_CONFIG_STD_MSG ) ;
CANSetFilter(CAN_FILTER_B1_F1, RX_Filter0 , CAN_CONFIG_STD_MSG) ;
CANSetFilter(CAN_FILTER_B1_F2, RX_Filter1 , CAN_CONFIG_STD_MSG) ;
CANSetFilter(CAN_FILTER_B2_F1, RX_Filter2 , CAN_CONFIG_STD_MSG) ;
CANSetFilter(CAN_FILTER_B2_F2, RX_Filter3 , CAN_CONFIG_STD_MSG) ;
CANSetFilter(CAN_FILTER_B2_F3, RX_Filter4 , CAN_CONFIG_STD_MSG) ;
CANSetFilter(CAN_FILTER_B2_F4, RX_Filter5 , CAN_CONFIG_STD_MSG) ;

CANSetOperationMode(CAN_OP_MODE_NORMAL) ;

while (1)
{
Delay_100() ;

if ( CANIsRxReady( ) ) // CAN Rx Buffer full ? If yes, continue......else keep looping......

{
CANReceiveMessage(&RX_ID1,RX_Data_Buf1,&RX_Data_Len1,&RX1_Message_Flag ) ;
if ( RX1_Message_Flag & CAN_RX_RTR_FRAME ) // Message Flag Contains Request-to-Return Frame?
{
// *** Fetch Absolute Position from AEAS-7000 ***
NCS = 0 ;
POS_MSB = ReadSPI() ;
POS_LSB = ReadSPI() ;
NCS = 1 ;
// ***********************************************

CANSendMessage(MESSAGE_ID1 ,TX_Data_Buf1,5,CAN_TX_PRIORITY_0 &
CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME ) ; //Send 2-bytes + Message Frame
}
} // End of IF-statement
} // End of WHILE-statement
} // End of MAIN-statement

void Delay_100(void)
{
int X1 ;

for (X1 = 0 ; X1 < 10000 ; X1 ++ ) ;

}

12
References
1. “AEAS-7000 Plug and Play Ultra-Precision Absolute Encoder 16-bit Gray
Code Datasheet,” Avago Technologies
2. “Microchip PIC18F258 8-bit Micro-controller Datasheet,”
Microchip Inc.
3. “Microchip MCP2551 CAN Transceiver,” Microchip Inc.
4. “AN713 Controller Area Network (CAN) Basics,” Microchip Inc.
5. “AN228 A CAN Physical Layer Discussion,” Microchip Inc.
6. “AN754 Understanding CAN Module Bit Timing,” Microchip Inc.
7. “Ease into Flexible CANbus Network,” Analog Design Note

For product information and a complete list of distributors, please go to our web site: www.avagotech.com

Avago, Avago Technologies, and the A logo are trademarks of Avago Technologies, Limited in the United States and other countries.
Data subject to change. Copyright © 2007-2010 Avago Technologies Limited. All rights reserved.
5989-2857EN - May 14, 2010