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.
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:
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:
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 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:
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:
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.