In the kernel, enable
CAN networking and your appropriate CAN hardware device driver:
Networking support -> CAN bus subsystem suportand the CAN device drivers also live in that menu branch (i.e. NOT under the "Device Drivers" main menu).
#modprobe <the driver for your CAN controller> modprobe plx_pci ip link set can0 type can bitrate 125000 ip link set can1 type can bitrate 125000 #ifconfig can0 up #ifconfig can1 up ip link set can0 up ip link set can1 up # the socketcan user-space tools have moved from SVN at Berlios to GIT at Github aptitude install git git clone https://github.com/linux-can/can-utils/ cd can-utils make make install candump can1 # switch to another console cansend can0 5A1#1122334455667788
All of this works "out of the box" in Debian 8.1 Jessie.
Yes, the netfilter's "ip" tool already knows about CAN.
And yes, the libc / kernheaders already contain the CAN #defines and structs.
It really all worked in Debian 6 Squeeze already.
For more information on how to use the "socket CAN" from your programs,
check out Documentation/networking/can.txt in your kernel source tree.
And, the can-utils directory is a great source of code examples.
Long story short, being an Advantech agent, I have good access
to their CAN hardware. Read the next chapter for some gory details and history.
If you are here because you need to get some CAN hardware by Advantech to work,
at this time (2019) I recommend that you patch
this driver
into your kernel source tree. It's an advantech-proprietary driver
called AdvSocketCAN, patchified for in-tree building by me,
tested against 5.2.7.
Comments on Advantech CAN hardware
By now, Advantech has quite a tradition of solid quality
CAN interface cards for the PC, using the Philips SJA1000
controller chip.
It probably started with the ISA-based PCL-841 and its
PC104-based equivalent called the PCM-3680
(do not confuse with the younger PCM-3680I=PCI104).
Then came the equally venerable PCI-1680,
combining two pcs of the SJA1000 with a PLX PCI9030
slave bridge ASIC. And it's PCI104 sister PCM-3680I.
And an onboard integrated sibling in the UNO-2052.
In the summer of 2014, PLX corp. (at the time owning Oxford Semi)
got acquired by Avago, which later also acquired Broadcom
but took its name... So within the resulting "new Broadcom"
conglomerate, the traditional slave bridges by PLX (and UARTs
by Oxford) got gradually phased out, which left Advantech
(and others) with no other option, but to redesign their
boards around FPGA-based PCI interfaces. Hence the birth
of PCI-1680 rev.B (PCI device ID PCI-1681) and several
similar design upgrades across the Advantech portfolio.
The Advantech interface card design exists in several
mechanical form factors, and a particular model can
apparently be known under several ordering codes...
possibly depending on the accessories included?
On a recent occasion, I've tested the Advantech driver
with an "iDoor module" purchased under the ordering code of
MOS-1130Y. Apparently that same module is also
known as the PCM-26D2CA (there's a Windows driver
referring to that name). The PCB of the MiniPCI-e card
has PCM-2680 etched in the copper. And, the PCI
device ID of 0xC302 gets reported as MIOe-3680
by the "lspci" utility - but we know that the MIO is
a different (proprietary) mechanical form factor
of the expansion card... so this refers to electric compatibility.
BTW, the product has a Spartan FPGA for a PCI interface.
Advantech seems to have a productive marketing dept :-)
The SJA1000 is a workhorse. If there's one thing to praise
Advantech for, it's sticking to the SJA1000 in their designs.
The SJA1000 is reliable, free of bugs and well documented.
If you happen to know about some downsides, at least
they've been known for decades = there are no bad surprises
to be expected.
The SJA1000 has open-source drivers that have been
stable for years - including a driver core in the vanilla
Linux kernel, which is wrapped in ISA-based and PCI-based
driver modules. Other CAN interfaces may be more efficient
in terms of CPU load (on part of interrupts and polling),
PCB real estate or power consumption, but the SJA1000
is excellent in that it pretty much "works out of the box".
The old ISA-based cards by Advantech are IOMEM-mapped, which may present a bit of a challenge to configure in some modern PC's = get an ISA IOMEM window reserved / working. (Hint: try ICOP motherboards if this is a problem.) These ISA-based interfaces would probably work with the stock/vanilla sja1000_isa.ko driver (apparently each SJA1000 can have its own IRQ). You just need to specify the two IOMEM bases and the two IRQ's as insmod arguments.
The PCI-based SJA1000 interfaces by Advantech need a little
more work to get going.
The original designs with PLX slave bridges would almost work
with the stock/vanilla plx_pci.ko . For some reason, the vanilla
driver did need a tiny patch
to modify some timeout during chip init - after that,
it worked just fine.
With the demise of the PLX bridges, and the corresponding
rise of the custom FPGA-bridges, sadly it makes less sense
to keep all the "SJA1000 on PCI" card models,
from different vendors, in one vanilla driver.
In that context, years ago, Advantech have published their
own driver called "advsocketcan" (= another factor to its
release was the standardization of SocketCAN support in Linux.)
The original Advantech download of AdvSocketCAN is accompanied by a Makefile for the "out of tree" build method. Unfortunately, this build method (once officially recommended) is now deprecated, and causes a "kernel tainted" on insmod. Perhaps the intended message here is, "get your open-source driver accepted upstream" (with all the rigorous collective nitpicking that involves). If for some reason this route proves unfruitful ;-) , you need to patch the driver into your vanilla kernel source tree. I have turned the AdvSocketCAN into that format - along with a few cosmetic additions. See the download link in the previous chapter.
The Advantech driver contains its own copy of the sja1000.c.
This clearly originated as a copy of the same file in the vanilla
Linux, at some past point in time. And, the file present in the
original Advantech download would clash with the vanilla sja1000.c
in that it exports about 5 functions with overlapping names.
I have worked around the problem by renaming those functions
in the Advantech version of the file, so that both the vanilla
sja1000.ko and the Advantech sja1000.ko can be present in the
kernel at the same time.
Still, perhaps it would be more appropriate to make the
advsocketcan driver work with the vanilla version of sja1000.ko.
If I take a diff, there are some differences - clearly
each version has slightly evolved in its own direction,
since the fork.
Yet nearly all the differences feel perfectly cosmetic
(macro names modified, without a change in their functioning,
and the like). Maybe I should just try... maybe later.
The Advantech hardware is good quality. It would be nice if Advantech worked to push its wrapper driver around SJA1000 upstream, but perhaps this is too much to hope for. Even the way it is, the Advantech CAN interfaces are much more useful in Linux, compared to various proprietary CAN ports included in competitors' industrial PC hardware (some MCU with proprietary firmware, attached to the host PC via RS232 or USB, hardly even documented...) The SJA1000 on PCIe is a safe bet.
blurted by: Frank Rysanek [ rysanek AT fccps DOT cz ]