Introducing CAN
Controller Area Network (CAN) is the de-facto protocol for communication between embedded devices. It was developed by Bosch in 1983 and was designed originally to be used in automotive industry where many systems within a car need to be communicated with a central ECU.
CAN or CAN-bus is a vehicle bus standard design to allow microcontrollers and devices to communicate within a vehicle without a host computer.
CAN is a high integrity serial data communications bus for real time control applications. Operates at data rates up to 1Mbits/s over links up to approximately 40m.
Controller Area Network (CAN) is the de-facto protocol for communication between embedded devices. It was developed by Bosch in 1983 and was designed originally to be used in automotive industry where many systems within a car need to be communicated with a central ECU.
CAN or CAN-bus is a vehicle bus standard design to allow microcontrollers and devices to communicate within a vehicle without a host computer.
CAN is a high integrity serial data communications bus for real time control applications. Operates at data rates up to 1Mbits/s over links up to approximately 40m.
Principle
A typical CAN message contains an ID (11 or 29 bits long) in the header and is followed by 8 bytes of data. There are other pieces of information in the message such as SOF (Start of Frame) and a 15 bit CRC.
Data messages transmitted from any node of a CAN bus does not contain addresses of either of the transmitting node or any of the intended receiving mode. Instead, the content of the message (e.g. Revolutions per minute, etc.) is labeled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.
If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority.
In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and no messages are lost.
CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure that any transmission errors are detected.
Data messages transmitted from any node of a CAN bus does not contain addresses of either of the transmitting node or any of the intended receiving mode. Instead, the content of the message (e.g. Revolutions per minute, etc.) is labeled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.
If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority.
In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and no messages are lost.
CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure that any transmission errors are detected.
CAN Analyzer
A CAN Analyzer is an efficient and versatile tool for analysis of CAN-based networks. This development and service tool aids an engineer to observe record and analyze communication protocols on CAN bus at a logical level. The analyzer distinguishes itself by its programmability and ability to work with different hardware interfaces.
A CAN tool specification
• Multi channel functionality
• Inter-window, time synchronous analysis of received data
• Graphic highlighting of altered data contents
• Communication with the CAN driver and the hardware is carried out centrally via a communication server
• Analysis of functions are provided by separate function modules; customer-specific functions can be integrated using individual modules
• Safe reception of CAN messages and time oriented buffering, even with high bus loads and baud rates.
A CAN tool specification
• Multi channel functionality
• Inter-window, time synchronous analysis of received data
• Graphic highlighting of altered data contents
• Communication with the CAN driver and the hardware is carried out centrally via a communication server
• Analysis of functions are provided by separate function modules; customer-specific functions can be integrated using individual modules
• Safe reception of CAN messages and time oriented buffering, even with high bus loads and baud rates.
No comments:
Post a Comment