PCAN Driver Linux - UserManual
PCAN Driver Linux - UserManual
User Manual
Relevant Products
Product Name Version Part number
PCAN Driver for Linux 8.x.x not applicable
www.peak-system.com
[email protected]
2
PCAN Driver for Linux v8 - User Manual
Contents
1 Disclaimer 4
2 Introduction 5
2.1 Features 5
2.2 System Requirements 6
2.3 Scope of Supply 6
3 Installation 7
3.1 Build Binaries 7
3.2 Install Package 9
3.3 Configure Software 10
3.4 Configure Non-PnP-Hardware 13
5 Developer Guide 47
5.1 chardev Mode 47
5.1.1 CAN 2.0 API 49
5.1.2 CAN FD API 53
5.2 netdev Mode 67
3
PCAN Driver for Linux v8 - User Manual
1 Disclaimer
The provided files are part of the PCAN Driver for Linux package.
This is free software; you can redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either version 3 of the License, or (at your option)
any later version.
The software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with the software package. If
not, see https://www.gnu.org/licenses/.
Important note: It is strictly prohibited to use the intellectual property from the provided source code
for developing or producing a compatible hardware. All rights are reserved by PEAK-System Technik
GmbH.
4
PCAN Driver for Linux v8 - User Manual
2 Introduction
With the PCAN Driver for Linux, you can use CAN 2.0 and, since v8, CAN FD hardware products from
PEAK-System under Linux-based systems. Even if the use of Linux 2.4 kernels is declining, the canonical
age of the driver ensures compatibility with some versions of this kernel line and with older PEAK-
System hardware products.
The driver is also compatible with the latest versions of well-known real-time (RT) extensions like
Xenomai 1 and RTAI 2 , by interfacing to the common “Real Time Driver Mode” model.
Historically, the PCAN Driver for Linux provides an application programming interface called chardev by
implementing the character mode device drivers system calls (open, read, write, close, poll, ioctl). Since
version 20070306_n, the driver also provides a netdev interface which, by integrating the Kernel
SocketCAN network sub-layer, provides applications with access to the PEAK-System CAN channels via
the socket interface of the Linux kernel. The choice of the selected interface is exclusively done when
building the driver; the driver cannot run offering both interfaces at the same time.
Note: Since the Linux kernel v3.6, PEAK-System has worked to include the support of their most-
used PC CAN interfaces in the mainline Kernel. Thus, if you plan to get access to the CAN bus with a
PC CAN interface made by PEAK-System from a socket-based application, there is no need of
installing this PCAN Driver for Linux package anymore. The so-called netdev interface is however
kept for backward compatibility.
Version 8 of the PCAN Driver for Linux is a major evolution since it mainly includes the support of the
new CAN FD specification. Because of the new features CAN FD proposes, the historical chardev API has
had to evolve, too. Time has come for PCAN to propose a more modern and scalable new chardev
interface, while the “old” good one is obviously always supported.
The package is always evolving, because of the constant support of some new hardware products made
by PEAK-System, some new versions of tools and Kernels, or because of some bug fixing. The latest
version can be downloaded from the PEAK-System website:
https://www.peak-system.com/linux/
2.1 Features
Support of all CAN 2.0 a/b and CAN FD hardware products made by PEAK-System
Support of all 2.6.x, 3.x, and 4.x Linux Kernels in 32 and 64-bit environments
DESTDIR and cross-compilation supported
Udev system support
Enhanced sysfs integration
Optimized character mode device driver interface (chardev) supporting CAN 2.0 as well as CAN
FD standard and multiple messages transfers between applications and the driver
SocketCAN device driver interface (netdev) supporting CAN 2.0 as well as CAN FD new features,
with enhanced NETLINK integration (ip link support)
1
Website Xenomai: https://xenomai.org
2
Website RTAI: https://www.rtai.org
5
PCAN Driver for Linux v8 - User Manual
Real-time Linux extensions like Xenomai 3.x and RTAI 4.x and 5.x supported by the driver, as well
as by the user space library and the test and examples applications (chardev interface only)
Full binary compatibility with existing CAN 2.0 chardev applications that run over older versions
of the driver (7.x and older)
Note: The g++ compiler as well as the libpopt-dev package are only required for building some user
space applications from the test directory.
6
PCAN Driver for Linux v8 - User Manual
3 Installation
The PCAN Driver for Linux is an out-of-tree driver module, and because of the GPL, it is provided in a
(compressed) tarball package including the source files of the driver as well as the user libraries and
some test utilities and tools (see 2.3 Scope of Supply on page 6).
This chapter covers the setup of the whole driver package under non-RT and RT Linux systems (root
privileges are required for the installation part). Also, cross-compilation options are explained.
$ make clean
$ make
Note: This behavior is new from v8.x of the driver! In former versions, the global make command did
build enabling the netdev interface rather than the chardev one. The main reason of that change is
that a great number of PEAK-System CAN hardware products are now natively supported by the
mainline kernel as SocketCAN interfaces 3. Thus, driver users are supposed to prefer using the
chardev interface instead. But of course, the netdev interface can always be selected by rebuilding
the driver (only) with:
$ make netdev
$ make RT=XENOMAI
3
Kernel code: https://elixir.bootlin.com/linux/v3.4/source/drivers/net/can/usb/peak_usb/pcan_usb_core.c
7
PCAN Driver for Linux v8 - User Manual
Note: Since driver version 8.2, you can also build the Xenomai binaries with:
$ make xeno
$ make RT=RTAI
Note: Since driver version 8.2, you can also build the RTAI binaries with:
$ make rtai
Note: Selecting one of the above real-time compilations also removes the support of some of the
non-RT PC CAN interfaces (like the USB adapters, for example).
To cross-compile binaries:
$ make KERNEL_LOCATION=/where/are/the/kernel/headers
Making something from the package’s root directory recursively makes this thing into:
$ make -C driver
$ make -C lib
$ make -C test
$ make -C libpcanbasic
The default configuration of the PCAN Driver for Linux in non-RT configuration is to handle the support of
all PC CAN interfaces. However, in order to save memory or to fix some cross-compilation and/or loading
issues, it is possible to remove the support of some of these interfaces. The driver's Makefile handles the
following set of switches from the make command line:
8
PCAN Driver for Linux v8 - User Manual
For example, to build the driver including the support of the PCAN-Dongle and the PCAN-PC Card CAN
interfaces:
To know which variant of the driver (chardev, netdev or RT) has been built, type in the “driver” directory:
$ cd peak-linux-driver-X.Y.Z
$ su -c "make install"
The above setup will build and install the driver, the user libraries, and the test programs on the running
system.
9
PCAN Driver for Linux v8 - User Manual
Since v8.14, the driver can also be installed with DKMS support. DKMS is a software system that handles
the rebuild of the driver when a new Kernel has been installed in the running Linux based host. To take
advantage of DKMS, one have to install the driver with:
Calling the Makefile target "install_with_dkms" can be done from the root of peak-linux-driver-
x.y.z or from the subdirectory "driver". In the first case, the other components (libs and programs) will
be installed in the same way as if "make install" had been called.
10
PCAN Driver for Linux v8 - User Manual
11
PCAN Driver for Linux v8 - User Manual
See also “Table 6: clock reference used by the driver for the
timestamps” on page 21.
Note: The bitrate= parameter has changed since v8.x of the driver. In previous versions, this para-
meter allowed to change the default nominal bitrate, but with following the coding format of the
BTR0BTR1 SJA1000 register only.
In order to ensure the best backward compatibility with the existing configurations, the bitrate=
parameter is now parsed as follows:
If the two first characters of the given value are 0x or 0X and if the hexadecimal value is smaller
than 65536, then the value is always interpreted as a BTR0BTR1 bitrate specification (as the driver
did in previous versions).
Otherwise, and if the value is obviously a numeric value, then it is used as a bit-per-second (bit/s)
bitrate specification.
12
PCAN Driver for Linux v8 - User Manual
These parameters and their values can be given on the insmod command line or can be written in the
/etc/modprobe.d/pcan.conf file. The system administrator has to edit this file, then to uncomment
the options pcan line, and to write his own settings.
Note: This paragraph only concerns the users of some non-plug-and-play PC CAN interfaces (like the
PCAN-ISA and PC/104 PC CAN interfaces family). The configuration of the driver for the PCI/PCIe and
USB PC CAN interfaces families is entirely handled by the system.
When using some non-plug-and-play PC CAN interfaces, the driver has to be informed of the IRQs and
I/O ports configured for these boards (see the provided hardware reference and the corresponding jum-
pers' usage). The installation procedure of the PCAN Driver for Linux has already created a configuration
text file which enables to define some optional arguments that are passed to the driver (see 3.3 Configure
Software on page 10), when it is loaded.
For example, if the Linux host is equipped with a two channels ISA PC CAN interface board, and if IRQ 5
(resp. IRQ 10) and I/O port 0x300 (resp. 0x320) is the configuration selected by the dedicated jumpers on
the board, then the /etc/modprobe.d/pcan.conf file has to be changed like this:
$ sudo vi /etc/modprobe.d/pcan.conf
# PCAN - automatic made entry, begin --------
# if required add options and remove comment
options pcan type=isa,isa irq=10,5 io=0x300,0x320
install pcan /sbin/modprobe --ignore-install pcan
# PCAN - automatic made entry, end ----------
The standard assignments for ISA and PC/104 PC CAN interfaces are (io/irq): 0x300/10, 0x320/5. The
standard assignments for the PCAN-Dongle in SP/EPP mode are (io/irq): 0x378/7, 0x278/5.
13
PCAN Driver for Linux v8 - User Manual
Once installed, and if the Udev system is running on the target system, the driver is automatically loaded
by the system at the next boot for internal PC CAN interfaces, like the PCI/PCIe boards, or when the
external PC CAN interface (like the USB adapters) is plugged into the system.
Note: The modprobe system command manages to load all the other modules the driver depends
on. When using insmod instead, you must load all of these modules manually:
The driver is reasonably verbose for the kernel: it logs one or several messages in the kernel logs buffer
for each PC CAN interface it enumerates. Next, it will save messages only when something wrong has
been detected.
Here are the messages it logs when it just has been loaded, for example:
14
PCAN Driver for Linux v8 - User Manual
The driver enumerates each PC CAN interface according to its type. Up to version 8.5.1, each type had
the following range of device minor numbers:
The needs of CAN channels increasing, since v8.6.0, the driver enumerates the PC CAN interfaces
according to a different scheme:
This v8.6.0 new scheme gives more spaces to most used PC CAN interfaces, while always booking slot 32
for the first USB device channel.
Note: No device nodes files are created when running the real-time version of the driver module
because it creates real-time (only) devices which are not connected in any way to the Udev system.
The installation of the driver package also adds some default rules to Udev, for helping the system to
create the device nodes that implement the CAN channels handled by the driver (see peak-linux-
driver-x.y.z/driver/udev/45-pcan.rules). By default, Udev creates one (character) device node
under the /dev directory per CAN/CAN FD channel. The name of this device node is made of:
pcan prefix
PC CAN interface bus type (pci, isa, usb …),
fd suffix if the CAN channel is CAN-FD-capable
unique minor number
15
PCAN Driver for Linux v8 - User Manual
For example:
The Udev rules that the driver installs enable to create some symbolic links that give much more
information about the CAN channel:
2. Udev rules group CAN channels according to their PC CAN interface into the same subdirectory
whose name is made of the PC CAN interface product name
3. Udev default rules also create some other symbolic links if the CAN channel exports a devid
property (different from -1) under /sys (as USB devices are able to, as well as PCIe devices since
v8.10 of the driver).
The example below demonstrates the complete list of /dev/pcan* nodes, symbolic links, and
subdirectories the Udev rules provided with the driver might create.
$ ls -l /dev/pcan*
lrwxrwxrwx 1 root root 10 févr. 3 14:59 /dev/pcan0 -> pcanpcifd0
lrwxrwxrwx 1 root root 10 févr. 3 14:59 /dev/pcan1 -> pcanpcifd1
lrwxrwxrwx 1 root root 10 févr. 3 14:59 /dev/pcan2 -> pcanpcifd2
lrwxrwxrwx 1 root root 10 févr. 3 14:59 /dev/pcan3 -> pcanpcifd3
lrwxrwxrwx 1 root root 11 févr. 3 14:59 /dev/pcan32 -> pcanusbfd32
lrwxrwxrwx 1 root root 11 févr. 3 14:59 /dev/pcan33 -> pcanusbfd33
lrwxrwxrwx 1 root root 11 févr. 3 14:59 /dev/pcan34 -> pcanusbfd34
lrwxrwxrwx 1 root root 9 févr. 3 15:24 /dev/pcan35 -> pcanusb35
lrwxrwxrwx 1 root root 9 févr. 3 15:24 /dev/pcan36 -> pcanusb36
lrwxrwxrwx 1 root root 8 févr. 3 14:59 /dev/pcan4 -> pcanpci4
lrwxrwxrwx 1 root root 8 févr. 3 14:59 /dev/pcan5 -> pcanpci5
lrwxrwxrwx 1 root root 8 févr. 3 14:59 /dev/pcan8 -> pcanisa8
lrwxrwxrwx 1 root root 8 févr. 3 14:59 /dev/pcan9 -> pcanisa9
crw-rw-rw- 1 root root 246, 8 févr. 3 14:59 /dev/pcanisa8
crw-rw-rw- 1 root root 246, 9 févr. 3 14:59 /dev/pcanisa9
crw-rw-rw- 1 root root 246, 4 févr. 3 14:59 /dev/pcanpci4
crw-rw-rw- 1 root root 246, 5 févr. 3 14:59 /dev/pcanpci5
crw-rw-rw- 1 root root 246, 0 févr. 3 14:59 /dev/pcanpcifd0
crw-rw-rw- 1 root root 246, 1 févr. 3 14:59 /dev/pcanpcifd1
crw-rw-rw- 1 root root 246, 2 févr. 3 14:59 /dev/pcanpcifd2
crw-rw-rw- 1 root root 246, 3 févr. 3 14:59 /dev/pcanpcifd3
crw-rw-rw- 1 root root 246, 35 févr. 3 15:24 /dev/pcanusb35
crw-rw-rw- 1 root root 246, 36 févr. 3 15:24 /dev/pcanusb36
crw-rw-rw- 1 root root 246, 32 févr. 3 14:59 /dev/pcanusbfd32
crw-rw-rw- 1 root root 246, 33 févr. 3 14:59 /dev/pcanusbfd33
16
PCAN Driver for Linux v8 - User Manual
/dev/pcan-pci:
total 0
drwxr-xr-x 2 root root 80 févr. 3 14:59 0
lrwxrwxrwx 1 root root 11 févr. 13 12:05 'devid=1' -> ../pcanpci4
lrwxrwxrwx 1 root root 11 févr. 13 12:05 'devid=2' -> ../pcanpci5
/dev/pcan-pcie_fd:
total 0
drwxr-xr-x 2 root root 80 févr. 3 14:59 0
drwxr-xr-x 2 root root 80 févr. 3 14:59 1
lrwxrwxrwx 1 root root 13 févr. 13 12:05 'devid=10' -> ../pcanpcifd0
lrwxrwxrwx 1 root root 13 févr. 13 12:05 'devid=11' -> ../pcanpcifd1
lrwxrwxrwx 1 root root 13 févr. 13 12:05 'devid=12' -> ../pcanpcifd2
lrwxrwxrwx 1 root root 13 févr. 13 12:05 'devid=13' -> ../pcanpcifd3
/dev/pcan-usb:
total 0
drwxr-xr-x 2 root root 60 févr. 3 15:24 0
drwxr-xr-x 2 root root 60 févr. 3 15:24 1
lrwxrwxrwx 1 root root 12 févr. 3 15:24 devid=161 -> ../pcanusb35
/dev/pcan-usb_fd:
total 0
drwxr-xr-x 2 root root 60 févr. 3 14:59 0
lrwxrwxrwx 1 root root 14 févr. 3 14:59 devid=12345678 -> ../pcanusbfd34
/dev/pcan-usb_pro_fd:
total 0
drwxr-xr-x 2 root root 80 févr. 3 14:59 0
lrwxrwxrwx 1 root root 14 févr. 3 14:59 devid=2 -> ../pcanusbfd32
lrwxrwxrwx 1 root root 14 févr. 3 14:59 devid=31 -> ../pcanusbfd33
Here is the content of the subdirectories created by these Udev rules, one per PC CAN interface. The tree
representation provides a better way of showing which CAN channel is connected to which PC CAN
interface:
$ tree /dev/pcan-pci
1 directory, 4 files
1 directory, 4 files
17
PCAN Driver for Linux v8 - User Manual
$ tree /dev/pcan-pcie_fd
/dev/pcan-pcie_fd
├── 0
│ ├── can0 -> ../../pcanpcifd0
│ ├── can1 -> ../../pcanpcifd1
│ ├── can2 -> ../../pcanpcifd2
│ └── can3 -> ../../pcanpcifd3
├── 1
│ ├── can0 -> ../../pcanpcifd6
│ └── can1 -> ../../pcanpcifd7
├── devid=10 -> ../pcanpcifd0
├── devid=11 -> ../pcanpcifd1
├── devid=12 -> ../pcanpcifd2
└── devid=13 -> ../pcanpcifd3
2 directories, 10 files
$ tree /dev/pcan-usb
/dev/pcan-usb
├── 0
│ └── can0 -> ../../pcanusb35
├── 1
│ └── can0 -> ../../pcanusb36
└── devid=161 -> ../pcanusb35
2 directories, 3 files
$ tree /dev/pcan-usb_fd
/dev/pcan-usb_fd
├── 0
│ └── can0 -> ../../pcanusbfd34
└── devid=12345678 -> ../pcanusbfd34
1 directory, 2 files
$ tree /dev/pcan-usb_pro_fd
/dev/pcan-usb_pro_fd
├── 0
│ ├── can0 -> ../../pcanusbfd32
│ └── can1 -> ../../pcanusbfd33
├── devid=2 -> ../pcanusbfd32
└── devid=31 -> ../pcanusbfd33
1 directory, 4 files
In the above configuration, a user application that wants to access to the CAN bus through the 2nd CAN
port of the PCAN-USB Pro FD plugged to the host will be able to open indifferently:
/dev/pcanusbfd33
/dev/pcan33
/dev/pcan-usb_pro_fd/devid=31
/dev/pcan-usb_pro_fd/0/can1
18
PCAN Driver for Linux v8 - User Manual
Note: With a properly configured and running Udev system, all of these devices files and directories
are generated on the fly. If the target non-RT system does not have a running Udev system, you
must create the device files manually each time after driver installation. The driver package provides
the shell script driver/pcan_make_devices for this. For example, to create a maximum of 2
devices of each type:
$ cd driver
$ sudo ./pcan_make_devices 2
Example:
$ cat /proc/pcan
The columns of the PC CAN interfaces table are properties that are common to each interface:
19
PCAN Driver for Linux v8 - User Manual
For historical reasons, v8.x of the driver always handles the /proc/pcan file, but it should be considered
as deprecated and for CAN 2.0 usage only. Since v8.x, the driver also exports all the /proc/pcan
properties (and some more) to the /sysfs interface.
$ cat /sys/class/pcan/version
8.0.0
b) Since v8.11.0, the /sys/class/pcan/clk_ref attribute exports the clock reference used by the
driver:
$ cat /sys/class/pcan/clk_ref
0
20
PCAN Driver for Linux v8 - User Manual
c) The /sys/class/pcan directory exports the list of all the CAN interfaces it handles:
$ tree -a /sys/class/pcan
/sys/class/pcan
├── pcanisa8 -> ../../devices/virtual/pcan/pcanisa8
├── pcanisa9 -> ../../devices/virtual/pcan/pcanisa9
├── pcanpci4 -> ../../devices/virtual/pcan/pcanpci4
├── pcanpci5 -> ../../devices/virtual/pcan/pcanpci5
├── pcanpcifd0 -> ../../devices/virtual/pcan/pcanpcifd0
├── pcanpcifd1 -> ../../devices/virtual/pcan/pcanpcifd1
├── pcanpcifd2 -> ../../devices/virtual/pcan/pcanpcifd2
├── pcanpcifd3 -> ../../devices/virtual/pcan/pcanpcifd3
├── pcanusb35 -> ../../devices/virtual/pcan/pcanusb35
├── pcanusb36 -> ../../devices/virtual/pcan/pcanusb36
├── pcanusbfd32 -> ../../devices/virtual/pcan/pcanusbfd32
├── pcanusbfd33 -> ../../devices/virtual/pcan/pcanusbfd33
├── pcanusbfd34 -> ../../devices/virtual/pcan/pcanusbfd34
└── version
d) These entries have been extended to export some PCAN devices private properties, as shown
(bold) in the example below (bold-green lines properties are the same as the columns of
/proc/pcan):
$ ls -l /sys/class/pcan/pcanpci4/
total 0
-r--r--r-- 1 root root 4096 nov. 6 12:34 adapter_name
-r--r--r-- 1 root root 4096 nov. 6 12:34 adapter_number
-r--r--r-- 1 root root 4096 nov. 6 12:34 adapter_partnum
-r--r--r-- 1 root root 4096 nov. 6 12:34 adapter_version
-r--r--r-- 1 root root 4096 nov. 6 12:34 base
-r--r--r-- 1 root root 4096 nov. 6 12:34 btr0btr1
-r--r--r-- 1 root root 4096 nov. 6 12:34 bus_state
-r--r--r-- 1 root root 4096 nov. 6 12:34 clk_drift
-r--r--r-- 1 root root 4096 nov. 6 12:34 clock
-r--r--r-- 1 root root 4096 nov. 6 12:34 ctrlr_number
-r--r--r-- 1 root root 4096 nov. 6 12:34 dev
-rw-r--r-- 1 root root 4096 nov. 6 12:34 devid
-rw-r--r-- 1 root root 4096 nov. 6 12:34 dev_name
21
PCAN Driver for Linux v8 - User Manual
22
PCAN Driver for Linux v8 - User Manual
e) Reading the content of all the above files will display something like that:
Note: Depending on the CAN hardware and/or the mode the driver has been compiled, the device
node might export some more properties. For example, a CAN FD PCIe device will export the
following properties (specific properties are bold):
23
PCAN Driver for Linux v8 - User Manual
f) Some of the entries are exposed with Write permission. These entries can be written but with root
privileges only:
24
PCAN Driver for Linux v8 - User Manual
For example, attaching his own device number to a CAN channel is (also) possible through sysfs:
$ cat /sys/class/pcan/pcanusb32/devid
4294967295
$ echo 12 | sudo tee /sys/class/pcan/pcanusb32/devid
[sudo] password for user:
12
$ cat /sys/class/pcan/pcanusb32/devid
12
Note: Since v8.10, it is also possible to identify a CAN channel through sysfs: by writing a ms. delay
to the “led” property, then the channel LED will blink during this delay. For example, to switch the
LED of “/dev/pcanusb32” during 3 s:
The lspcan tool is a shell script based on the /sysfs interface that can be used to get an overview of the
PC CAN interfaces and CAN channels of the host.
$ ./lspcan --help
lspcan: list PEAK-System CAN/CANFD devices found by driver
Option:
-a | --all equivalent to: -i -s
-f | --forever forever loop on devices (^C to stop)
-h | --help display this help
-i | --info information about PCAN devices
-s | --stats statistics about PCAN devices
-t | --title display a title line over columns
-T | --tree tree version
--version display driver version
25
PCAN Driver for Linux v8 - User Manual
$ ./lspcan -T -t -i
dev name port irq clock btrs bus
[PCAN-ISA 0]
|_ pcanisa8 CAN1 10 8MHz 500k CLOSED
|_ pcanisa9 CAN2 5 8MHz 500k CLOSED
[PCAN-PCI 0]
|_ pcanpci4 CAN1 19 8MHz 500k CLOSED
|_ pcanpci5 CAN2 19 8MHz 500k CLOSED
[PCAN-PCIe FD 0]
|_ pcanpcifd0 CAN1 32 80MHz 500k+2M CLOSED
|_ pcanpcifd1 CAN2 32 80MHz 500k+2M CLOSED
[PCAN-PCIe FD 1]
|_ pcanpcifd2 CAN1 33 80MHz 500k+2M CLOSED
|_ pcanpcifd3 CAN2 33 80MHz 500k+2M CLOSED
[PCAN-USB 0]
|_ pcanusb32 CAN1 - 8MHz 500k CLOSED
[PCAN-USB 1]
|_ pcanusb33 CAN1 - 8MHz 500k CLOSED
[PCAN-USB Pro FD 0]
|_ pcanusbfd34 CAN1 - 80MHz 500k+2M CLOSED
|_ pcanusbfd35 CAN2 - 80MHz 500k+2M CLOSED
On the other hand, running lspcan with -T -t -s -f refreshes the screen every second with a detailed
view of statistics collected from all the PC CAN interfaces present on the Linux host:
Note: The content of the above screen copy may change, depending on the version of the driver.
26
PCAN Driver for Linux v8 - User Manual
$ sudo ./pcanosdiag.sh
[sudo] password for xxx:
./pcanosdiag.sh v1.0.5
Done.
Please send /tmp/pcanosdiag-1.0.5-YYYMMDD_HHMNSS.log to <support@peak-
system.com>
The output log file can be useful to assist in the diagnosis in certain situations.
This (very) simple interface makes it possible to quickly check if the driver correctly works. This interface
uses a syntax made of:
1. a letter that indicates the command
27
PCAN Driver for Linux v8 - User Manual
Example:
$ echo "i nom_bitrate=1M" > /dev/pcanusb0
Example:
$ echo "m s 0x123 3 01 02 03" > /dev/pcanusb0
The above command writes CAN message ID 0x123 with 3 the data bytes
“01 02 03” on the CAN bus connected to the 1st CAN port of the USB CAN
interface.
e id len [xx [xx …]] Write CAN extended message id (numeric value <= 0x3fffffff) with len
data bytes valued by xx [xx ].
Example:
$ echo "m e 0x123 3 01 02 03" > /dev/pcanusb0
The above command writes CAN message ID 0x00000123 with 3 the data
bytes “01 02 03” on the CAN bus connected to the 1st CAN port of the USB
CAN interface.
r s id Write the CAN RTR (Remote Transmission Request) of standard id
(numeric value <= 0x7ff).
e id Write the CAN RTR (Remote Transmission Request) of extended id
(numeric value <= 0x7ff).
M Same as m but asking the driver to activate the self-receive feature (if the CAN controller of the given channel can
copy an outgoing CAN frame to its own rx queue).
R Same as r but asking the driver to activate the self-receive feature (if the CAN controller of the given channel can
copy an outgoing CAN frame to its own rx queue).
b Same as m but asking the driver to activate the BRS feature (if the given channel is equipped with a CAN FD
controller).
B Same as b but asking the driver to activate the self-receive feature (if the CAN FD controller of the given channel
can copy an outgoing CAN FD frame to its own rx queue).
28
PCAN Driver for Linux v8 - User Manual
If reading from this interface, the user is able to receive any of the above messages, plus status (x)
messages:
The test directory applications should be built after the libraries under lib directory have been built and
installed. Like the driver, these libraries and applications accept non-RT and RT compilation.
The global package installation described in 3.1 Build Binaries on page 7 has built and installed those
binaries in the system. To (re-)build them (without using any RT system calls):
$ cd peak-linux-driver-x.y.z
$ make -C test
32-bit version:
Since driver version 8.3, a 64-bit version of the pcan driver can operate with any 32-bit application. To
build the 32-bit version of the applications stored in this test directory, you need to do:
$ cd peak-linux-driver-x.y.z
$ make -C test all32
Note: A 32-bit version of libpcan must have been built and installed first (see Making the 32-bit
version of the library on page 8). Moreover, in order to build any 32-bit application while running a
64-bit Kernel, you first need to install the gcc-multilib package. Finally, the specific libpopt 32-
bit package must be installed to:
29
PCAN Driver for Linux v8 - User Manual
Real-time versions:
A user who wants to rebuild the RT version of these binaries will have to:
$ cd peak-linux-driver-x.y.z
$ make -C test RT=XENOMAI # Or "make xeno" since pcan 8.2
$ cd peak-linux-driver-x.y.z
$ make -C test RT=RTAI # Or "make rtai" since pcan 8.2
Note: Users (as well as developers) of CAN-FD-specific applications can directly have a look at the
new pcanfdtst application described in 4.8.5 on page 34.
4.8.1 receivetest
This application writes all frames it receives from a given CAN 2.0 channel (only!) to stdout. This
application also demonstrates the usage of the old lipcan CAN 2.0 API in both RT and non-RT
environments.
Usage:
$ receivetest --help
receivetest - a small test program which receives and prints CAN messages.
usage: receivetest [-b=BTR0BTR1] [-e] [-?]
{[-f=devicenode] | {[-t=type] [-p=port [-i=irq]]}}
options:
-f=devicenode path to PCAN device node (default=/dev/pcan0)
-t=type type of interface (pci, sp, epp, isa, pccard, usb (default=pci)
-p=port port number if applicable (default=1st port of type)
-i=irq irq number if applicable (default=irq of 1st port)
-b=BTR0BTR1 bitrate code in hex (default=see /proc/pcan)
-e accept extended frames (default=standard frames only)
-d=no donot display received messages (default=yes)
-n=mloop number of loops to run before exit (default=infinite)
-? or --help displays this help
30
PCAN Driver for Linux v8 - User Manual
Example:
Display up to 100 (extended and standard) messages received from the 1st CAN port of a USB interface
connected to a CAN bus at 1 Mbit/s:
Note: The bitrate set by this program to this CAN interface is exported by the driver:
Note: The RT device doesn't appear under "/dev" while running an RT Linux like Xenomai or RTAI, so
RT version of CAN_Open(libpcan) removes the "/dev" prefix from the device name characters string,
while pcanfd_open(lipcanfd) DOES NOT. This workaround ONLY works with "/dev/pcanX" device
names.
4.8.2 transmitest
This application writes all the frames it finds in the given text file to the given CAN 2.0 channel (only!).
This application also demonstrates the use of the old libpcan CAN 2.0 API in both RT and non-RT
environments.
Usage:
$ transmitest --help
31
PCAN Driver for Linux v8 - User Manual
The file transmit.txt is given as an example in the test directory. The syntax of this file is quite
simple and follows the syntax of the write interface of the driver. The test loops the transmission of the
frames found in the input text file. The number of loops is infinite unless the -n option is specified on
command line.
Example:
Transmit 100 times all the CAN 2.0 frames described in transmit.txt to the 1st CAN port of a USB
interface connected to a CAN bus at 1 Mbit/s:
Note: The bitrate set by this program to this CAN interface is exported by the driver:
Note: The RT device doesn't appear under "/dev" while running an RT Linux like Xenomai or RTAI, so
RT version of CAN_Open(libpcan) removes the "/dev" prefix from the device name characters string,
while pcanfd_open(lipcanfd) DOES NOT. This workaround ONLY works with "/dev/pcanX" device
names.
4.8.3 pcan-settings
This application enables to read/write some specific values from/to the non-volatile memory of some PC
CAN interfaces. This feature is useful to the user who wants his hot-pluggable CAN interfaces to always
have the same device node name, whatever socket it is plugged on (operating systems devices
enumeration rules don't give the same number to the same device, if this device is not plugged to the
same socket/bus/port…).
Since driver version 8.8, pcan-settings allows any super user to switch specific PC CAN interfaces to
“USB Mass Storage Device” mode. This mode is used to easily upgrade these PC CAN interfaces with a
new firmware (see also 4.10 USB Mass Storage Device Mode on page 44).
Usage:
$ pcan-settings --help
Usage: pcan-settings [OPTION...]
-f, --deviceNode='device file path' Set path to PCAN device (default:
"/dev/pcan32")
-s, --SerialNo Get serial number
-d, --DeviceNo[='device number'] Get or set device number
-v, --verbose Make it verbose
-q, --quiet No display at all
-M, --MSD Switch device in Mass Storage Device
mode (root privileges needed)
Help options:
-?, --help Show this help message
--usage Display brief usage message
32
PCAN Driver for Linux v8 - User Manual
Example:
$ pcan-settings -f=/dev/pcanusb32 -s
0x00000003
• Set device numbers 30 and 31 for CAN1 and CAN2 of a USB 2xCAN channels interface:
$ pcan-settings -f=/dev/pcanusb32 -d 30
$ pcan-settings -f=/dev/pcanusb33 -d 31
• Read the device numbers of CAN1 and CAN2 of a USB 2xCAN channels interface:
$ pcan-settings -f=/dev/pcanusb32 -d
30
$ pcan-settings -f=/dev/pcanusb33 -d
31
When the driver is reloaded, it reads these numbers and exports them to /sys:
$ cat /sys/class/pcan/pcanusb32/devid
30
$ cat /sys/class/pcan/pcanusb33/devid
31
Thus, Udev is notified and reads the driver’s rules. These default rules say that, if devid is not -1, then it
should be used to create a symbolic link to the true device node under a directory which name is the
adapter name. In this example, if the USB CAN interface is a PCAN-USB Pro, then two symbolic links are
created under /dev/pcan-usb_pro:
$ ls -l /dev/pcan-usb_pro
total 0
drwxr-xr-x 2 root root 11 nov. 8 11:00 0
lrwxrwxrwx 1 root root 11 nov. 8 11:00 devid=30 -> ../pcanusb32
lrwxrwxrwx 1 root root 11 nov. 8 11:00 devid=31 -> ../pcanusb33
Note: device numbers can also be defined using the sysfs interface (see /sysfs Interface on page 24).
Note: since v8.10, a device number can also be set to each CAN channel of the PCAN PCI Express /
PCAN-PCIe FD cards.
4.8.4 bitratetest
Note: This application is kept for historical reasons only but, since bitrate values and clock selection
are now proposed by the new API to the user space, it is considered as deprecated.
This application displays the BTR0BTR1 values for some well-known bitrate values. The BTR0BTR1
16-bits codification is 8 MHz SJA1000-controller-specific.
33
PCAN Driver for Linux v8 - User Manual
Usage:
$ bitratetest --help
4.8.5 pcanfdtst
This application enables to test the driver, since it can receive/transmit CAN 2.0/CAN FD messages
from/to all of the device nodes handled by the driver. It works in several modes:
when running in RX mode, the application writes everything received from all the opened device
nodes on the screen. It is also able to check the content of the incoming frames
when running in TX mode, the application transmits CAN 2.0/CAN FD frames on all the opened
devices and also displays any event received from them
when running in record mode, the application records the CAN 2.0/CAN FD frames in a local file
instead of transmitting them. Recording frames allows to play the same scenario several times
(see -play option below)
Moreover, this application demonstrates the usage of the new CAN FD API of the driver in both RT and
non-RT Linux. Among all the novelties, the application allows to:
specify nominal and data bitrates for CAN FD usage
select the device clock
select ISO and non-ISO CAN FD modes
demonstrate the usage of the new entry points of the new API that enable to transmit and receive
several messages at once
demonstrate the new event-based API
Usage:
$ pcanfdtst --help
Setup CAN[FD] tests between CAN channels over the pcan driver (>= v8.x)
WARNING
This application comes with ABSOLUTELY NO WARRANTY. This is free
software and you are welcome to redistribute it under certain
conditions. For details, see attached COPYING file.
USAGE
34
PCAN Driver for Linux v8 - User Manual
MODE
tx generate CAN traffic on the specified CAN interfaces
rx check CAN traffic received on the specified CAN interfaces
getopt get a specific option value from the given CAN interface(s)
setopt set an option value to the given CAN interface(s)
rec same as 'tx' but frames are recorded into the given file
FILE
For all modes except 'rec' mode:
OPTIONS
35
PCAN Driver for Linux v8 - User Manual
opt-name, opt-value and opt-size parameters are only used when in getopt or setopt mode
only. These options enable to get or set devices global or specific options value (see also int
pcanfd_get_option())
36
PCAN Driver for Linux v8 - User Manual
Bitrates and clock values can be expressed with ending k or M as shortcuts for factor 1,000 or
factor 1,000,000. Note that if the option --btr0btr1 is used, then bitrate and dbitrate
options value is read as a BTR0BTR1 format coded value.
The unit of the pause delay between each write or read system call is the microsecond. Here,
using an m appended to a value (e.g. 5m) changes to milliseconds and an appended s to full
seconds (e.g. 7s).
The unit of the timeout-ms parameter is millisecond. Appending an s to the value switches to
seconds (e.g. 7s).
If only one PC CAN interface is given on the command line, the application runs in “blocking”
mode, that is, the application task blocks into the driver while the receive queue of the driver is
empty, or while the transmission queue of the driver is full.
If more than one PC CAN interface is given on the command line, the application does the
following:
• It runs in non-blocking mode and uses the select() system call in non-RT environment,
to be able to wait for several events at once.
• It creates as many real-time tasks as given device nodes, to be able to wait for several
events at the same time.
The application’s default behavior is to read/write messages from/to the driver one by one. When
the --mul x option is used (with x > 1), then the application reads/writes x messages at once.
The + option is a character’s string that runs like the Linux Shell command “date”: it enables to
specify his own format of the output lines.
--ts-base option allows user to set the base of the timestamps of the frames the driver
received:
--ts-base Description
1 Timestamps are based on the time when the device has been opened.
2 Timestamps are based on the time the driver has been loaded.
Some options (like id, len, incr, filler…) can be used either in tx (or rec) mode or in rx
mode:
• When used in tx mode, they control how the transmitted CAN frames are generated
• When used in rx mode, they control how the received CAN frames must be.
Examples:
1. Write 10 CAN 2.0 frames (with random ID and data length) each second on a bus with a bitrate of
250 kbit/s using the 2nd USB CAN interface:
37
PCAN Driver for Linux v8 - User Manual
2. Write CAN FD (non-ISO) frames with extended ID 0x123 and 24 data bytes at a nominal bitrate of
1 Mbit/s and data bitrate of 2 Mbit/s, using the 60 MHz clock of the 2nd USB interface and the
1st PCI interface of the host:
3. Same as above but record (instead of writing) the frames into a file named “test.rec”:
4. Play file “test.rec” writing its frames every 1 s through the 1st channel of a PCAN-PCIe FD on a
1Mbps CAN bus:
38
PCAN Driver for Linux v8 - User Manual
5. Read the same bus, but from the 1st USB interface:
6. Transmit frames but use the new entry point of the multi-messages write API. Here, the
application transmits 3 copies of the same frame:
When reading on the same bus, you can see that the driver has written each frame 3 times:
Note: The RT device doesn't appear under "/dev" while running an RT Linux like Xenomai or RTAI, so
the RT version of pcanfdtst MUST use the real name of the CAN device, that is "pcanX". There are
neither aliases nor links that Udev can make when a RT device is created.
7. Changing the device id. of a PCAN-USB FD device using the getopt/setop modes:
39
PCAN Driver for Linux v8 - User Manual
Note: Since kernel version 3.6, the netdev interface with all of the PEAK-System PC CAN interfaces is
natively included in the mainline kernel. So, there is no need to install the PCAN driver for Linux
when planning to use the SocketCAN interface in applications.
In this mode, the driver registers a “CAN network interface” for each PC CAN interface it enumerates.
Each network interface is given a name made of the prefix can, followed by a number starting from 0.
assign=peak
When loading the driver with the parameter assign=peak, the CAN network CAN interface number is
fixed to the PCAN device minor number. In this mode, canX interface defines the same PC CAN interface
as /dev/pcanX.
assign=pcanX:canY[,pcanX:canY]
Loading the driver with the parameter assign=pcanX:canY sets the name canY to the device which
name is pcanX. When selecting this mode, the assign parameter value can be a list of several
assignments, each separated by a “,” (comma).
assign=devid[,peak]
When loading the driver with the parameter assign=devid, then the name of the network CAN interface
is made by using the devid value of the corresponding PC CAN interface. If the PC CAN interface does
not define any devid, then the usual (ascending) order enumeration scheme is used (as if assign= was
not used) unless assign=devid,peak is used. In that case, the CAN network number will be the same as
the PCAN device number (as if assign=peak was used).
4
Background information: https://en.wikipedia.org/wiki/SocketCAN
40
PCAN Driver for Linux v8 - User Manual
Note: The value of the devid property can be changed using test/pcan-settings utility (see 4.8.3
pcan-settings on page 32).
defclk=value
When loading the driver with the parameter defclk=value, all the PC-CAN interfaces will try to switch
from their default clock value to the given one. value is expressed in Hz. Ending letter “M” or “k” can be
used as a shortcut to “x1000000” or “x1000”. For example:
defclk=12M
selects the 12 MHz clock of each PC CAN interface that can run with such a clock. If a PC-CAN interface
can’t select the given clock value, then it silently ignores it. If value is 0, the default clock is unchanged.
defclk=pcanX:valueA[,pcanY:valueB]
Loading the driver with the parameter defclk=pcanX:valueA[,pcanY=valueB] defines a specific clock
value to each PC CAN interface which name is given in the characters string. For example:
defclk=pcan0:12M,pcan1:60M,pcan2:0,pcan3:24M
tells the first four PC CAN interfaces to respectively switch to their 12 MHz, 60 MHz, default and 24 MHz
clock. If any of these interfaces can’t select the given clock, then it silently ignores it.
4.9.3 ifconfig/iproute2
Both utilities configure a canX interface. While ifconfig is somewhere too old to support all of the
CAN/CAN-FD-specific features, the last versions of the iproute2 package (especially the ip tool)
includes options to setup a canX interface. Since v8, the canX interfaces exported by the pcan driver can
be configured using the ip link command.
The ip tool has been modified to handle protocol-specific features of CAN and CAN FD. This simplifies
the bitrate setup of a CAN interface. The help of the tool describes its usage:
41
PCAN Driver for Linux v8 - User Manual
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
Thus, setting the bitrate to a CAN interface is now possible using one of the following options:
bitrate bit-timing parameters set (aka sample-point, tq, prop-seg, phase-seg1, phase-seg2,
sjw)
bitrate option followed by numeric value (if the kernel configuration option
CONFIG_CAN_CALC_BITTIMING was set)
The restart-ms option defines a timer in milliseconds. After this period the CAN interface is
automatically restarted on BUS-OFF condition. If the given numeric value is 0, then the automatic restart
mechanism is disabled, thus user will have to manually do:
The last and complete version of how to use the ip link tool with CAN networks is available online at:
https://www.kernel.org/doc/Documentation/networking/can.txt
Examples:
Set up a PCAN netdev CAN FD interface with 1 Mbit/s te and 2 Mbit/s of data bitrate (if supported):
Set up a PCAN netdev CAN FD interface with 1 Mbit/s nominal bitrate and 2 Mbit/s data bitrate,
running in non-ISO mode (if supported by the device and the kernel):
$ ip link set canX up type can bitrate 1000000 dbitrate 2000000 fd-non-iso on
42
PCAN Driver for Linux v8 - User Manual
You might use ifconfig for setting the interface UP or DOWN only:
Note: loopback mode is supported since v8.10 of the driver. The below example shows how to
configure can0 to receive the echo of each frame sent as well as the frame looped back by the
controller:
$ candump -x can0
$ candump -x can0
Can0 TX - - 123 [8] 00 11 22 33 44 55 66 77
Can0 RX - - 123 [8] 00 11 22 33 44 55 66 77
4.9.4 can-utils
The can-utils package 5 contains some tools and utilities that allow transmitting and receiving CAN as
well as CAN FD messages over the PCAN netdev interfaces.
Note: Transmitting and receiving to/from the CAN bus through the SocketCAN network interfaces
needs these interfaces to be configured (see 4.9.3 ifconfig/iproute2 on page 41).
Examples:
Dump CAN/CAN FD messages received from the canX interface, display timestamps:
$ candump -t a canX
5
Website can-utils: https://github.com/linux-can/can-utils/
43
PCAN Driver for Linux v8 - User Manual
Transmit a CAN message with ID 0x123 on canX with 4 data bytes 00 11 22 33:
Transmit the same message with CAN FD (##) on canX, select the data bitrate for the data bytes
(BRS flags = 1):
A PC CAN interface can be switched into MSD mode if its device nodes export the mass_storage_mode
file under the /sysfs tree. In the example below, the PCAN-USB adapter cannot switch into MSD mode,
while the PCAN-USB FD is able to:
$ cat /sys/class/pcan/pcanusb33/mass_storage_mode
cat: /sys/class/pcan/pcanusb33/mass_storage_mode: No such file or directory
$ cat /sys/class/pcan/pcanusbfd38/mass_storage_mode
0
Note: Reading the mass_storage_mode file (if it exists) always returns the character string “0”.
Switching to MSD mode is only useful if the PC CAN interface firmware should be upgraded. In that case,
super user should first get a compatible firmware from the support pages of the PEAK-System website.
1. With root privileges, writing 1 to the mass_storage_mode file of (for example) the directory entry
that corresponds to the first device node of the PC CAN interface:
44
PCAN Driver for Linux v8 - User Manual
Hint: the “verbose” mode gives more details that may help for the next steps:
For example:
# mkdir -p /mnt/pcan-usb
# mount -t vfat /dev/sdX /mnt/pcan-usb
# ls -al /mnt/pcan-usb
After a few seconds, the LED(s) of the PC CAN interface should blink, and the Kernel should detect a new
USB mass storage device:
In the example above, the Kernel attached the storage device sde to the newly detected USB mass
storage device with idVendor 0c72 (that is PEAK-System). If the running Linux system doesn’t
automatically mount any file system onto that storage device, then super user has to do it manually:
$ ls -al /mnt/pcan-usb-fd
total 830
drwxr-xr-x 2 root root 512 janv. 1 1970 .
drwxr-xr-x 10 root root 4096 déc. 13 11:23 ..
-rwxr-xr-x 1 root root 844800 avril 1 2015 firmware.bin
45
PCAN Driver for Linux v8 - User Manual
$ sudo rm -f /mnt/pcan-usb-fd/*.bin
Note: The remove operation is purely virtual but is mandatory to let the system think that the
storage device is large enough to store the new firmware file. At that point, if the PC CAN interface is
unplugged, then it will normally restart as usual once plugged in again.
After a few seconds, the PC CAN interface must be power cycled to run the new firmware. Either unplug
it or switch it off, in case the PC CAN interface is powered by another source than the USB cable (like the
PCAN-USB X6, for example).
Note: The PCAN-USB X6 adapter is equipped with 3 modules, each managing 2 CAN ports. Also, it is
necessary to perform the previous manipulation 3 times in total, using each time the first device
node of each module (CAN1, CAN3, and CAN5).
For example, if the connected PCAN-USB X6 adapter is exported by the system like that:
$ lspcan -t -T -i
dev name port irq clock btrs bus
[PCAN-USB X6 0]
|_ pcanusbfd38 CAN1 - 80MHz 500k+2M CLOSED
|_ pcanusbfd39 CAN2 - 80MHz 500k+2M CLOSED
|_ pcanusbfd40 CAN3 - 80MHz 500k+2M CLOSED
|_ pcanusbfd41 CAN4 - 80MHz 500k+2M CLOSED
|_ pcanusbfd42 CAN5 - 80MHz 500k+2M CLOSED
|_ pcanusbfd43 CAN6 - 80MHz 500k+2M CLOSED
Then pcanusbfd38, pcanusbfd40, and pcanusbfd42 should all be switched to MSD mode.
Once restarted, the PC CAN interface runs the new firmware. The version of the firmware that is
embedded into a PC CAN interface (if any) can be read in the /sysfs tree. For example:
$ cat /sys/class/pcan/pcanusbfd38/adapter_version
3.2.0
46
PCAN Driver for Linux v8 - User Manual
5 Developer Guide
As explained in 3.1 Build Binaries on page 7, the PCAN Driver for Linux can be configured to run in two
exclusive modes:
1. If built for chardev mode, the driver exports a classic open/read/write/ioctl/close character device
interface to the user space applications, while
Note: The netdev mode is not available when building the driver for real-time environment.
Building and installing the driver as described in 3.1 Build Binaries on page 7 and in 0 To know which
variant of the driver (chardev, netdev or RT) has been built, type in the “driver” directory:
Install Package on page 9 also builds and installs some user API libraries that encapsulate the system
calls to the driver:
• libpcan is the good and old API which is always offering access to CAN 2.0 channels (see 5.1.1
CAN 2.0 API on page 49)
• libpcanfd is the new API included in the package since version 8 of the driver. This new API
offers access to CAN 2.0 and CAN FD channels, as well as multi-messages services and status
events messaging. Since this library also includes all the entry points of libpcan described in
5.1.1 CAN 2.0 API on page 49, this library can also be linked with CAN 2.0 API applications instead
of using libpcan.
Both libraries can be built for being used by real-time applications. Two RT environments can be selected
when building these libraries, knowing that both make usage of RTDM:
Each device node can be opened, closed, read, and written (see 4.6 pcanosdiag.sh Tool
47
PCAN Driver for Linux v8 - User Manual
Starting from v8.14, the pcan driver package includes and installs another tool named pcanosdiag.sh.
When launched with root rights, this Shell script produces a log file that takes a snapshot of the running
Linux host.
$ sudo ./pcanosdiag.sh
[sudo] password for xxx:
./pcanosdiag.sh v1.0.5
Done.
Please send /tmp/pcanosdiag-1.0.5-YYYMMDD_HHMNSS.log to <support@peak-
system.com>
The output log file can be useful to assist in the diagnosis in certain situations.
read/write Interface on page 27). The main functions are implemented through the ioctl() entry point.
The architecture of the several software components of the driver package since v8 is summarized in
Figure 1 below.
The chardev mode is especially needed when one wants to take benefits of the PCAN-Basic API PEAK-
System has developed, for writing applications that can run on both Windows and Linux systems.
48
PCAN Driver for Linux v8 - User Manual
main() main()
{ {
h = CAN_Open(); fd = pcanfd_open();
CAN_Init(h); err = pcanfd_set_init(fd);
CAN_Write(h); err = pcanfd_send_msg(fd);
CAN_Read(h); err = pcanfd_recv_msg(fd);
} pcanfd_close(fd);
libpcan.h #include <PCAN.h> }
#include <libpcan.h> libpcanfd.h
DWORD CAN_Init(); int pcanfd_set_init()
DWORD CAN_Init();
pcanfd.h
#include <PCAN.h>
PCAN.h
#define PCAN_INIT
#define PCANFD_SET_INIT
libpcanfd.so
#include <libpcan.h> #include <libpcanfd.h>
libpcan.so
DWORD CAN_Init() int pcanfd_set_init()
{ {
ioctl(PCAN_INIT);
}
}
PCAN.ko
#include <pcanfd.h>
ioctl() {
case PCAN_INIT:
case PCANFD_SET_INIT:
Note: This API is kept for backward compatibility reasons, thus these entry points are also proposed
by the new libpcanfd library. But, this API is considered as deprecated. Use the new CAN FD API
instead.
The (old) CAN 2.0 API ioctl codes are defined by pcan.h:
49
PCAN Driver for Linux v8 - User Manual
This API enables to read and write CAN 2.0 messages (only) from/through any PC CAN interface of PEAK-
System. This API is encapsulated by the libpcan library (C/C++ programs like transmitest,
receivetest, bitratetest, and pcan-settings stored in the test directory use this API). Since this
API is always supported for CAN 2.0 access, to use this API, the application must link with -lpcan or
-lpcanfd.
The principle of this API is to implement a CAN 2.0 channel with something like an object HANDLE used
during the whole life of the connection to the CAN bus. This API is greatly inspired of the PCAN-Light
version for Windows©.
For example:
#include <libpcan.h>
/* open the 2nd CAN 2.0 PCI channel in the system (first is 0) */
HANDLE h = CAN_Open(HW_PCI, 1);
See the list of CAN_BAUD_xxx and CAN_INIT_TYPE_XX symbols defined in libpcan.h to get the list of
supported values for wBTR0BTR1 values and nCANMsgType.
For example:
#include <libpcan.h>
…
/* initialize the CAN 2.0 channel with 500 kbps BTR0BTR1, accepting extended ID. */
status = CAN_Init(h, CAN_BAUD_500K, CAN_INIT_TYPE_EX);
50
PCAN Driver for Linux v8 - User Manual
For example:
#include <libpcan.h>
…
msg.ID = 0x123
msg.MSGTYPE = MSGTYPE_STANDARD;
msg.LEN = 3;
msg.DATA[0] = 0x01;
msg.DATA[1] = 0x02;
msg.DATA[2] = 0x03;
/* write standard msg ID = 0x123. with 3 data bytes 0x01 0x02 0x03
* (the function may block)
*/
status = CAN_Write(h, &msg);
For example:
#include <libpcan.h>
…
/* wait for a CAN 2.0 msg received from the CAN channel
* (the function may block)
*/
status = CAN_Read(h, &msg);
Note: Reading the status of a channel with this function clears it!
51
PCAN Driver for Linux v8 - User Manual
For example:
#include <libpcan.h>
…
/* get the status of a CAN 2.0 channel */
status = CAN_Status(h);
For example:
#include <libpcan.h>
…
/* wait for a CAN 2.0 msg received from the CAN channel
* (the function may block)
*/
CAN_Close(h);
To get profit from the multi-tasking environment of Linux, the library has been extended with the
following LINUX_XXX() functions:
52
PCAN Driver for Linux v8 - User Manual
53
PCAN Driver for Linux v8 - User Manual
These new ioctl codes are also encapsulated by some new entry points of the new libpcanfd library.
These new entry points are defined in libpcanfd.h.
Note: The test application pcanfdtst uses these new entry points.
This new library does not anymore encapsulate CAN channels into any HANDLE objects, but directly
deals with file descriptors returned by the open() system call, made on the corresponding device node.
Note: The old and new APIs are not compatible! Once a CAN channel is opened through one API, it
cannot be used with the other one. In other words, opening a CAN channel selects the API that is
used for the connection.
The new API offers several levels of usage. While Level 1 encapsulates the above ioctl codes, Level 2 API
offers a more friendly way of opening and closing a device node.
Finally, all of the entry points of this new API return an integer value. If it is negative, it must be
interpreted as an error code that equals to -errno.
struct pcanfd_init {
__u32 flags;
__u32 clock_Hz;
struct pcan_bittiming nominal;
struct pcan_bittiming data;
};
54
PCAN Driver for Linux v8 - User Manual
struct pcanfd_state {
__u16 ver_major, ver_minor, ver_subminor;
55
PCAN Driver for Linux v8 - User Manual
to discard. The message filter is described by the new struct pcanfd_msg_filter object (see also
pcanfd.h):
struct pcanfd_msg_filter {
__u32 id_from; /* msgs ID in range [id_from..id_to] */
__u32 id_to; /* and flags == msg_flags */
__u32 msg_flags; /* will be passed to applications */
};
struct pcanfd_msg_filters {
__u32 count
struct pcanfd_msg_filter list[0];
};
Note: The count field should contain the number of message filters saved in the list[] array field.
struct pcanfd_msg {
__u16 type; /* PCANFD_TYPE_xxx */
__u16 data_len; /* true length (not the DLC) */
__u32 id;
__u32 flags; /* PCANFD_xxx definitions */
struct timeval timestamp;
__u8 ctrlr_data[PCANFD_CTRLR_MAXDATALEN];
__u8 data[PCANFD_MAXDATALEN] __attribute__((aligned(8)));
};
This C structure object is able to carry a CAN 2.0 as well as a CAN FD message. It also can contain some
out-of-band message types (like status messages) that can be pushed by the driver to the application.
Note: Writing a message to the CAN bus might block the calling task, unless the device node has
been opened in non-blocking mode. In that case, -EWOULDBLOCK is returned by this function if the
task had not enough room to store the outgoing message.
56
PCAN Driver for Linux v8 - User Manual
struct pcanfd_msgs {
__u32 count;
struct pcanfd_msg list[0];
};
This C structure object is able to carry several CAN 2.0 and CAN FD messages. The number of messages
to write is given by the count field. This field is also used to indicate how many messages have really
been written in the transmit queue of the device.
Note: Writing several messages to the CAN bus might block the calling task, unless the device node
has been opened in non-blocking mode. In that case, -EWOULDBLOCK is returned by this function if
the task had not enough room to store the outgoing messages.
If at least one message has been successfully written in the transmit queue, then the function returns 0.
Otherwise, it returns a negative error code.
Using this function saves memory copies and constant round trips between kernel and user spaces.
57
PCAN Driver for Linux v8 - User Manual
Example:
#include <malloc.h>
#include <libpcanfd.h>
/* put all of the messages at once in the transmit queue of the device… */
err = pcanfd_send_msgs(fd, pml);
if (err)
printf("Only %u/5 msgs have been sent because of errno=%d\n",
pml->count, err)
free(pml);
…
Note: Reading a message from the driver might block the calling task, unless the device node has
been opened in non-blocking mode. In that case, -EWOULDBLOCK is returned by this function if the
task didn't find any message to read.
58
PCAN Driver for Linux v8 - User Manual
struct pcanfd_msgs {
__u32 count;
struct pcanfd_msg list[0];
};
This C structure object is able to carry several CAN 2.0 and CAN FD messages. The maximum number of
messages the list is able to contain must be set in the count field. When returning from this function, the
count field is set by the driver to the real number of copied messages.
Note: Reading several messages from the driver might block the calling task, unless the device node
has been opened in non-blocking mode. In that case, -EWOULDBLOCK is returned by this function if
the task didn't find any message to read.
If at least one message has been successfully read, then the function returns 0. Otherwise, it returns a
negative error code.
59
PCAN Driver for Linux v8 - User Manual
Using this function saves memory copies and constant round trips between kernel and user spaces.
Example:
#include <malloc.h>
#include <libpcanfd.h>
#include <errno.h>
return -EINVAL
}
free(pml);
…
If the return value is positive, then it indicates the real count of messages read from the device input
queue. Otherwise, it's an error code.
60
PCAN Driver for Linux v8 - User Manual
struct pcanfd_available_clocks {
__u32 count;
struct pcanfd_available_clock list[0];
};
User is responsible to setup the "count" field with the count of items it has allocated in the "list[]"
array.
Example:
free(pac);
Note: list[0] always contains default clock value. Only CAN FD devices define more than one clock.
61
PCAN Driver for Linux v8 - User Manual
struct pcanfd_bittiming_ranges {
__u32 count;
struct pcanfd_bittiming_range list[0];
};
User is responsible to setup the "count" field with the count of items it has allocated in the "list[]"
array.
Version 8.2 of the pcan driver always sets 1 in the "count" field for any CAN 2.0 device, while it sets 2 for
any CAN FD device.
Example:
if (pbr->count == 1)
printf("CAN 2.0 device\n");
else
printf("CAN FD device\n");
free(pbr);
Getting the value of an option that doesn't exist returns -EINVAL, while getting an unsupported option
(for the device) returns -EOPNOTSUPP. Reading the value of an option with a too small value buffer
returns -ENOSPC.
Successfully reading the value of an option returns the number of bytes that have been copied into
value.
62
PCAN Driver for Linux v8 - User Manual
Cooked timestamps handle clocks drift between the different clocks systems (PC,
board, USB controller…)
63
PCAN Driver for Linux v8 - User Manual
If the device is not able to switch in MSD mode, reading this option fails and errno is
set to EOPNOTSUPP.
PCANFD_OPT_DRV_CLK_REF 4 Get the clock reference used by the driver (see Table 6 on page 21 ).
PCANFD_OPT_LINGER 4 Get the maximum waiting time in ms. the driver will wait before closing the device,
while there are frames to write pending in the driver device Tx queue.
Table 12
Setting the value of an option that does not exist, or setting an invalid value to an existing option returns
-EINVAL, while setting a value to an unsupported option (for the device) returns -EOPNOTSUPP.
Cooked timestamps handle clocks drift between the different clocks systems (PC,
board, USB controller…)
64
PCAN Driver for Linux v8 - User Manual
If the device is not able to switch in MSD mode, setting this option fails and errno is
set to EOPNOTSUPP.
If the user hasn’t got root privileges, setting this option fails and errno is set to
EPERM.
PCANFD_OPT_FLASH_LED 4 Makes the LED of the device blink to identify it (if it is equipped with one).
Value is the number of milliseconds the LED should blink.
PCANFD_OPT_DRV_CLK_REF 4 Set the clock reference used by the driver (see Table 6 on page 21 ).
PCANFD_OPT_LINGER 4 PCANFD_OPT_LINGER_NOWAIT Task doesn’t wait for the Tx queue to be empty
before closing the device.
PCANFD_OPT_LINGER_AUTO Driver automatically computes time to wait for the
TX queue to be empty before closing the device.
Any other positive value defines the maximum waiting time in ms. before closing
the device. The default value is 1000.
Table 13
Table 14 describes the order and how each bit of the flags argument is interpreted:
Bit Description
OFD_BITRATE The specification of the nominal bitrate starts with the third parameter:
If OFD_BTR0BTR1 is set too, then the third parameter is interpreted as a 16-bit value
respecting the BTR0BTR1 SJA1000 format.
If OFD_BRPTSEGSJW is specified, then the 3rd, 4th, 5th, and 6th parameters are
interpreted as BRP, TSEG1, TSEG2, and SJW values.
If none of the above bits is set, then the third argument is interpreted as a bits-per-
second value.
OFD_SAMPLEPT Argument next to the nominal bitrate is the minimal sample point rate requested. If
not specified, the driver uses its own default value. If specified, this value must be
expressed in 1/10000th (that is, 8750 stands for 87,5 %)
OFD_DBITRATE The data bitrate is given in the next arguments:
If OFD_BTR0BTR1 is set too, then the next parameter is interpreted as a 16-bit value
respecting the BTR0BTR1 SJA1000 format.
If none of the above bits is set, then the next argument is interpreted as a bits-per-
second value.
OFD_DSAMPLEPT Argument next to the data bitrate is the minimal sample point rate requested. If not
specified, the driver uses its own default value. If specified, this value must be
expressed in 1/10000th (that is, 8750 stands for 87,5 %)
OFD_CLOCKHZ The clock frequency (in Hz) to select in the CAN controller is given in the next
argument.
OFD_NONBLOCKING The device node is opened in non-blocking mode.
65
PCAN Driver for Linux v8 - User Manual
Bit Description
PCANFD_INIT_xxx All of these flags are used to initialize the CAN device, as if it was initialized using
“int pcanfd_set_init(int fd, struct pcanfd_init *pfdi);”.
Example:
#include <libpcanfd.h>
int fd;
/* open the 1st CANFD channel of the PCAN-USB Pro FD and set 1Mbps+2Mbps bitrate */
fd = pcanfd_open("/dev/pcanusbprofd0",
OFD_BITRATE|OFD_DBITRATE,
1000000,
2000000);
…
CAN 2.0 API defines these two sub functions to set/get specific parameters:
With pcan v8.14, CAN-FD API has extended this usage by including the “ucDevData” 64 bytes array field
to be able to exchange more than simple 32 bit data objects:
66
PCAN Driver for Linux v8 - User Manual
or:
In this case the user application can neither use the libpcan nor the libpcanfd library but has to be
built over the socket API instead. The programmer can access the online documentation, starting, for
example, at these links:
https://en.wikipedia.org/wiki/SocketCAN
https://www.kernel.org/doc/Documentation/networking/can.txt
67