Raspberry Pi CAN
Last Modified Aug 20, 2021

Introduction

I am putting together two Raspberry Pi units as an work-related experiment (on my own time with my own money). One has a PICAN 3 HAT (for CAN), the other has a PICAN FD HAT (for CAN-FD). At the moment, both Pis are 4B 8GB models, which would be my target for the work-related experiment. If I keep these particular units (which I'd expect to do because it provides a development and test environment), I'll probably swap them with 4B 4GB models I have. I need these for CAN sniffing and injection, and I don't really anticipate needing a GUI. Given that CAN tops out at 1 Mbps and CAN-FD in automotive typically tops out under 8 Mbps, I don't anticipate needing a large RAM cache of messages; even an average microSD card should be able to sustain the I/O needed to write continuously (and of course I'll be using the filesystem, which has its own cache).

It's worth noting that at the moment, I'm running the 64-bit version of Raspberry Pi OS, which has been in beta for about 9 months. I haven't had any issues yet, but I haven't been hard on them yet.

One issue I ran into: the lack of availability of stacking headers for the PoE HAT. I prefer having the PoE HAT on all of my Pi 3B and 4B, for the convenience of always having PoE on-board (I don't need to carry a PoE splitter with me). Unfortunately it's hard to get the 4-pin stacking header from the usual suspects, and most of them are actually incorrect; they use extra-long pins despite the fact that nothing should plug into the 4-pin header except the PoE HAT. And the newer PoE+ HAT doesn't allow pass-through of the 4-pin header (no holes in the PoE+ HAT's PCB for the 4-pin).

I ordered stacking headers from The Pi Hut, despite knowing the 4-pin won't work with the PoE+ HAT. It took roughly 2 weeks for them to arrive. They work for stacking Pi 4B 8G, then original PoE HAT, then the PICAN FD, but require 15mm standoffs between the Pi 4B and the original Pi PoE board; not ideal but the upside is that it leaves room for shallow heatsinks on the SOC and other components while not hitting the PoE board's fan. The 4-pin stacking headers protrude well beyond the top of the original Pi PoE HAT PCB and should definitely be shorter. I'll cut and shape them and look for a more reasonable 4-pin header.

<soapbox>

I'm annoyed at the Pi Foundation regarding the PoE+ HAT. A number of problems have cropped up, which tells me they didn't learn enough from the problems with the original PoE HAT (Rev1). Users are reporting high power consumption at idle, high temperatures at idle, a louder fan, and horrible noises if the Pi is powered from USB-C while powered from PoE. That's in addition to the change that makes us search out new stacking connectors for the 4-pin PoE connection (and none of the usual suspects sell such a connector). Meanwhile, the reliable Rev 2 of the original Pi PoE HAT is not available everywhere. However, there's at least one reasonable (i.e. isolated) alternative (from Waveshare).
</soapbox>

Sadly I'll be waiting a while for the stacking headers to arrive, since they're coming from Europe and I wasn't willing to pay for expedited shipping.

I'm using mostly-open cases for these. I need fairly easy access to the DB-9 and screw terminals on the CAN HATs, and there are no fully enclosed cases for my planned stackup (Pi 4, PoE HAT, CAN HAT) with precut holes in the right location for the DB-9 and screw terminals on the CAN HAT. Yet another situation where I wish I had a 3D printer. However, I don't know if we can use PoE for the target application at work. If there's no PoE HAT needed there, I can use an enclosure from copperhilltech.com. However, even those enclosures don't provide access to the CAN screw terminals or a 120 ohm termination jumper should we choose to solder one in place (sadly, right now the Seeed Studio CAN HAT with built-in switches for 120 ohm termination isn't available). In any case, I prefer PoE if available. An isolated version, of course. On a managed switch, it's just easier to deal with:

The stackup, once the stacking headers arrive, should look roughly like the images below. Raspberry Pi 4, PoE HAT, PICAN FD HAT):

For the intended target, we'll want a fully prepared spare. Fortunately this is easy to do; duplicate hardware, and a prepared microSD image that we'd maintain (which should not need to change very often). That image would contain standard Raspbian and some packaged software (Debian packges), whether just can-utils or our own. When we need to update, we should be able to do it remotely (standard apt get ... for things like can-utils and dpkg -i ... for anything we create.

Long term it might be nice to be able to stack an opto-isolated I/O board, just so we could see some of the tester actions that are not via a network bus. The alternative would be to have the tester send information via TCP or UDP, but there are latency variances that make that solution less desirable.

Why go through all the trouble? Well, I'd just like to be able to get CAN logs when a tester is having trouble, without jumping through hoops (and across more than 10 time zones) to get them. This lets us analyze some tester/DUT behavior from afar. It's not perfect but it will pay for itself the first time we need it; we spent a lot more in engineering hours trying to get useful log data from a recent tester to DUT issue than the cost of this setup. Our build was delayed by several days just trying to get a log that we could use to figure out what was wrong with the first issue encountered. Even if someone has to pull this device out of a tool box, blow the dust off and plug it in... it'd be way faster than what we recently experienced.

Purchases by Vendor

www.amazon.com

copperhilltech.com

www.microcenter.com

thepihut.com

Totals by Vendor

Raspberry Pi 4 8GB with PICAN-FD and PoE HATs

Changes to /boot/config.txt

Uncomment this line: 

    #dtparam=spi=on
Add these lines: 

    # Enable PICAN FD
    dtoverlay=mcp251xfd,oscillator=16000000,interrupt=25
    dtoverlay=spi-bcm2835-overlay

Configuration works?

So far, yes.


 % uname -a
 Linux raspberrypi 5.10.52-v8+ #1441 SMP PREEMPT Tue Aug 3 18:14:03 BST 2021
  aarch64 GNU/Linux



 % dmesg | egrep 'CAN|mcp'
 [    4.968779] CAN device driver interface
 [    5.022167] mcp251xfd spi0.0 can0: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN
  +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:16.00MHz m:20.00MHz r:6.80MHz e:6.75MHz)
  successfully initialized.



 % lsmod | grep can
 can_dev                36864  1 mcp251xfd



 % ip link show type can
 4: can0:  mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
     link/can 



 % ifconfig can0
 can0: flags=128  mtu 16
     unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
     RX packets 0  bytes 0 (0.0 B)
     RX errors 0  dropped 0  overruns 0  frame 0
     TX packets 0  bytes 0 (0.0 B)
     TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     device interrupt 68
Here's the parts list for the Raspberry Pi 4 8GB with PICAN FD and PoE HATs. This list doesn't include M2.5 screws for the PICAN FD HAT; you should get some with the PoE HAT as well as the PICAN FD HAT.

CAN-FD Purchases by Vendor

www.amazon.com

copperhilltech.com

www.microcenter.com

thepihut.com

www.digikey.com

Totals by Vendor

Diary