[crosspost from github]
hi WPILib folk (@Peter_Johnson ?)
since the SystemCore device is based on a CM5, I’m wondering if the WPIlib suite, including DS communication and actuator heartbeat, will be able to run on a raspberry pi? for training scenarios in the lab, we don’t need everything the SystemCore offers, in fact we really only need an RPi with a CAN hat. Would that work?
Keep in mind the SystemCore is an expansion board. Even if you can run the full systemcore OS/Image on it there will be issues like “DEVICE NOT FOUND” galore
Assuming when you say Training, you meant programming, then your best bet is the XRP. It doesn’t have a CAN hat - no SW support yet in the WPILIB as far as I know but I haven’t been keeping up with the XRP in a while so I can be off here.
The ROMI should still work too but I haven’t touched one in a long while so I could also be wrong.
well, I really mean “not competition.”
during subsystem development, each sub team uses it’s own RoboRio to drive their mechanism.
during the fall, our rookie cohort builds up several simple robots, again, with a RoboRio each.
I’m aware of the romi and xrp, that’s not what I’m interested in.
re: “device not found”, I mean, that’s what the HAL is for, no?
Well the HAL expects everything to be there, an alternate HAL would need to be created for a more limited device. Which takes work and time to do and support.
Additionally, we don’t own the heartbeat and DS comm code, so that’s not really a WPILib decision to make. The actuator heartbeat is a kernel module, so at minimum you’d need to compile a custom Pi kernel to add that in.
I flashed a Pi 5 with the Systemcore Alpha 3 image just to test. Driver Station is able to connect, and robot.local is reachable, but as expected, it doesn’t fully work. Although WPILib is able to successfully deploy the robot code, the Driver Station reports no robot code.
Edit: Got it to deploy the code with a virtual can simulator.
Wonder if we could buy said HAT/expansion separately…
or have it produced by someone else
re: CAN hats, these are COTS things.
Note: for the use case it’s intended for, it seems like the forthcoming SystemCore will be terrific, and I don’t want my interest to seem unsupportive. We should support this project! We should buy lots of them! But if you already have dozens of Raspberry Pi’s, as we do, it would be cool to be able to use them too.
I am trying to communicate with an MCP2515 connected to an Arduino using an MCP2515 connected to a Raspberry Pi, to test if SPI-CAN communication is doable. At 500 kbps, messages are delivered both ways without any issues, but when I go above that speed, it starts causing problems.
I’m currently using bit banging because I couldn’t get the Python spidev library installed, and the MOSI-MISO loopback test failed as well. I’m guessing the loopback failure might be because the GPIO setup was originally made for the CM5.
I’m not an expert in this area and I have no idea what I am doing, so any guidance would be much appreciated.
Also, sorry — I meant to reply to my own message but accidentally replied to truher instead.
This is on the Raspberry Pi side? You should use the mcp2515 kernel driver and socketcan instead. On a Raspberry Pi you can enable this by applying one of the device tree overlays for use with the mcp2515.
I’ll note that even using that driver, it may struggle to reliably receive all messages at high bitrates on a bus with high utilization- this is due to the fact that the mcp2515 can only hold 2 received messages at a time, and if the host processor (the pi, in this case) hasn’t read the message before more messages arrive, the incoming messages will be dropped. The pi receives an interrupt request every time a message is received, but most of the interrupt routine implemented in the Linux driver is executed in a threaded (non-hard IRQ) context, so depending on system configuration and load, it can still be overwhelmed. These are really designed to be used with a bare metal microcontroller that can service interrupts quickly.
https://www.amazon.com/2-Channel-Expansion-Controller-Transceiver-Protection/dp/B09BHWQB68
If you’re wanting to match the functionality of the SystemCore CAN interfaces, this hat will work well. It uses the same CAN controllers as SystemCore (MCP2518FD), which have good driver support in Linux and don’t suffer the issue I mentioned above as they are able to queue quite a few messages onboard.
Hey CD, noob here (for non-Gen Z people that means I have no clue what I’m doing) does it matter if its a normal pi 5 or a compute module. thx 
The word “noob” is a millennial: NOOB Definition & Meaning - Merriam-Webster
To answer your question, it shouldn’t matter that much. The software theoretically could check if it’s running on a computer module or not, but I don’t think there’s much of a point to that and it’s not difficult to work around from what I remember.
Thank you, yes it is on the raspberry side. I edited the Systemcore boot config to enable spi and I can see that MCP2515 was initialized after reboot but clock reports as 4MHz. Also “sudo ip link set can0 type can bitrate 1000000” returns invalid argument. “sudo ip link set can0 type can bitrate 500000” sets the bitrate to 500kbps successfully but I believe I need 1Mbit/s for FRC CAN communication.
I actually bought that 2-channel CanFD Hat, but it won’t arrive for another week . I got a few 2515s someone gave me so I am just trying to get them working.
[boot_partition=2]
cmdline=cmdline.txt
[boot_partition=3]
cmdline=cmdline_b.txt
start_file=start4.elf
fixup_file=fixup4.dat
over_voltage=2
#disable_touchscreen=1
boot_delay=1
kernel=Image
disable_overscan=1
hdmi_ignore_hotplug=1
hdmi_ignore_edid=0xa5000080
#hdmi_edid_file=1
hdmi_blanking=2
ignore_lcd=1
dtoverlay=miniuart-bt
disable_splash=1
dtoverlay=pi3-disable-bt
#dtoverlay=disable-wifi
dtoverlay=disable-bt
dtparam=audio=off
dtparam=spi=on
enable_uart=1
arm_64bit=1
force_eeprom_read=0
dtparam=ant2
#pi5
# 2 canbuses on spi2 pi5 / spi3 pi4
dtoverlay=spi2-2cs-pi5,cs0_pin=0,cs0_spidev=off,cs1_pin=24,cs1_spidev=off
dtoverlay=sc-mcp2518-can0-spi2,oscillator=40000000,interrupt=22,spimaxfrequency=20000000
dtoverlay=sc-mcp2518-can1-spi2,oscillator=40000000,interrupt=26,spimaxfrequency=20000000
#interrupt changes from 11 to 17
# 3 canbuses on spi1 pi5 / spi6 pi4
dtoverlay=spi1-3cs,cs0_pin=27,cs0_spidev=off,cs1_pin=25,cs1_spidev=off,cs2_pin=18,cs2_spidev=off
dtoverlay=sc-mcp2518-can2-spi1,oscillator=40000000,interrupt=9,spimaxfrequency=20000000
dtoverlay=sc-mcp2518-can3-spi1,oscillator=40000000,interrupt=17,spimaxfrequency=20000000
dtoverlay=sc-mcp2518-can4-spi1,oscillator=40000000,interrupt=8,spimaxfrequency=20000000
# spi3 pi5 / spi4 pi4
#IMU LSM (builtin)
#dtoverlay=spi3-1cs,cs0_pin=4,cs0_spidev=on
# MCP2515 configuration for external CAN controller
# Using SPI0 (standard pins: SCLK=11, MOSI=10, MISO=9, CS=8)
dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25,spimaxfrequency=10000000
#working gadget
dtoverlay=dwc2,dr_mode=peripheral
dtparam=pciex1_gen3
camera_auto_detect=0
display_auto_detect=0
dtparam=i2s=off
#dtparam=i2c_arm=on
#dtparam=i2c0=on
#dtparam=i2c1=on
#dtparam=i2c0_baudrate=100000
#dtoverlay=i2c0,pins_44_45
dtparam=i2c_csi_dsi0=on
dtoverlay=i2c1,pins_10_11
I’d recommend not doing this with the systemcore image, at least while you’re trying to get it working. If you must, I’d recommend disabling the systemcore CAN interface overlays.
You’re currently telling the driver that the controller is using an 8MHz external oscillator. Is this what you actually have attached? If it’s not, you’ll need to set the correct frequency in the overlay configuration in config.txt.
Linux won’t let you set the bitrate to 1Mbps because that bitrate isn’t achievable with the MCP2515 using an 8Mhz oscillator. On the MCP2515, 1 time quanta is 2 cycles of the external oscillator (which is why the clock is reported as 4Mhz). To achieve 1Mbps reliably on this chip you’ll need an oscillator with a frequency of at least 16MHz.
its possible to do on a rpi5 i had to jump through some hoops to get it to work but you can do it
I got the can_s0 and can_s1 working on the PI 5 with 2-ch CAN FD hat, Ryan_Blue mentioned. I haven’t been able to get Tuner or the Java code to control any motor controllers, but they do show up in Phoenix Tuner, and I was able to update the firmware on the Kraken
Sorry txrnqt, I somehow managed to accidentally reply to a person instead of the topic itself again.
Wpilib is going to require all 5 buses to exist, which is likely why nothing wpilib loads. Additionally 5 buses are needed for the heartbeat.
Basically, we expect all the hardware that exists on systemcore. If you don’t have all of it, don’t expect things to work.
Just asking because I don’t know but doesn’t DS have anything to detect heartbeat is not present and disable the robot after it is enabled?
