search

REVrobotics / 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.
Other
11 stars 5 forks source link

CANBridge: Add support for Linux and macOS #29

Open qwertychouskie opened 3 months ago

qwertychouskie commented 3 months ago

The @unofficial-rev-port team has been hard at work making the core technologies used by the REV Hardware Client work on all 3 major platforms (Windows, macOS, Linux). This PR contains changes needed for CANBridge to compile and run on macOS and Linux in addition to Windows; and the GitHub Actions changes needed to upload binaries for all 3 OSes for use by the node-can-bridge build process to pull the correct libraries for the 3 platforms (see https://github.com/REVrobotics/node-can-bridge/pull/21).

Please note that this PR is still a work-in-progress; while we have successfully ran a local build of the REV Hardware Client that was able to load and initialize the CAN backend, we are still in the process of testing with real hardware to ensure full functionality (and no regressions) on all 3 OSes. We are opening this PR in the current state in order to gather feedback and make sure we do the changes in a way acceptable to having the PR merged upstream (once completed, of course).

garrettsummerfi3ld commented 3 months ago

Other notes to be made, we have added CI to this to validate not only the already existing workflows, but also new builds to support Linux (ARM32/64, and x86) and macOS. Along side those changes, modernizing the existing workflows and modernization to allow directly GitHub Actions to create releases on behalf of the repository.

NoahAndrews commented 2 months ago

Thank you for contributing! I expect that this work will be the hardest part of bringing Mac and Linux support to the REV Hardware Client, so if you're successful here, that increases the odds of that happening significantly.

I see that you've started with porting the serial driver. Unfortunately, the serial driver only works with SPARK MAX firmware 1.4 and earlier, and the REV Hardware Client doesn't use it at all (it has its own minimal implementation of the serial protocol that is only capable of putting the device in dfu mode).

For Linux support, see the SocketCAN branch (see the Linux section it adds to the README). The Linux kernel actually contains a gs_usb driver that is compatible with our USB CAN devices, so on Linux we can take advantage of that, and use Linux's SocketCAN interface instead of writing low-level USB code. I'm not sure what shape that branch is in, but I would recommend starting a new branch based on that one, merging main into it, porting over your CI and build changes, and going from there. I would also be interested in merging a PR that deletes the serial driver entirely.

The big lift will be writing a candle/gs_usb driver for Mac. Unfortunately, that protocol is not documented anywhere that I've seen, so if you want to tackle that, you're probably going to have to learn it by reading the candlelib code in this repository (originally published here) and kernel gs_usb driver source code. There's also a python implementation.

Please let me know if you have any questions! Once you have some code that will work with modern REV firmware, I'll give it a more thorough review.

NoahAndrews commented 3 weeks ago

Note to self: Test timestamp resolution on new platforms before merging

LandryNorris commented 1 week ago

We're adding support for RTR messages (Remote Transmission Request) in #36. The way an RTR is indicated is unfortunately not very standardized. WPILib uses one of the reserved bits (0x80000000) of the ARB ID. Since there's no standard way of specifying this (candlelib uses 0x40000000, for example), each driver has to handle the translation. See the diff in #36 for how the Candlelib driver will handle this translation.