Introduction
The CAN bus was developed by BOSCH (1) as a mufti-master, message broadcast system that specifies a maximum signaling rate of 1 megabit per second (bps). Unlike a traditional network such as USB or Ethernet, CAN does not send large blocks of data point-to-point from node A to node B under the supervision of a central bus master. In a CAN network, many short messages like temperature or RPM are broadcast to the entire network, providing data consistency in every node of the system. Once CAN basics such as message format, message identifiers, and bit-wise arbitration — a significant benefit of the CAN signaling scheme are explained, a CAN bus implementation is examined, typical waveforms are presented, and transceiver features are reviewed.
Components required table
| S.N. | COMPONENTS | DESCRIPTION | QUANTITY | link |
| 1 | LAUNCHXL-F28379DSM | LAUNCHXL-F28379D | 1 | LAUNCHXL-F28379D |
| 2 | Logic Analyser | Logic Analyser | 1 | Logic Analyser |
| 3 | connection wires | Jumper Wires | 40 | Jumper Wires |
| 4 | Oscilloscope | Oscilloscope | 1 | Oscilloscope |
Software Requirements
In this workshop we are interfacing can using tms320
To interface can communication we are using CAN_B Port for data transmission and reception.
| S.No | GPIO_PIN |
| 1 | GPIO_17_CANRXB |
| 2 | GPIO_12_CANTXB |
GPIO Connection In LAUNCHXL-F28379D
TMS320F28x CAN Features
- Full implementation of CAN protocol, version 2.0B
- 32 mailboxes, each with the following properties:
- Configurable as receiving or transmit
- Configurable with standard or extended identifier
- Has a programmable receive mask (every mailbox has its own mask)
- Supports data and remote frame
- Composed of 0 to 8 bytes of data
- Uses a 32-bit time stamp to receive and transmit a message
- Protects against reception of the new message
- Holds the dynamically programmable priority of transmitting a message
- Employs a programmable interrupt scheme with two interrupt levels
- Employs a programmable alarm on transmission or reception time-out
- Low-power mode
- Programmable wake-up on bus activity
- Automatic reply to a remote request message
- Automatic retransmission of a frame in case of loss of arbitration or error
- 32-bit Time Stamp Counter (TSC), which can be synchronized by a specific mailbox
What are some real-world applications of CAN?
- Controller Area Networks are used in many different fields, the bulk of which are
- Automotive industry
- Factory Automation
- Machine Control
- Medical Equipment and devices
And more….
Why is CAN used?
- Robust in noisy environments
- Priority Signal Setting
- All devices on the network receive every bit of information sent on the BUS
- Cost Effective
CAN bus Communication Speed and Distance
The CAN bus is a bus that connects multiple units at the same time. There is theoretically no limit to the total number of units that can be connected. In practice, however, the number of units that can be connected is limited by the time delay on the bus and the electrical load. Reduce the speed of communication, increase the number of units that can be connected, and increase the speed of communication, the number of units that can be connected decreases.
The communication distance is inversely related to the communication speed, and the farther the communication distance, the smaller the communication speed. The longer distance can be 1km or more, but the speed is less than 40kps.
Arbitration limits bus speed. Maximum speed = 2 x tpd
tpd = propagation delay of electrical medium
Standardization
- Vehicle bus system applications can be separated in three different categories according to their real-time capabilities.
- Class A for a low-speed bus with bit rates up to 10 kbps, e.g for body control applications,
- Class B for a low-speed bus with bit rates from 10 kbps to 125 kbps, e.g. for dashboard and diagnostics,
- Class C for a high-speed bus with bit rates from 125 kbps to 1 Mbps for real-time applications like engine management, Gearbox, ABS etc.
Fallowing table contain the maximum distance cover by can bus according to the signal rate
Bus Levels according to ISO-IS 11898
- These are the bus levels according to ISO-IS 11898. A recessive bit is represented by both CAN bus lines driven to a level of about 2.5 V so that the differential voltage between CAN_H and CAN_L is around 0 V.
- A dominant bit is represented by CAN_H going to about 3.5 V and CAN_L going to about 1.5 V. This results in a differential voltage for a dominant bit of about 2V
CAN Bus wire solution
Example:
If the user uses Baudrate 100 kbit/s and wire cross-section 0.5 mm2, the maximum length can arrive to 500 m. But the maximum length is in inverse proportion to the node number. When the node number is up to 32, the maximum length will be down to 360 m.
How CAN Communication Protocol works?
The CAN communication protocol is a carrier-sense, multiple-access protocol with collision detection and arbitration on message priority (CSMA/CD+AMP). CSMA means that each node on a bus must wait for a prescribed period of inactivity before attempting to send a message. CD+AMP means that collisions are resolved through a bit-wise arbitration, based on a preprogrammed priority of each message in the identifier field of a message.
The higher priority identifier always wins bus access. That is, the last logic high in the identifier keeps on transmitting because it is the highest priority. Since every node on a bus takes part in writing every bit “as it is being written,” an arbitrating node knows if it placed the logic-high bit on the bus. The ISO-11898:2003 Standard, with the standard 11-bit identifier, provides for signaling rates from 125 kbps to 1 Mbps. The standard was later amended with the “extended” 29-bit identifier. The standard 11-bit identifier field in Figure 2 provides for 2 11, or 2048 different message identifiers, whereas the extended 29- bit identifier in Figure 3 provides for 2 29, or 537 million identifiers.
CAN Frames
A CAN network can be configured to work with two different messages (or “frame”) formats: the standard or base frame format (described in CAN 2.0 A and CAN 2.0 B), and the extended frame format (described only by CAN 2.0 B). The only difference between the two formats is that the “CAN base frame” supports a length of 11 bits for the identifier, and the “CAN extended frame” supports a length of 29 bits for the identifier, made up of the 11-bit identifier (“base identifier”) and an 18-bit extension (“identifier extension”). The distinction between the CAN base frame format and the CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in the case of an 11-bit frame, and transmitted as recessive in the case of a 29-bit frame. CAN controllers that support extended frame format messages be also able to send and receive messages in CAN base frame format? All frames begin with a start-of-frame (SOF) bit that denotes the start of the frame transmission.
CAN has four frame types:
- Data frame: a frame containing node data for transmission
- Remote frame: a frame requesting the transmission of a specific identifier
- Error frame: a frame transmitted by any node detecting an error
- Overload frame: a frame to inject a delay between data or remote frame
Data frame
There are two types of data frames,
- Standard CAN – with 11 identifier bits
- Extended CAN – with 29 identifier bits
Standard CAN
Basic message frame format
// Initialize the transmit message object used for sending CAN messages.
// Message Object Parameters:
// Message Identifier: 0x5555
// Message ID Mask: 0x0
// Message Object Flags: None
// Message Data Length: 4 Bytes
// Message Transmit data: txMsgData
//
sTXCANMessage.ui32MsgID = 0x5555;
sTXCANMessage.ui32MsgIDMask = 0;
sTXCANMessage.ui32Flags = 0;
sTXCANMessage.ui32MsgLen = MSG_DATA_LENGTH;
sTXCANMessage.pucMsgData = txMsgData;
The frame format is as follows: The bit values are described for CAN-LO signal.
Extended CAN
As shown in Figure 3, the Extended CAN message is the same as the Standard message with the addition of:
- SRR–The substitute remote request (SRR) bit replaces the RTR bit in the standard message location as a placeholder in the extended format.
- IDE–A recessive bit in the identifier extension (IDE) indicates that more identifier bits follow. The 18-bit extension follows IDE.
- r1–Following the RTR and r0 bits, an additional reserve bit has been included ahead of the DLC bit.
The CAN Data Frame
The CAN data frame is composed of seven fields: Start of the frame (SOF), arbitration, control, data, cyclical redundancy check (CRC), acknowledge (ACK), and end of frame (EOF). CAN message bits are referred to as “dominant” (0) or “recessive” (1). The SOF field consists of one dominant bit. All network nodes waiting to transmit synchronize with the SOF and begin transmitting at the same time. An arbitration scheme determines which of the nodes attempting to transmit will actually control the bus.
Arbitration
The arbitration field of the CAN message consists of an 11- or 29-bit identifier and a remote transmission (RTR) bit. The CAN arbitration scheme is called “carrier sense multiple access with collision detection” or CSMA/CD, and assures that the highest priority message is broadcast. Message priority is determined by the numerical value of the identifier in the arbitration field, with the lowest numerical value having the highest priority. Non-destructive, bit-wise arbitration resolves conflicts among competing transmitters. This means that the bus can be thought of as acting like an AND gate: If any node writes a dominant (0) bit on the bus, every node will read a dominant bit regardless of the value written by that node. Every transmitting node always reads back the bus value for each bit transmitted. If a node transmits a recessive bit and reads back a dominant bit, it immediately stops transmitting. Arbitration is illustrated in Figure 3.
The RTR bit simply distinguishes between data frames and remote frames. In data frames, the RTR bit must be dominant; in remote frames, it must be recessive.
Control and Data Fields
Note 1: It is worth noting that the presence of an Acknowledgement Bit on the bus does not mean that any of the intended addressees has received the message. The only thing we know is that one or more nodes on the bus have received it correctly
Note 2: The Identifier in the Arbitration Field is not, despite its name, necessarily identifying the contents of the message.
CAN 2.0A (“standard CAN” 11-bit ID) Data Frame.
CAN 2.0B (“extended CAN” 29-bit ID) Data Frame.
The Remote Frame
Summary: “Hello everyone, can somebody please produce the data labeled X?”
The Remote Frame is just like the Data Frame, with two important differences:
It is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and there is no Data Field.
The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234.
Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behavior outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame or to notify the local CPU instead.
Remote Frame (contd.)
There’s one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise, the arbitration will not work.
Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby “filling up” the empty Remote Frame. This is not the case.
A Remote Frame (2.0A type):
- CAN and EMI
Due to the differential nature of transmission, CAN is insensitive to electromagnetic interference, because both bus lines are affected in the same way which leaves the differential signal unaffected.
To reduce the sensitivity against electromagnetic interference, even more, the bus lines can additionally be shielded. This also reduces the electromagnetic emission of the bus itself, especially at high baud rates.
Final code for CAN Transmit to Single ID
// CAN Communication for data transmition for single ID ////////////
//
#include "F28x_Project.h"
#include "F2837xD_device.h"
#include "F2837xD_Examples.h"
#include "device.h"
#include "driverlib.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <math.h>
#define TX_MSG_OBJ_ID 1
#define MSG_DATA_LENGTH 8
uint16_t txMsgData_1[8]={0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08};
void main(void)
{
Device_init();
Device_initGPIO();
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANRXB);
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANTXB);
CAN_initModule(CANB_BASE);
CAN_setBitRate(CANB_BASE, DEVICE_SYSCLK_FREQ, 500000, 16);
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID, 0x18FB47FF,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_TX, 0,
CAN_MSG_OBJ_NO_FLAGS, MSG_DATA_LENGTH);
CAN_startModule(CANB_BASE);
EINT;
while(1)
{
CAN_sendMessage(CANB_BASE, TX_MSG_OBJ_ID, MSG_DATA_LENGTH, txMsgData_1);
while(((HWREGH(CANB_BASE + CAN_O_ES) & CAN_ES_TXOK)) == CAN_ES_TXOK)
{
}
DEVICE_DELAY_US(1000000);
}
}
Monitor the CAN data using an oscilloscope
Connect the positive terminal of the oscilloscope to the CAN_H
Negative terminal connect to the CAN_L as shown in the below figure
Output waveforms
Final code for CAN data Transition for multiple ID’S
/*
* main.c
*
* Created on: 16-Sep-2021
* Author: Admin
*/
//
#include "F28x_Project.h"
#include "F2837xD_device.h"
#include "F2837xD_Examples.h"
#include "device.h"
#include "driverlib.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <math.h>
//
// Defines
//
#define TXCOUNT 100000
#define MSG_DATA_LENGTH 8
#define TX_MSG_OBJ_ID 1
#define TX_MSG_OBJ_ID_2 2
#define TX_MSG_OBJ_ID_3 3
uint16_t txMsgData_1[8]={0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08};
uint16_t txMsgData_2[8]={0X09,0X10,0x11,0x12,0x13,0x14,0x15,0x16};
uint16_t txMsgData_3[8]={0X17,0X18,0x19,0x20,0x21,0x22,0x23,0x24};
void main(void)
{
Device_init();
//
// Initialize GPIO and configure GPIO pins for CANTX/CANRX
// on module A
//
Device_initGPIO();
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANRXB);
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANTXB);
CAN_initModule(CANB_BASE);
CAN_setBitRate(CANB_BASE, DEVICE_SYSCLK_FREQ, 500000, 16);
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID, 0x18FB47FF,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_TX, 0,
CAN_MSG_OBJ_NO_FLAGS, MSG_DATA_LENGTH);
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID_2, 0x12345,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_TX, 0,
CAN_MSG_OBJ_NO_FLAGS, MSG_DATA_LENGTH);
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID_3, 0x6789A,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_TX, 0,
CAN_MSG_OBJ_NO_FLAGS, MSG_DATA_LENGTH);
CAN_startModule(CANB_BASE);
while(1)
{
CAN_sendMessage(CANB_BASE, TX_MSG_OBJ_ID, MSG_DATA_LENGTH, txMsgData_1);
CAN_sendMessage(CANB_BASE, TX_MSG_OBJ_ID_2, MSG_DATA_LENGTH, txMsgData_2);
CAN_sendMessage(CANB_BASE, TX_MSG_OBJ_ID_3, MSG_DATA_LENGTH, txMsgData_3);
while(((HWREGH(CANB_BASE + CAN_O_ES) & CAN_ES_TXOK)) == CAN_ES_TXOK)
{
}
DEVICE_DELAY_US(1000000);
}
}
