Abstract—This paper proposes
the fast data frame transfer between one controller to another. The data
frames are transferred without any collision or corruption.The Controller Area
Network(CAN) frames and protocols will be explained deeply, here. The
simulation is made in the keil software to display the data transfer between
transmitter and receiver in CAN. ARM7 microcontroller is used to transfer datas
between the controllers in real time. Data transfer is verified using the CRO.
The Controller Area Network
(CAN) is a serial bus communications protocol developed by Bosch in the early
1980s. It provides a preferrable and reliable communication between actuators,
controllers, sensors and other nodes in real time systems. CAN is a standard
protocol for many number of control systems in network embedded.CAN basically
developed for Vehicle industry. It can be found in vehicles like cars, trucks,
boats etc. Nowerdays, the protocol is also used in industries for automation
and network embedded control, with application in products such as medical
equipments, weaving machines, production machinery and wheel chairs etc. In the
automotive industry, embedded control has grown from stand-alone systems to
highly integrated and networked control systems in such industries. By making a
network of electro-mechanical subsystems, it become possible to change the
functionalities and hardware, which gives us a chance to reuse it. The ECU
handles the control of engine, turbo and fan, etc. but also the CAN
communication. Combination of networks and mechatronics modules reduces the
cabling distances and system response time, which gives more production and
reliability. Introducing networks in vehicles also makes it possible to more
efficiently carry out diagnostics and to coordinate the operation of the separate
subsystems.The CAN protocol standardizes the physical and data link layers,
which are the two lowest layers of the open systems interconnect (OSI)
communication model.For most systems, higher-layer protocols are needed to
enable efficient development and operation. Such protocols are needed for
defining how the CAN protocol should be used in applications, for example, how
to refer the configuration of identifiers with respect to application
messages,how to package application messages into frames, and how to deal with
start-up and fault handling.Note also that real-time issues and redundancy
management OSI layers are required. are not covered by the
Assistant Professor, Dept of EEE,
university, Coimbatore, Tamilnadu, India.
OSI model. The adoption of CAN in a variety of application
fields has led to the development of several higher-layer protocols, including
SAE J1939, CANopen, DeviceNet, and CAN Kingdom. Their characteristics reflect
differences in requirements and traditions of application areas. An example is
the adoption of certain communication models, such as either the client-server
model or the distributed data-flow model. The progress and success of CAN are
due to a number of devices through which it can communicate. The evolution of
microelectronics led the way for introducing distributed control system in
vehicles. In the early 1980s there was, however, a lack of low-cost and
standardized protocols suitable for real-time control systems. Therefore, in
1983 Kiencke started the development of a new serial bus system at Bosch.
1: OSI model
The CAN protocol defines the lowest two layers of the OSI
model. There exist several CAN-based higher-layer protocols that are
standardized. The user choice depends on the application.
CAN (or CANbus) is a
multi-master broadcast serial bus standard designed to enable communication
between embedded devices without requiring a host computer. The latest version
of the CAN specification is CAN 2.0. CAN was internationally standardized as
ISO11898-1 in 1993,and they sold more than two billion CAN nodes to all the
available at that time. CAN is
one of the protocols used in the OBD-II on-board diagnostic standard mandatory
on all autos sold in the United States from 1996 onward. CAN become a mandatory
part of all gasoline powered vehicles sold in the European Union from 2001 and
all diesel-powered vehicles since 2004. And also CAN become a mandatory part of
JOBD on Japanese cars since 2001, and is part of the OBD system that is
mandatory on certain light vehicles in China from 2008.Aspects of CAN have been
codified in various ISO standards.
11898-5:2007 specifies the CAN physical layer for transmission rates up to 1
11898-1:2003 specifies the CAN data link layer (DLL) and physical signaling.
ISO 15765-2:2004 specifies the CAN network protocol.
15765-4:2005 specifies a CAN variant specifically for emissions-related systems
based on ISO 15765-2, ISO 11898-1, and ISO 11898-2, with the addition of
CAN was targeted originally for automotive applications, but
adoption of CAN has spread to other markets because of it reliability and
economical cost. CAN is now used in vehicles from trains to ships, as well as
in military, aerospace, and industrial control applications.
III THE CAN PROTOCOL
The CAN communication protocol is a CSMA/CD protocol. The
CSMA stands for Carrier Sense Multiple Access. What this means is that every
node on the network must monitor the bus to check whether the bus is idle or
not, before sending the data in it (Carrier Sense). Also,once this period of no
activity occurs, every node on the bus has an equal opportunity to transmit a
message (Multiple Access) in bus. The CD stands for Collision Detection. If two
nodes start sending data at a time the data will be collided and required
action will be taken. In the CAN protocol, a nondestructive bitwise arbitration
method is utilized. This means that messages remain intact after arbitration is
completed even if collisions are detected. All of this arbitration takes place
without corruption or delay of messages.
The CAN protocol is a
message-based, not an address based protocol. This means that messages are not
transmitted from one node to another node based on addresses. Embedded in the
CAN message itself is the priority and the contents of the data being transmitted.
All nodes in the system receive all message transmitted on the bus. It is up to
each node in the system to decide whether the message received should be
immediately discarded or kept to be processed. A major benefit of this
message-based protocol is that additional nodes can be added to the system
without the necessity to reprogram all other nodes to recognize this addition.
This new node will
start receiving messages from the network and, based on the
message identifier (ID), decide whether to process or discard the received
information.CAN nodes have the ability to determine fault conditions and
transition to different modes based on the severity of problems being
encountered. They also have the ability to detect short disturbances from
permanent failures and modify their functionality accordingly. CAN nodes can
transition from functioning like a normal node (being able to transmit and
receive messages normally), to shutting down completely (bus-off) based on the
severity of the errors detected. This feature is called Fault Confinement. No
faulty CAN node or nodes will be able to monopolize all of the bandwidth on the
network because faults will be confined to the faulty nodes and these faulty
nodes will shut off before bringing the network down. The CAN protocol also
provides sophisticated error detection and error handling mechanisms such as
Cyclic Redundancy Check (CRC) and high immunity against electromagnetic
interference. Temporary errors are recovered. Permanent errors are followed by
automatic switch-off of defective nodes. Every node in the system is informed
about an error. This is very powerful because both Fault Confinement and the
error detection methods guarantee bandwidth for critical system information.
Fig. 2: DATA FORMATS.
In CAN module, data transmission and reception is done with
the help of message frames. Message Frames carry data with it and broadcast it
to the other nodes in the network. The
required node will
receive the data.. The CAN protocol has two Message Frame formats.
CAN (Version 2.0A) uses 11 bit identifier.
CAN (Version 2.0B) uses 29 bit identifier.
Most Standard CAN controllers transmit and receive only
Standard format messages, whereas some (known as 2.0B passive) will receive
Extended format messages 32 but then ignore them. Extended CAN controllers can
send and receive messages in both the formats.
1) STANDARD CAN (VERSION 2.0A) FORMAT
Standard CAN (Version 2.0A) Message Frame consists of different bit fields:
Start of Frame (SOF) field. This is a dominant (logic 0) bit that indicates the
intialization of a data frame.
Arbitration field, containing an 11 bit message identifier and the Remote
Transmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates that
the message is a Data Frame. A recessive (logic
value indicates that the message is
a Remote Transmission Request. A Remote Frame is a request by one node for data
from transmitting node in the bus.Data Field is not required for Remote Frames.
Control Field containing six bits where r0 and r1 are two dominant bits, that
are reserved for future use and Data Length Code of four Bits (DLC). Data Field
has DLC which indicates the number of bytes.A Data Field, containing from zero
to eight bytes.
The CRC field, contains fifteen bit
cyclic redundancy check code and a recessive delimiter bit.
ACKnowledge field, consist of two bits. The first one is the Slot bit which is
transmitted as a logic „0? (recessive bit), but it is over written by logic „1?
(dominant bit) is transmitted from all other nodes that successfully receive
the message. The second bit is a recessive delimiter bit.
End of Frame field, It consists of
seven recessive bits.
Following the end of a frame is the Intermission field which
consist of three recessive bits. After the three bit Intermission period the
bus is recognised to be free. Bus Idle time may be of any arbitrary length
including zero. Refer fig2 for data format and their clear picture.
2) EXTENDED CAN (VERSION 2.0B) FORMAT
The Extended CAN format provides a twenty nine (29) bit
identifier as opposed to the 11 bit identifier in Standard CAN. Extended CAN
evolved to provide compatibility with other serial communications protocols
used in automotive applications in the industries. To make it more efficient
and provide compatibility with the 2.0A format, the Message Frame in Version
2.0B has an extended format.
Extended CAN, the Arbitration field contains two identifier bit fields. The
first the base ID is eleven
bits long for compatibility with
Version 2.0A. The second field the ID extension is eighteen (18) bits long, to
provide a total length of twenty nine (29) bits.
The distinction between the two
formats is done by using an Identifier Extension (IDE) bit.
Substitute Remote Request (SRR) bit is included in the Arbitration Field. The
SRR bit is always transmitted as a logic „0? bit to ensure that, in the case of
arbitration between a Standard Data Frame and an Extended Data Frame, the
Standard Data Frame will always be given high priority where both messages have
the same base (11 bit) identifier.
All other fields in a Extended CAN Message Frame are
identical to those in the Standard format. Refer fig2 for data format and
their clear picture. But I have chosen 11bit identifier because the CAN data
communication is between only two controllers.
The proposed system focuses on data transfer between
controllers which reduces the time of data transmission, complexity and power
consumption. The overview block diagram of the system as follows :
X data in
X data out
Fig. 3: BLOCK DIAGRAM OF PROPOSED
The two ARM 7 LPC 2129 CAN
controllers will be connected in serial with the help of High(H) and Low(L)
wires. H and L wires reduce the harmonics in the data transmission. The X data
will be transmitted from controller 1 and received in controller 2 as data „X?.
4: FLOW CHART FOR CAN DATA TRANSMISSION.
CAN initialization is done and data is transferred from the
controller1. CAN features a collision and arbitration free transmission. The
Message Frame with high priority will be sent without any hurdle while low
priority message will back off and wait till the execution of high priority
message.CAN data transmisson with out data loss is achieved by means of
binary models of logic ‘0’(Dominant) and logic ‘1’
(Recessive).. This means physical implementation, or open collector or wired of
the bus. If one node with dominant bit wins the bus for data transmission. If
the dominant bit over writes the recessive bit, after the execution of the
dominant bit it evidences the collision. A dominant bit is asserted by creating
a voltage across the wires while a recessive bit is simply not asserted on the
bus. If any node sets a change in the voltage, High priority message will not
have any delay in transmitting message while low priority message automatically
retransmit the data frame after the end of dominant message. carrier sense
multiple access/bitwise arbitration (CSMA/BA) scheme is often play a major role
in this protocol.
Prioritized arbitration (
dominant message is delay free) is the solution for CAN to be very suitable in
real time applications. During the transmission, some other node starts
transmiting the message frames. Then the transmitting nodes stops and compares
the arbitration. If the interrupted message frame is dominant then it takes
control of the bus and start transmitting the data. (i.e., it lost
arbitration). Arbitration is performed during the transmission of the
identifier field. Each node starting to transmit at the same time sends an ID
with dominant as binary 0, starting from the high bit. As soon as their ID is a
larger number (lower priority) they will be sending 1 (recessive) and see 0
(dominant), so they back off. At the end of ID transmission, all nodes but one
must have been in wait state, and the highest priority message gets through
unimpeded and takes the bus. Once the data is received properly or not is
checked. If not data is transmitted once again and processed. CAN follows the
priority level in such a way “Lower the Binary Number, Higher the Priority”.
1) SIMULATED RESULT:
Steps to obtain simulated result as
C code is written for ARM7 LPC2129 controller in Keil software for CAN data
-> Debug -> Peripherals -> CAN -> Communication, Controller,
Transmit, Receive and Filters.
The transmission of DATA and ID will
be visible in the below mentioned windows with all other required information
So the fig 5 gives the simulated output of faster data
transmission between Controllers. The column Tx1 ID & Data contains C2TID1
(CAN ID) and C2TDA1 (Data) transmits the data with ID to C2RDA which is in the
column of Rx ID & Data. The data transmission between two controllers is
clearly in the fig 5 which shows the ID and Data a voltage of
3.75 and 1.25v respectively.fig7 and fig8 shows
High and Low voltage signals as follow:
5: SIMULATION RESULT FOR CAN DATA TRANSMISSION.
2) HARDWARE RESULT:
6: HARDWARE SETUP FOR CAN DATA TRANSMISSION.
refers the quick data transfer between ARM7 LPC 2129 connected serially with
High and Low twisted pair of wires. The data transmission can be verified by
using the DSO with two channels CH1 and CH2 having high and low signal having
Fig. 7: CRO RESULT
FOR CAN DATA TRANSMISSION (HIGH).
Fig. 8: CRO RESULT FOR CAN DATA
VII CONCLUSION AND FUTURE WORKS.
The execution of fast data
transfer between ARM7 controllers is successful and verified using DSO. In
future, planned to add many controllers together and analyse the network
behavior like data collision and corruption. Then, assigning the tasks for the
data transferred via CAN to actuate peripherals like motors, buzzer, and
solenoid valves etc…