Linux and PEAK-System's CAN Interfaces

Drivers Included in Linux Kernels

Key Features

• Out-of-the-box usage, suitable for most use cases
• CAN channels are handled as network devices (SocketCAN)
• Part of the Linux mainline kernel:
  
  

Check 1: Are CAN drivers part of your Linux environment?

Open a terminal and type: grep PEAK_ /boot/config-`uname -r`

All PEAK drivers are listed (y = included in kernel, m = separate module) but this may not work in every Linux environment.

Check 2: Is the CAN device initialized?

Open a terminal and type: lsmod | grep ^peak

If, for example, a USB-based CAN interface from PEAK is connected and initialized, the output will be at least one line starting with peak_usb.

Check 3: Which kernel version is required for your PEAK CAN interface?

We provide a script to check which kernel version is required for running your PEAK CAN interface.

1. Download the packed script: pcan-kernel-version.sh.tar.gz
2. To extract it open a terminal and type: tar -xzf pcan-kernel-version.sh.tar.gz
3. Execute the script with ./pcan-kernel-version.sh

In case of the PCAN-USB FD two kernel version requirements are possible:

Bus 001 Device 003: ID 0c72:0012 PEAK System PCAN-USB FD needs Linux 4.0
Bus 002 Device 002: ID 0c72:0012 PEAK System PCAN-USB FD needs Linux 6.0

USB - CAN Socket Driver: dealing with canX interfaces names under Linux 6.3

Connecting, disconnecting, reconnecting USB - CAN interfaces is convenient since the driver loads itself into memory, but it has the disadvantage that the name of the CAN interfaces depends on the connection order. Using a (so-called) "device id" in this case solves this problem. The device id is a number chosen by the user and flashed in the device itself.

Starting from Linux 6.3, the device id is attached to a CAN channel (unlike Windows where the device id is attached to the device itself). Thus, a PCAN-USB Pro FD will offer to define TWO device ids under Linux while only one will be possible under Windows. To access the flash memory of the USB - CAN interface, one uses the ethtool tool as follows:

To read the flash memory of "can0" interface:

$ sudo ethtool -e can0 raw off
Offset Values
------ ------
0x0000: 00 

To write value "1":

$ sudo ethtool -E can0 value 1

This device id is also readable through the sysfs interface, by displaying the content of the "can_channel_id" file of the concerned CAN network interface:

$ cat /sys/class/net/can0/peak_usb/can_channel_id 
00000001

The purpose of this number is to be used for the naming of the associated CAN interface. This is made possible by the Udev daemon and:

1/ adding a new appropriate rule in (for example) the file "70-persistent-net.rules":

$ cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="peak_usb", KERNEL=="can*", PROGRAM="/bin/peak_usb_device_namer %k", NAME="%c"

2/ adding the following shell script (for example) "/bin/peak_usb_device_namer":

$ cat /bin/peak_usb_device_namer
#!/bin/sh
#
# External Udev program to rename peak_usb CAN interfaces according to the flashed device numbers.
#
# (C) 2023 PEAK-System GmbH by Stephane Grosjean 
#
[ -z "$1" ] && exit 1
CAN_ID="/sys/class/net/$1/peak_usb/can_channel_id"
if [ -f $CAN_ID ]; then
        devid=`cat $CAN_ID`
        # PCAN-USB specific: use "000000FF" instead of "FFFFFFFF" below
        if [ "$devid" != "00000000" -a "$devid" != "FFFFFFFF" ]; then
                printf "can%d\n" 0x${devid}
                exit 0
        fi
fi
echo $1

By convention, the value of the device id when leaving the factory is either 00000000 or FFFFFFFF (000000FF specifically for PCAN-USB). In these specific cases, the above script considers that the CAN interface should not be renamed. Once these changes have been made, the peak_usb driver must be unloaded from memory (if it was previously loaded) and then reloaded:

$ sudo rmmod peak_usb
$ sudo modprobe peak_usb

Driver Package for Proprietary Purposes

Key Features

• Contains sources for chardev and for netdev drivers
• Monolithic driver in contrast to mainline SocketCAN environment with several drivers
• Must be compiled for the target system
• Can be build for real-time Linux extensions like Xenomai or RTAI (RTDM)
• Enables the use of PCAN-Basic Linux API calls (not possible via SocketCAN)
• Provides extra information like the bus load (depending on used CAN interface)
• Support of specific hardware features
• True hardware time stamps with handling of clock drifts
• Mainline kernel drivers are blacklisted when using the PCAN driver

When to Use the Package

• Your CAN application relies on PCAN-Basic for Linux API (based on chardev driver).
• The kernel you run is too old to include one of the peak_* mainline drivers you need.
• The kernel you run includes peak_* mainline drivers that are out-of-date or might contain issues.

---

Implementation Details Download Driver Package Documentation

Linux Real Time Drivers for PEAK CAN/CAN FD Interfaces

Since the CAN bus is a real-time network, it obviously may need a real-time system. PEAK-System offers several solutions to support its interfaces in different real-time environments based on the Linux kernel.

But first:

• "real-time" does not mean "faster". It means "lower and stable latency". Response times may even be a little longer than in a standard Linux kernel, but they will always be the same.
• Because its nature is to be a packet-oriented protocol, USB is not supported in real-time. The received frames are received in the USB interface which will decide by itself when to transmit them to the host.

As in the standard Linux environment, the choice of the solution depends on the desired application interface:
in standard Linux, if the choice is made according to the chardev or netdev interface, in the real-time world, it is made according to the RTDM or RT-socket-CAN interface. Whatever the chosen interface, the PEAK-System software offer will provide an adapted solution. The table below summarizes this offer:

Linux-RT

Linux-RT is the real-time version of the Linux kernel that brought real-time facilities to the standard kernel (see https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/). Applications don't care about it. Real-time is entirely handled by the patched kernel.

Xenomai

Xenomai is a living project that regularly proposes real-time extensions to the various longterm Linux kernels, for different hardware architectures like ARM, PPC, or x86 (see https://source.denx.de/Xenomai/xenomai/-/wikis/home).

Xenomai 3.1 Mercury is not supported here since it is a simple Xenomai interface (skin) to a Linux-RT patched kernel.

Xenomai 3.1 Cobalt co-kernel is the hard real-time version of Xenomai. Like RTAI, it implements the Real Time Driver Model interface the RT version of the PCAN-Linux driver supports when it is built with "make xeno". Xenomai 3.1 also includes the support of the real-time socket for the CAN bus (aka "RT-Socket-CAN"). With the driver "xeno_can_peak_pci", the RT-Socket-CAN core natively includes support of all the PCI/PCIe CAN 2.0 interfaces of PEAK-System.

The PCIe CAN FD interfaces family is natively supported by the driver "xeno_can_peak_pciefd" since Xenomai v3.2 in CAN 2.0 mode *ONLY* (at the time this note is written - 2021-11-15 - CAN FD is not yet supported by the RT-Socket-CAN core).

To take advantage of real-time under Xenomai, an application must be compiled and linked with the real-time libraries that offer access to the real-time facilities added by the Xenomai extension. That's the reason why the PCAN library (which encapsulates the calls to the kernel entry points) must be compiled in real-time mode too.

Finally, as shown in the table above, RT-Socket-CAN is not supported by the PCAN-Linux driver.

RTAI

RTAI is another Linux kernel extension coming with user libraries and RTDM API that also supports different hardware architectures like ARM, PPC, x86, and m68k (see https://www.rtai.org/).

Unlike Xenomai, RTAI doesn't propose any native support of real-time CAN sockets. Therefore, the RTDM version of the PCAN-Linux driver and its library (built with "make rtai") is the only way to take advantage of the benefits brought by real-time under RTAI when using the PC CAN interfaces of PEAK-System.