CANBridge: Add support for Linux and macOS #29
Conversation
Note you might need to complie wpilib your self to complie this yourself this is due to wpilib not compling for all versions of linux in the maven repo
There's a lot of warnings that apparently aren't showing up on the Windows build
Fixes broken CANBridge builds on any macOS platform.
Updated workflows to better handle artifact uploads. This includes better cleanup of no longer dumping all the possible platforms into the main directory of the CI job, as well as for each platform type, specific artifacts for each platform is made to lower artifact sizes and to be specific to the correct platform. Added other adjustments for platform types across the workflow for future ARM-specific builds Added macOS artifact creation.
Added builds to utilize Linux ARM 32 and 64 bit versions. Added artifact uploads for Linux versions.
Disabled fail-fast to allow for all other jobs to continue running without interruption, especially if another job fails inside the matrix. Added step to install 7Zip for the Docker CI. This is just to zip and archive up packages without issues.
Steps for unarchiving and archiving HALs are split up to add verbosity to the CI steps, if a specific step fails, we are able to diagnose more quickly. Updated release CI steps, using updated Actions and cleaner methods to check if the build CI completed.
Updated dependent actions due to deprecation notices.
Update artifact uploading workflows, add ARM workflows, update release workflows
This updates workflows to produce headers for CANBridge separately from the built binaries.
The linker flag wasn't needed apparently
|
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. |
|
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 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 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. |
Brings SocketCAN from upstream back to origin with already existing changes from main for workflows and other changes.
Some of the functions and implementations were not readily available nor created. This now resolves those issues.
This commit adds the implementation for the SocketCANDevice class, which was previously missing some functions and implementations. Now all required functions are available and the issues have been resolved.
This was missing the previous commit. Change compiler options to have SocketCANThread actually compile instead of not.
Mirroring SerialDeviceThread.h as it was changed years ago.
Adding more compiler args to prevent other platforms that are not able to compile some platforms to compile files, as it would just error and fail the build. Fixing broken functions such as `SocketCANDevice::GetID()` as it was not returning a string. This is now not implemented but it returns an `int` which is correct for the function.
Fix SocketCANDevice from being broken on compiles, from broken constructors to missing includes.
This is largely untested, however this should bring the functionality of the SocketCAN work somewhat back into play.
This tears out the majority of what was [candle_dll](https://github.com/HubertD/candle_dll/tree/master) for the Linux driver and implemented the Linux [SocketCAN](https://docs.kernel.org/networking/can.html) driver. Preliminary testing shows that this does functionally work with a single SPARK MAX motor controller, however further testing may be required.
Updated section for Linux support.
The googletest dependency was using an older version from the WPILib Artifactory, this was causing issues with builds on macOS where `osxuniversal` platform type was not available, and split between `osxarm64` and `osxx86-64`.
Plans to fully delete the serial driver are underway, as this is not supported or even functioning with current firmware.
SocketCAN devices aren't exclusively, changing it to something more generic.
Add SocketCAN functionality
The current implementation of the tests were accounting for only Linux platforms for SocketCAN, this has been changed to allow for all currently supported platforms. This also removes conditionals that prevented any GoogleTests from running.
|
Note to self: Test timestamp resolution on new platforms before merging |
|
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. |
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 REVrobotics/node-can-bridge#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).