The Linux kernel supports using CAN-devices through a network-like API (see https://www.kernel.org/doc/Documentation/networking/can.txt). This crate allows easy access to this functionality without having to wrestle libc calls.
The CAN bus was originally designed to allow microcontrollers inside a vehicle to communicate over a single shared bus. Messages called frames are multicast to all devices on the bus.
Every frame consists of an ID and a payload of up to 8 bytes. If two devices attempt to send a frame at the same time, the device with the higher ID will notice the conflict, stop sending and reattempt to sent its frame in the next time slot. This means that the lower the ID, the higher the priority. Since most devices have a limited buffer for outgoing frames, a single device with a high priority (== low ID) can block communication on that bus by sending messages too fast.
The Linux socketcan subsystem makes the CAN bus available as a regular networking device. Opening an network interface allows receiving all CAN messages received on it. A device CAN be opened multiple times, every client will receive all CAN frames simultaneously.
Similarly, CAN frames can be sent to the bus by multiple client simultaneously as well.
More information on CAN can be found on Wikipedia. When not running on an embedded platform with already integrated CAN components, Thomas Fischl's USBtin (see section 2.4) is one of many ways to get started.
Raw access to the underlying file descriptor and construction through
is available through the
candump format parsing
A socket for a CAN device.
Error decoding a CANError from a CANFrame.
Errors opening socket
Error that occurs when creating CAN packets
if set, indicate 29 bit extended format
valid bits in extended frame id
valid bits in error frame
remote transmission request flag
valid bits in standard frame id
Check an error return value for timeouts.