Abstract—This paper proposesthe fast data frame transfer between one controller to another. The dataframes are transferred without any collision or corruption.
The Controller AreaNetwork(CAN) frames and protocols will be explained deeply, here. Thesimulation is made in the keil software to display the data transfer betweentransmitter and receiver in CAN. ARM7 microcontroller is used to transfer datasbetween the controllers in real time. Data transfer is verified using the CRO. Keywords—CAN; embedded;microcontroller; CRO.
I. INTRODUCTION The Controller Area Network(CAN) is a serial bus communications protocol developed by Bosch in the early1980s. It provides a preferrable and reliable communication between actuators,controllers, sensors and other nodes in real time systems. CAN is a standardprotocol for many number of control systems in network embedded.CAN basicallydeveloped for Vehicle industry. It can be found in vehicles like cars, trucks,boats etc. Nowerdays, the protocol is also used in industries for automationand network embedded control, with application in products such as medicalequipments, weaving machines, production machinery and wheel chairs etc. In theautomotive industry, embedded control has grown from stand-alone systems tohighly integrated and networked control systems in such industries.
By making anetwork of electro-mechanical subsystems, it become possible to change thefunctionalities and hardware, which gives us a chance to reuse it. The ECUhandles the control of engine, turbo and fan, etc. but also the CANcommunication. Combination of networks and mechatronics modules reduces thecabling distances and system response time, which gives more production andreliability.
Introducing networks in vehicles also makes it possible to moreefficiently carry out diagnostics and to coordinate the operation of the separatesubsystems.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 toenable efficient development and operation. Such protocols are needed fordefining how the CAN protocol should be used in applications, for example, howto refer the configuration of identifiers with respect to applicationmessages,how to package application messages into frames, and how to deal withstart-up and fault handling.Note also that real-time issues and redundancymanagement OSI layers are required. are not covered by the Kathiravan.N Assistant Professor, Dept of EEE,Amritauniversity, Coimbatore, Tamilnadu, [email protected]
com OSI model. The adoption of CAN in a variety of applicationfields has led to the development of several higher-layer protocols, includingSAE J1939, CANopen, DeviceNet, and CAN Kingdom. Their characteristics reflectdifferences in requirements and traditions of application areas. An example isthe adoption of certain communication models, such as either the client-servermodel or the distributed data-flow model. The progress and success of CAN aredue to a number of devices through which it can communicate.
The evolution ofmicroelectronics led the way for introducing distributed control system invehicles. In the early 1980s there was, however, a lack of low-cost andstandardized protocols suitable for real-time control systems. Therefore, in1983 Kiencke started the development of a new serial bus system at Bosch. APPLICATION PRESENTATION SESSION TRANSPORT NETWORK CAN DATA LINK PHYSICAL Fig.
1: OSI model The CAN protocol defines the lowest two layers of the OSImodel. There exist several CAN-based higher-layer protocols that arestandardized. The user choice depends on the application. II. BACKGROUND CAN (or CANbus) is amulti-master broadcast serial bus standard designed to enable communicationbetween embedded devices without requiring a host computer. The latest versionof the CAN specification is CAN 2.0. CAN was internationally standardized asISO11898-1 in 1993,and they sold more than two billion CAN nodes to all theindustriesavailable at that time.
CAN isone of the protocols used in the OBD-II on-board diagnostic standard mandatoryon all autos sold in the United States from 1996 onward. CAN become a mandatorypart of all gasoline powered vehicles sold in the European Union from 2001 andall diesel-powered vehicles since 2004. And also CAN become a mandatory part ofJOBD on Japanese cars since 2001, and is part of the OBD system that ismandatory on certain light vehicles in China from 2008.Aspects of CAN have beencodified in various ISO standards. § ISO11898-5:2007 specifies the CAN physical layer for transmission rates up to 1Mbps. § ISO11898-1:2003 specifies the CAN data link layer (DLL) and physical signaling. § ISO 15765-2:2004 specifies the CAN network protocol. § ISO15765-4:2005 specifies a CAN variant specifically for emissions-related systemsbased on ISO 15765-2, ISO 11898-1, and ISO 11898-2, with the addition ofvarious constraints.
CAN was targeted originally for automotive applications, butadoption of CAN has spread to other markets because of it reliability andeconomical cost. CAN is now used in vehicles from trains to ships, as well asin military, aerospace, and industrial control applications. III THE CAN PROTOCOL The CAN communication protocol is a CSMA/CD protocol. TheCSMA stands for Carrier Sense Multiple Access. What this means is that everynode on the network must monitor the bus to check whether the bus is idle ornot, before sending the data in it (Carrier Sense). Also,once this period of noactivity occurs, every node on the bus has an equal opportunity to transmit amessage (Multiple Access) in bus.
The CD stands for Collision Detection. If twonodes start sending data at a time the data will be collided and requiredaction will be taken. In the CAN protocol, a nondestructive bitwise arbitrationmethod is utilized. This means that messages remain intact after arbitration iscompleted even if collisions are detected. All of this arbitration takes placewithout corruption or delay of messages.
The CAN protocol is amessage-based, not an address based protocol. This means that messages are nottransmitted from one node to another node based on addresses. Embedded in theCAN 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 toeach node in the system to decide whether the message received should beimmediately discarded or kept to be processed. A major benefit of thismessage-based protocol is that additional nodes can be added to the systemwithout the necessity to reprogram all other nodes to recognize this addition.
This new node will start receiving messages from the network and, based on themessage identifier (ID), decide whether to process or discard the receivedinformation.CAN nodes have the ability to determine fault conditions andtransition to different modes based on the severity of problems beingencountered. They also have the ability to detect short disturbances frompermanent failures and modify their functionality accordingly. CAN nodes cantransition from functioning like a normal node (being able to transmit andreceive messages normally), to shutting down completely (bus-off) based on theseverity of the errors detected. This feature is called Fault Confinement.
Nofaulty CAN node or nodes will be able to monopolize all of the bandwidth on thenetwork because faults will be confined to the faulty nodes and these faultynodes will shut off before bringing the network down. The CAN protocol alsoprovides sophisticated error detection and error handling mechanisms such asCyclic Redundancy Check (CRC) and high immunity against electromagneticinterference. Temporary errors are recovered.
Permanent errors are followed byautomatic switch-off of defective nodes. Every node in the system is informedabout an error. This is very powerful because both Fault Confinement and theerror detection methods guarantee bandwidth for critical system information. Fig. 2: DATA FORMATS. In CAN module, data transmission and reception is done withthe help of message frames. Message Frames carry data with it and broadcast itto the other nodes in the network. The required node willreceive the data.
. The CAN protocol has two Message Frame formats.§ StandardCAN (Version 2.0A) uses 11 bit identifier. § ExtendedCAN (Version 2.
0B) uses 29 bit identifier. Most Standard CAN controllers transmit and receive onlyStandard format messages, whereas some (known as 2.0B passive) will receiveExtended format messages 32 but then ignore them. Extended CAN controllers cansend and receive messages in both the formats. 1) STANDARD CAN (VERSION 2.
0A) FORMAT AStandard CAN (Version 2.0A) Message Frame consists of different bit fields: a) AStart of Frame (SOF) field. This is a dominant (logic 0) bit that indicates theintialization of a data frame.
b) AnArbitration field, containing an 11 bit message identifier and the RemoteTransmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates thatthe message is a Data Frame. A recessive (logic 1) value indicates that the message isa Remote Transmission Request. A Remote Frame is a request by one node for datafrom transmitting node in the bus.
Data Field is not required for Remote Frames. c) AControl Field containing six bits where r0 and r1 are two dominant bits, thatare reserved for future use and Data Length Code of four Bits (DLC). Data Fieldhas DLC which indicates the number of bytes.A Data Field, containing from zeroto eight bytes. d) The CRC field, contains fifteen bitcyclic redundancy check code and a recessive delimiter bit.
e) TheACKnowledge field, consist of two bits. The first one is the Slot bit which istransmitted as a logic „0? (recessive bit), but it is over written by logic „1?(dominant bit) is transmitted from all other nodes that successfully receivethe message. The second bit is a recessive delimiter bit.
f) End of Frame field, It consists ofseven recessive bits. Following the end of a frame is the Intermission field whichconsist of three recessive bits. After the three bit Intermission period thebus is recognised to be free. Bus Idle time may be of any arbitrary lengthincluding 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) bitidentifier as opposed to the 11 bit identifier in Standard CAN. Extended CANevolved to provide compatibility with other serial communications protocolsused in automotive applications in the industries. To make it more efficientand provide compatibility with the 2.0A format, the Message Frame in Version2.0B has an extended format. Thedifferences are: a) InExtended CAN, the Arbitration field contains two identifier bit fields.
Thefirst the base ID is eleven (11) bits long for compatibility withVersion 2.0A. The second field the ID extension is eighteen (18) bits long, toprovide a total length of twenty nine (29) bits.
b) The distinction between the twoformats is done by using an Identifier Extension (IDE) bit. c) ASubstitute Remote Request (SRR) bit is included in the Arbitration Field. TheSRR bit is always transmitted as a logic „0? bit to ensure that, in the case ofarbitration between a Standard Data Frame and an Extended Data Frame, theStandard Data Frame will always be given high priority where both messages havethe same base (11 bit) identifier.
All other fields in a Extended CAN Message Frame areidentical to those in the Standard format. Refer fig2 for data format andtheir clear picture. But I have chosen 11bit identifier because the CAN datacommunication is between only two controllers. V SYSTEM ARCHITECTURE The proposed system focuses on data transfer betweencontrollers which reduces the time of data transmission, complexity and powerconsumption. The overview block diagram of the system as follows : X data in ARM7LPC 2129(1) High Low ARM7LPC 2129(2) X data out Fig. 3: BLOCK DIAGRAM OF PROPOSEDSYSTEM.The two ARM 7 LPC 2129 CANcontrollers 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 datawill be transmitted from controller 1 and received in controller 2 as data „X?. VI PROCEDURE CAN Intialization DataTransmission (controller1) Dominant NOData? WAIT YES CAN Bus Data NO Received? YES Process Data (Controller2) Fig.4: FLOW CHART FOR CAN DATA TRANSMISSION.
CAN initialization is done and data is transferred from thecontroller1. CAN features a collision and arbitration free transmission. TheMessage Frame with high priority will be sent without any hurdle while lowpriority message will back off and wait till the execution of high prioritymessage.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 ofthe bus. If one node with dominant bit wins the bus for data transmission. Ifthe dominant bit over writes the recessive bit, after the execution of thedominant bit it evidences the collision. A dominant bit is asserted by creatinga voltage across the wires while a recessive bit is simply not asserted on thebus. If any node sets a change in the voltage, High priority message will nothave any delay in transmitting message while low priority message automaticallyretransmit the data frame after the end of dominant message. carrier sensemultiple access/bitwise arbitration (CSMA/BA) scheme is often play a major rolein this protocol.
Prioritized arbitration (dominant message is delay free) is the solution for CAN to be very suitable inreal time applications. During the transmission, some other node startstransmiting the message frames. Then the transmitting nodes stops and comparesthe arbitration. If the interrupted message frame is dominant then it takescontrol of the bus and start transmitting the data.
(i.e., it lostarbitration).
Arbitration is performed during the transmission of theidentifier field. Each node starting to transmit at the same time sends an IDwith dominant as binary 0, starting from the high bit. As soon as their ID is alarger 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 onemust have been in wait state, and the highest priority message gets throughunimpeded and takes the bus. Once the data is received properly or not ischecked. If not data is transmitted once again and processed. CAN follows thepriority level in such a way “Lower the Binary Number, Higher the Priority”.
VI RESULT 1) SIMULATED RESULT: Steps to obtain simulated result asfollows: a) EmbeddedC code is written for ARM7 LPC2129 controller in Keil software for CAN datatransmission. b) Compile-> Debug -> Peripherals -> CAN -> Communication, Controller,Transmit, Receive and Filters. c) The transmission of DATA and ID willbe visible in the below mentioned windows with all other required informationin it. So the fig 5 gives the simulated output of faster datatransmission between Controllers.
The column Tx1 ID & Data contains C2TID1(CAN ID) and C2TDA1 (Data) transmits the data with ID to C2RDA which is in thecolumn of Rx ID & Data. The data transmission between two controllers ismarkedclearly in the fig 5 which shows the ID and Data a voltage of3.75 and 1.
25v respectively.fig7 and fig8 showstransmission. theHigh and Low voltage signals as follow: Fig.5: SIMULATION RESULT FOR CAN DATA TRANSMISSION. 2) HARDWARE RESULT: Fig.6: HARDWARE SETUP FOR CAN DATA TRANSMISSION.
Fig 5refers the quick data transfer between ARM7 LPC 2129 connected serially withHigh and Low twisted pair of wires. The data transmission can be verified byusing the DSO with two channels CH1 and CH2 having high and low signal having Fig. 7: CRO RESULTFOR CAN DATA TRANSMISSION (HIGH). Fig.
8: CRO RESULT FOR CAN DATATRANSMISSION (LOW). . VII CONCLUSION AND FUTURE WORKS. The execution of fast datatransfer between ARM7 controllers is successful and verified using DSO. Infuture, planned to add many controllers together and analyse the networkbehavior like data collision and corruption.
Then, assigning the tasks for thedata transferred via CAN to actuate peripherals like motors, buzzer, andsolenoid valves etc…