We use cookies on our website to provide you with the best possible service and to further improve our website. By clicking the "Accept all" button, you agree to the use of all cookies. You can limit the cookies used by clicking on "Accept selection". Further information and an option to revoke your selection can be found in our privacy policy.


These cookies are necessary for basic functionality. This allows you to register on our website and forum or order products with our online shop.


With these cookies, we collect anonymized usage data for our website. For example, we can see which content is interesting for our visitors and which resolutions are used. We use the information to optimize our website to provide you with the best possible user experience.


show more

The PCAN Driver - Implementation Details

The First and Historical API (aka the chardev API)

Since the PCAN driver package is released under [L]GPL v2 licence, we provide for free all the source files and Makefiles that enable to build and install it under your own Linux system. The latest package of this driver can be downloaded at the overview or version history webpage and contains:

  • C source files of the driver module
  • C source and header files of the libraries that encapsulate the calls to the driver module
  • C/C++ source files of some examples and test applications that demonstrate the usage of these libraries, as well as enable to test a connexion to a CAN bus
  • PDF documentation that includes a user guide and a description of the programming interfaces

This PCAN driver especially enables to run our PCAN-Basic API for Linux.

The PCAN driver supports by default all kinds of our PC-CAN interfaces. However, the support of some of them can be easily removed when the driver is built, by the mean of some options on the commands line.

The CAN channels are implemented as character devices and UDEV-like systems are setup to create the corresponding entries under /dev. These /dev interfaces can be opened, read, written, and closed by applications, using the provided library (aka "libpcan").

Since PCAN v8, the driver also supports the CAN FD standard. With this new standard, the PCAN driver also offers a new library (aka "libpcanfd") that enables applications to transfer CAN frames with more than 8 bytes in their data fields. In addition, "libpcanfd" offers a newer and more efficient interface to the applications than "libpcan".

By default, the driver as well as all the enclosed binaries are built according to the running Kernel. That means that the output binaries will be (for example) x86 32-bit binaries if you're running a 32-bit Kernel in a PC system. However:

  • The PCAN driver supports CONFIG_COMPAT. That means that it is able to run in a 64-bit Kernel and compatible with 32-bit applications.
  • The PCAN driver as well as the enclosed binaries can be cross-compiled too. This means that you can easily build the binaries targetted to (for example) some ARM platforms, from your x86 PC.
  • The PCAN driver as well as the enclosed binaries include Real-Time support (specifically RTDM support) that enable them to run in RTAI or Xenomai 3.0 patched kernels.

Finally, and because of its canonical age, the PCAN driver has been the first out-of-tree CAN drivers to propose the support of the so-called SocketCAN API (aka "netdev" API). By default, this interface IS NOT activated in the PCAN driver. Moreover, it CAN'T be activated WITH the chardev interface. This means that you won't be able to use (for example) the PCAN-Basic interface over PCAN if it has been built with this SocketCAN interface.

We are keeping this SocketCAN interface into PCAN for historical reasons. But, for several years now, we have moved our support effort of this SocketCAN interface into a new approach: including the support of our PC-CAN interfaces directly into the Linux kernel.

The SocketCAN API (aka the netdev API)

The SocketCAN API has been introduced in the Kernel since v2.6.25. The next milestone in its history was Kernel v3.6 when CAN FD has been included, too. Since 2012, PEAK-System makes the effort to include the support of its PC CAN (FD) interfaces into the Kernel itself, so that you are able to use our PC CAN (FD) interfaces out-of-the-box.

On the contrary of the PCAN driver which is a single monolitic driver that includes support for all of our interfaces, the support of our PC CAN (FD) interfaces in the Kernel is implemented by several mainline drivers:

  • peak_pci (since Kernel v3.2) is in charge of all SJA1000 based PCI/PCIe-like PC interfaces (PCAN-PCI, PCAN-PCI Express, PCAN-miniPCIe, ...).
  • peak_pcmcia (since Kernel v3.4) is in charge of our single or dual channel PCAN-PC Card interfaces.
  • peak_usb (since Kernel v3.4, CAN FD support since Kernel v4.0) is in charge of all our USB PC interfaces (PCAN-USB, PCAN-USB Pro, PCAN-USB FD, PCAN-USB Pro FD, PCAN-Chip USB, and PCAN-USB X6).
  • peak_pciefd (since Kernel v4.12) is in charge of our CAN FD PCIe-like PC interfaces (PCAN-PCI Express FD, PCAN-miniPCIe FD, and PCAN-M.2).

In fact, you just don't care about these names since the Linux system you're running theoretically and automatically loads them according to the hardware it has detected:

  1. when it has started.
  2. when you have plugged the device (USB or PCMCIA CAN interface).

When using these mainline drivers, the CAN (FD) channels are viewed like network interfaces and are named by the system "can0", "can1", ... They can be configured, for example, with using the "ip link" command from the "iproute2" package. On the contrary of the PCAN driver (and the "chardev" approach), no new /dev entries are created by these drivers.

In this world, CAN application developpers have access to the CAN (FD) channels by creating AF_CAN sockets (just like network application programmers do create AF_INET sockets to connect to the IP network).

Please note: Installing the PCAN driver manually automatically with the download package blacklists all these mainline drivers. From this point, the system will automatically loads the installed PCAN driver instead, when it will enumerate the hardware again.