5989-2857en+an_5223+14may10

8/7/2019 5989-2857EN+AN_5223+14May10

1/13

Controller Area Network (CAN)Bus for AEAS-7000

Application Note 5223

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

IntroductionCommunication 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

slave or inputs to the slave per clock cycle. For example, totransfer 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.

Figure 1. AEAS-7000 SSI Communication State Diagram.

8/7/2019 5989-2857EN+AN_5223+14May10

2/13

8/7/2019 5989-2857EN+AN_5223+14May10

3/13

3

Figure 3. CAN Implementation Using OSI Model.

CAN communication protocol only

denes the Data Link layer and the

Physical layer in the OSI model. It is

up to the system designers to dene

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.

The Physical Medium Attachment

(PMA) and Medium Dependent

Interface (MDI) are two physical

layers that are undened in CAN

specications. Physical Signaling

(PS) is dened in the CAN specica-

tions and the system designers are

free to choose any driver/receiverand transport medium as long as

the Physical Signaling requirements

are met.

The CAN Controller implements all

the CAN specications in hardware.

The PMA is undened in the CAN

specications, but it is dened by

the ISO-11898. The ISO-11898 is a

standard for high-speed CAN com-

munications in road vehicles and

species a 5V dierential electrical

bus as the physical interface. TheISO-11898 also ensures compatibil-

ity with the CAN transceiver.

Control Area Network (CAN) Controller

Basically, the CAN Controller imple-

ments the CAN specications in

hardware. CAN protocol is a CSMA/

CD (Carrier Sense Multiple Access/

Collision Detection) protocol, which

means:

Each of the nodes is required tocheck 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).

8/7/2019 5989-2857EN+AN_5223+14May10

4/13

4

Figure 4. Non-destructive Bitwise Arbitration Method.

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 dened

as Dominant or Recessive. In CAN

protocol, logic bit 0 is dened as

Dominant bit, and logic bit 1 is

dened 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 Recessivebit state. The lower the value in

the Message Identier, the higher

the message priority.

4. A node that loses the arbitration

stops transmitting immediately

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 onaddresses 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 TransmitRequest (RTR). Instead of waiting for

messages to be received, each node

specically 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 consistof elds that provide specic

information embedded in the

messages as dened in the CAN

specications. 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 dened as the Dominant

bit and logic 1 bit is dened as

the Recessive bit, meaning thatmessages with a lower number in

the arbitration eld have a higher

priority on the bus. The Arbitra-

tion Field consists of 12-bits

(11-bit Identier and 1-bit RTR)

or 32-bits (29-bit Identier, 1-bit

extended data frame identier,

1-bit unused SRR, and 1-bit RTR),

depending on whether Standard

Frames or Extended Frames are

chosen.

The Control Field consists of sixbits. 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.

8/7/2019 5989-2857EN+AN_5223+14May10

5/13

5

Figure 5. Data Frame Structure.

The Data Field consists of data

bytes. The amount of bytes is

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

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 RemoteFrame as shown in Figure 6 is

sent with the identier of the

required Data Frame. The RTR bit

in the arbitration eld 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 ve error types dened

in the CAN specications:

a. Acknowledge Error

b. CRC Errorc. Form Error

d. Stu Error

e. Bit Error

4. Overload Frame is generated by

nodes that require more time to

process received messages.

Figure 6. Remote Frame Structure.

Figure 7. Error Frame Structure.

8/7/2019 5989-2857EN+AN_5223+14May10

6/13

6

Control Area Network (CAN) Transceiver

The Control Area Network (CAN)

transceivers fall under the Physical

Medium Attachment category

specied by the ISO-11898-2 stan-

dard. CAN protocol denes the logi-

cal states as Dominant (logic 0) bit

and Recessive (logic 1) bit, whereasthe ISO-11898 denes a dierential

voltage to represent Dominant and

Recessive states. Figure 8 illustrates

the dierential bus of the CAN

transceiver.

ISO-11898 does not specify the

mechanical wires and connectors,

but it does specify that the wires

and connectors must meet the

specications. One of the specica-

tions states that a 120 (nominal)

terminating resistor is required ateach end of the bus. Other speci-

cations ensure that the transceiver

can survive harsh electrical condi-

tions. Table 1 shows the ISO-11898-2

electrical requirements for CAN

transceivers.

The ISO-11898 specications also

specify that the transceiver must

be able to drive a 40-meter bus at

1 Mb/s. The bus length can be in-

creased by reducing the data rate to

less than 1Mb/s. The main concern

regarding the bus length is the

propagation delay of the transceiv-

er. The propagation delay greatly

aects 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 8. CAN Transceiver Bus Dierential.

Table 1. ISO-11898-2 CAN Transceiver Electrical Specications Requirement.

ISO-11898-4

Parameter Min Max Unit

DC Voltage on CANH and CANL -3 +32 V

Transient voltage on CANH and CAL -150 +100 V

Common Mode Bus Voltage -2.0 +7.0 V

Recessive Output Bus Voltage +2.0 +3.0 V

Recessive Diferential Output Voltage -500 +50 mV

Diferential Internal Resistance 10 100 k

Common Mode Input Resistance 5.0 50 k

Diferential Dominant Output Voltage +1.5 +3.0 V

Dominant Output Voltage (CANH) +2.75 +4.50 V

Dominant Output Voltage (CANL) +0.50 +2.25 V

Figure 9. Propagation Delay Node ANode B.

8/7/2019 5989-2857EN+AN_5223+14May10

7/13

7

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 tbus is physical bus timing,tcmpis input comparator delay, and

tdrvis output driver delay.

In order for the CAN system to work

properly, the receivers must synchro-

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

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.

System Design ConsiderationsThe 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 diagramof AEAS-7000 with CAN interface.

Figure 10. AEAS-7000 with CAN Interface System Block Diagram.

CANB

US

8/7/2019 5989-2857EN+AN_5223+14May10

8/13

8

Program Flow ChartFigure 11 illustrates the ow chart of

the AEAS-7000 with CAN interface.

Figure 11. Software Flow Chart.

8/7/2019 5989-2857EN+AN_5223+14May10

9/13

9

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

fetches the Absolute Position and

sends the data via the CAN bus in

Data Frame Format.

Figure 12. Remote Frame Data Format.

Figure 13. Data Frame Format.

8/7/2019 5989-2857EN+AN_5223+14May10

10/13

10

Appendix I

AEAS-7000 Schematic with CAN Bus Interface

8/7/2019 5989-2857EN+AN_5223+14May10

11/13

11

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 // Include Processor Library

#include CAN18XX8.h // Include CAN Bus Library

#include // Include General Software Library

#include // 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 ;

#dene OUTGOING_ID 0X210

#dene INCOMING_ID 0X200

#dene MESSAGE_ID1 0x201

#dene RX_Filter0 0x201






#dene RXB0_MASK 0x7ff

#dene RXB1_MASK 0x7ff

#dene NCS LATAbits.LATA5

void main( void )

{

// *** Port Initialization ***

PORTA = 0x00 ;

TRISA = 0x00 ;

PORTD = 0x00 ;

TRISD = 0x00 ;

TRISBbits.TRISB2 = 0 ; // CANTX

TRISBbits.TRISB3 = 1 ; // CANRX

8/7/2019 5989-2857EN+AN_5223+14May10

12/13

12

// *** 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) ; //Conguration 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) ;






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 ++ ) ;

}

8/7/2019 5989-2857EN+AN_5223+14May10

13/13

References1. 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 inormation and a complete list o distributors, please go to our web s ite: www.avagotech.com

Avago, Avago Technologies, and the A logo are trademarks o 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

5989-2857en+an_5223+14may10

Documents