We’ve started selling toolboards that are supported by RRF and use an RP2040 but we’ve had to add an additional component to handle the CAN-FD implementation.
We did have a software implementation written that would’ve meant we were able to use standard klipper RP2040 toolboards but we were unable to obtain a licence from Bosch.
Therefore, the additional component we’ve had to add to handle CAN-FD is the MCP2518FD connected via SPI. We use the 2nd core of the RP2040 in RRF to handle all the CAN-FD comms. This means that currently, our toolboards aren’t compatible with klipper. I wanted to put the feelers out to see if anyone was interested in supporting an MCP2518FD implementation in klipper for the RP2040? Obviously the MCP2518FD is backwards compatible with CAN 2.0. This would mean that we could then work with manufactures (BTT, Fysetc and Mellow) to make a truely universal toolboard as we’re currently looking at adding LIS2DW12 support in RRF. If anyone is interested, please reach out to me and we can discuss the supply of hardware etc
RRF uses CAN-FD. It can afford to do so as it uses chips that have native CAN-FD support so all licencing is covered by the chip manufacturer.
Klipper uses CAN 2.0 which is older and no longer covered by patents or licencing.
The RP2040 natively doesn’t support CAN 2.0 or CAN-FD
The toolboard we’ve had made is aimed at RRF so requires CAN-FD. Due to the licencing issues mentioned above, a software implementation wasn’t possible so we’ve instead used the MCP2518FD to handle the CAN-FD communication.
For klipper, as the licencing for CAN 2.0 has expired, it is able to implement a software implementation, allowing chips such as the RP2040 to support CAN 2.0 even when it’s not natively supported.
The MCP2518FD is a hardware solution for chips that don’t natively support CAN 2.0 or CAN-FD.
If support for the MCP2518FD was added to klipper, it would be using CAN 2.0 and would turn klippers implementation from a software solution to a hardware driven solution.
This would then mean that the same toolboard could be used with CAN 2.0 on klipper and CAN-FD on RRF with all the same hardware.
Moved to developers category.
Maybe consider offering an incentive or sponsorship if you’re planning to utilize such as commercial service; it could be highly beneficial.
I can offer the a toolboard or two (as well as some test hardware of whatever BTT/Fysetc make) plus a couple of main boards (all Mellow gear).
Could probably offer a small monetary donation too
its not for adding directly to the SBC as a way of adding CAN. Its part of the toolboard itself to add CAN capabilities to the RP2040. So not sure whether its part of the mainline kernel is relevant
I totally agree, it’s not relevant for your implementation. I just mentioned it.
Cool idea to avoid Bosch licensing fees. Klipper talks by SPI with MCP2518FD (Adding CAN-FD to a Fly-Super8 | RepRapFirmware for LPC and STM32). MCP2518FD talks with RP2040 by CAN-FD. RP2040 on the RRF has nothing to do with Klipper (concerning CAN license).
Though I’m no lawyer!
@jjay_s_uk
Could you provide the schematics from DFD and EFD mentioned here https://s.click.aliexpress.com/e/_Dm7ZASH? Without schematics, there is no way to start.
I’ve added the schematics to here GitHub - Mellow-3D/RRF-spican-modules
but these modules aren’t applicable for this request as they are used to add CAN-FD to mainboards that do not natively support it, specifically STM32F4 based boards.
This is for adding support to klipper for MCP2518FD to RP2040 so CAN 2.0 can be handled over hardware rather than the software implementation that it currently used.
And just to reiterate, the MCP2518FD is already present and installed on the Fly-RRF-36 and is being used to add hardware CAN-FD to the RP2040 MCU
I just want to say not to confuse this request with adding FDCAN. I’m purely interesting in adding the MCP2518FD to support CAN 2.0 on the RP2040 and not FDCAN
I’m not aware of any licensing or patent issues with using CAN-FD on Klipper when using an external chip such as the MCP2518. In previous conversations I indicated I was not interested in writing a software implemention of CAN-FD on the rp2040 in the can2040 library. Implementing the low-level CAN-FD in software seems to add unnecessary risk (given various patents), but this is unrelated to utilizing a hardware implementation such as the MCP2518.
I don’t see any particular gain in utilizing CAN-FD on Klipper as there are far fewer chips available. In particular, it’s harder to find common Linux USB adapters that support CAN-FD. The older CAN 2.0 protocol can be annoying, but it generally works fine for our usages. To wit, using CAN-FD instead of CAN 2.0 enables some additional bandwidth, at the cost of notably worse hardware availability.
I’m sure it is possible to support the MCP2518 chip in Klipper (using either CAN-FD or CAN 2.0), but I suspect it would take notable work. An interested developer would need to implement that support. It is not something that I personally plan to look at.
Just reading this reply regarding CAN-FD and the question that comes to mind is: do you have visibility into the product roadmap for different electronics providers (I guess this would be primarily BTT and MKS, with Duet, Smoothieware and Creality coming up from behind)?
I’m sure this sounds like the tail wagging the dog but I would think your standing in the community would gain you some insight into what different controller board companies are doing and maybe give you the opportunity to express your opinion on what they should be doing.