The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss.
Like any field-bus system based on serial communication, Controller Area Network will reduce wiring, which was initially considered an advantageous side effect. Distributed control, i.e., the use of a multi-processor system, will consequently result in increased performance. The vastly reduced costs of microcontroller chips in the market made the use of multiple processors in one system affordable. Other advantages include increased reliability and improved service and maintenance features.
Another significant benefit of applying the CAN Bus technology is apparent during the time-consuming and costly hardware and software development process. The Physical Layer and the Data Link Layer, as defined in the ISO 11898 standard, are already implemented in silicon, either in the form of a stand-alone CAN controller or integrated into multi-function single-chip microcontrollers.
CAN Bus Controller Firmware
As demonstrated in picture 3.1.1, the ISO/OSI Reference Model specifies seven levels beginning with the physical connection to the actual user application, i.e., the Application Layer.
The standard CAN implementation bypasses the connection between the Data Link Layer and the Application Layer to save on valuable memory resources by minimizing the overhead and, as a result, gaining performance as needed for embedded solutions with limited resources.
Layers 3 through 6, i.e., all layers above the Data Link Layer, require additional software resources provided by higher layer protocols such as CANopen, DeviceNet, and J1939 (see Chapter 3.5 - Higher Layer Protocols).
The Application Layer is the layer that interacts with the operating system or application of the CAN device.
The Data Link Layer connects the actual data to the protocol to send, receive, and validate data. Under CAN, it represents the data exchange, including error detection/recovery and fault confinement, transmission acknowledgments, etc., and all the ingenious features as previously described in Chapter 2 - Main Characteristics.
The Physical Layer represents the actual hardware, i.e., the physical connection between nodes in a network and the electrical signal characteristics such as voltage levels and timing.
Note: Whenever you attempt to add software functions between the CAN Data Link Layer and the Application Layer, you will be adding functionalities that are already covered by off-the-shelf available higher layer protocols such as CANopen and DeviceNet.
The software development engineer will benefit from the fact that under CAN, the two lowest layers, the Physical Layer and Data Link Layer, are already integrated into silicon. The on-chip method reduces the software development process by concentrating solely on the coding of the actual application software.
Most CAN Bus chip manufacturers and vendors in the CAN business provide source code (e.g., for LINUX) and libraries (e.g., Windows APIs) for all function calls representing the connection between the Data Link Layer and the Application Layer.
The nature of the necessary function calls is identical to those needed for the access of any hardware device (drivers):
- Read Data
- Write Date
- Check Status
Naturally, this is just an elementary list of function calls. Most code libraries provide extended functionality like the determination of the busload and more.
Speed, Reliability, and Error-Resistance
The CAN Bus technology provides the ability to function in challenging electrical environments, a high degree of real-time capability, and ease of use. The real-time capabilities are supported by extremely short arbitration times in the range of microseconds, limited data length, and extremely short error recovery times, again, in the range of microseconds.
The reliability and error resistance of CAN has been calculated in a mathematical model. Here is an example using the following parameters and conditions:
- 1 Bit error every 0.7 sec
- Baud rate of 500 kBit/sec
- Operation of 8 hours/day and 365 days/year
According to the mathematical model, the Residual Error Probability will be 1 undetected error in 1000 years. (Source: CAN-in-Automation)
PiCAN 2 - CAN Bus Interface for Raspberry Pi
This PiCAN2 board provides Controller Area Network (CAN) Bus capabilities for the Raspberry Pi. It uses the Microchip MCP2515 CAN controller with MCP2551 CAN transceiver. Connection are made via DB9 or 3-way screw terminal.
There is an easy-to-install SocketCAN driver, and programming can be accomplished in C or Python.
The PiCAN board is fully compatible with the new Raspberry Pi 4 Model B.
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. Everything that has to do with Controller Area Network (CAN) is based on maximum reliability with the maximum possible performance in mind. After all, CAN was initially designed for automobiles, definitely a very demanding environment for microprocessors, not only regarding required electrical robustness [...]
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. One frequently asked question is regarding any other field of application, besides automobiles, where CAN is successfully used. There is not just one answer, but many. There is no particular niche for CAN; its use is universal from any industrial application, space, aviation, maritime, [...]
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. The idea of Controller Area Network (CAN) was hatched by engineers at the Robert Bosch GmbH in Germany in the early 1980s. They investigated the market for a suitable field-bus technology for use in automobiles that would enable them to add additional functionality. [...]
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation and other applications. The CAN bus is primarily used in embedded systems, [...]
Introduction Welcome to my beginner's guide! By opening this page, you have entered the first and probably most crucial stage toward developing your SAE J1939 project: Reading. Over the years, I dealt with many newcomers to the J1939 technology, some of them motivated by great product ideas. Others were thrown into a project because they were [...]
For the longest time, the major misconception about Controller Area Network (CAN) was that it merely applies to automobiles. The truth is, CAN, since its introduction in 1986, proved to be a robust, versatile, and straightforward technology and, consequently, the CAN Bus technology found its way into all areas of applications where microprocessors need to [...]
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. Controller Area Network, like any field-bus system based on serial communication, will reduce wiring, which was initially considered only as an advantageous side effect. Distributed control, i.e., the use of a multi-processor system, will consequently result in increased performance, and the vastly reduced costs [...]
LIN To CAN Bus Gateway - Prototyping And Firmware Development With The Arduino-Compatible Teensy Board
In general, let's start with a brief comparison of CAN Bus (Controller Area Network) and LIN Bus (Local Interconnect Network): LIN Bus networks provide cost-efficient communication in applications where the bandwidth and versatility of the CAN Bus technology are not required. LIN Bus applications are relatively inexpensive using the standard serial universal asynchronous receiver/transmitter (UART) technology, which are embedded [...]
There are many applications, in which one may need to reverse engineer CAN Bus communication. Examples are automotive competitor analysis, telematics applications such as fleet management, and disabled driver applications. The typical reverse engineering process is concerned with moving a sensor and watching the CAN Bus network for message changes. For example, wind down a door [...]