Closed brainstorm closed 3 years ago
It would be nice if your changed did not introduce unnecessary whitespace modifications to the files. It's difficult to tell what was changed or not.
Agreed, it was a quick on-my-phone type of pullrequest, but this repo has not seen a merge since 2017, so closing.
It's unlikely it'll be acted upon, happy to be convinced otherwise by @ericevenchick or whoever maintains this repo... also, feel free to add my changes to your pullrequest in #20 or open another one yourself @trollcop ;)
FYI I do have a fork of this repo with an updated HAL library with better performance on heavily loaded busses/etc. I haven't merged in hardware filtering yet, and I think I may have broken support for devices with external oscillators (if I remember correctly). I'm still doing active development on this fork.
Oh, nice work! While you are here, I have this burning question, let's see if you can address it since I'm genuinely curious:
https://github.com/linklayer/cantact/issues/3#issuecomment-752041563
TL;DR: The author, @ericevenchick, claimed that SLCAN is "generally not good" and that I should use gs_usb
and another firmware entirely (candleLight) instead... what's your take on that? Is there really a perf difference and do you reckon you've corrected it in your fork?
Cheers and kudos for your work @normaldotcom!
I would agree... slcan is definitely not the best option if you're running on Linux. Using the gs_usb / candlelight firmware gives better performance at high bitrates/busloads and eliminates the overhead of slcand. And it's just nice to plug it in and "can0" shows up immediately. I always recommend gs_usb when running on Linux with a reasonably modern kernel, the fact that you don't need to run slcand is enough motivation for me!
Fixes compilation warnings of the sort (mentioned on https://github.com/linklayer/cantact/issues/3)... quick on-the-web type of patch/PR so tabs and spaces are garbled, but you get the point :-S