The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss.
As demonstrated in the image below, 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. They are provided by higher layer protocols such as CANopen, DeviceNet, and J1939 (see Chapter 3.5 - Higher Layer Protocols).
For more information on the OSI Reference Model refer to:
CertificationZone.com OSI Reference Model Pocket Guideby Howard C. Berkowitz - ISBN: 1890911143
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.
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. This reduces the software development process by concentrating solely on the coding of the actual application software.
Most CAN 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 that represent 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.
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 Guide To J1939 by Wilfried Voss. The J1939 Standards Collection was designed to follow the ISO/OSI 7-Layer Reference Model as far as necessary. Each layer is addressed by a corresponding document. The SAE has named documents addressing the transport (4), session (5), and presentation (6) layer in the ISO/OSI 7-Layer [...]
The following is an excerpt from A Comprehensible Controller Area Network by Wilfried Voss. The ISO/OSI Reference Model specifies seven levels starting with the physical connection up to the actual user application, i.e., the Application Layer. The standard CAN Bus implementation neglects the connection between the Data Link Layer and the Application Layer to save on relevant memory resources [...]