Is there a canivore-esque device from REV?

My team is all rev all the time and we were just wondering if there is a similar device to the canivore that rev makes or if the ctre canivore is the only option?

No, REV sells no such product

It should be noted that the canivore only supports can FD enabled devices (Falcon 500, Cancoder, Pigeon 2.0, Candle) It does not support any other device, including other CTRE devices that do not also support CAN FD.


Which is kind of weird, considering CAN-FD devices support CAN 2.0B on the same network…

I’ve heard rumors that it’s technically possible to configure CANivore to run in the standard CAN 2.0B mode through a workaround (something about like a compatibility mode or something) via Phoenix Tuner, but that you would have to configure it every single time you power on the robot.
I, for one, would love to see CTRE make CAN 2.0B an officially supported option on CANivore since, most of the time, I don’t need a “high speed” CAN bus, I just need another CAN bus to clear up network traffic and still be more fault-tolerant.


This isn’t quite fully true. Having any CAN FD devices on the bus means that all devices on the bus must at least know about CAN FD. This is because an FD frame to a pure 2.0 device looks like an error, and will cause the 2.0 device to throw error frames onto the bus, bringing it down.

The main reason for this is so the entire but and all data structures don’t have to be updated to FD, you can only use FD in the places its actually necessary. However, at least all HW on the bus must be FD capable.

In FRC, most of the older HW is not FD capable, and throwing them on an FD bus would bring down the entire bus.

1 Like

REV technically does make an equivalent that actually predates the CANivore: the SPARK MAX, which is capable of being used as a generic USB to CAN adapter. However, there’s currently no official software support for using it on the roboRIO.


That would certainly be an interesting use of a SparkMax (if the support existed), but I don’t entirely hate it. Cheaper than a CANivore too.

Of note for that: academic: Enable can drivers by jhershbe · Pull Request #121 · ni/linux · GitHub


+1 to this. I actually prefer 2.0B because it’s more tolerant of weird wiring. Looking at CTREs chart below, 20 Falcons, 8 CANcoders, and a Pigeon only uses 114% of the bus on Phoenix 5 CAN 2.0B. Divide that into two busses and bam you’re under 60% on both with no optimization. Plus, even though their FD uses a difficult-to-support 10Mbps CAN, the utilization only goes down by a bit more than half anyway. Frankly I would have preferred an open use 4Mbps FD bus, if FD was desired, so that cheaper modern MCUs that support FD would work with it.

Also CONFIG_CAN_MCP251X :thinking:


I know, right?

That’s a fair point, I just remember back to some automotive logs I had, and I remember seeing a mix of FD and non-FD frames. I guess it was a newer architecture

I’m try to finish the SocketCAN implementation of CanBRIDGE that you started a while ago. Plugging a SparkMAX into a rpi and having a RoboRIO compatible CAN enabled minibot is the goal.

GitHub - FRC-Team-4143/CANBridge: Generic CAN Bridge emulating FRC netcomm CAN driver for connecting a PC to the CAN Bus with WPILib 2020+ and SPARK MAX (FW 1.5.0 or higher) or other drivers, currently only supported in Windows. 4143 branch