Download - 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 RX_Filter1 0x300
#dene RX_Filter2 0x400
#dene RX_Filter3 0x500
#dene RX_Filter4 0x600
#dene RX_Filter5 0x700
#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) ;
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 ++ ) ;
}
-
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