@CollinK I think I’ve finished with the Single-Wire CAN reworking (after debugging by recreating the project to try to trace my error, I now find my original implementation working so I chalk it up to user error initially).
Any objections to my changing the file names, say to “SW_CAN_MCP2515” from “sw_can”, solely to try to cut down on the number of issues from people managing to find old old versions? (I’m not tied to the suggested name).
It might not be a bad idea to rename it so that people are forced to update. Though, if the function names are different it sort of requires appropriate changes to the user sketch as well. It’s up to you.
Did you actually test SWCAN at 33.33k? Because, the library seems horribly broken in the baud rate setting function. I’m going to rewrite it to be better at finding a good setting for a given baud rate.
Nope, I was just using “Verify/Compile” as my test that re-arranging the code didn’t break anything. I don’t like that level of testing, but that is all that was reasonably available to me.
I just submitted a pull request that fixes CAN rate setting for single wire CAN. The previous code would set the rate to 55000 baud instead of 33333 like I asked for. This is now corrected and I can confirm that with the pull request you can truly get 33333 baud suitable for single wire CAN.
I think that renaming is an excellent idea; given the fact that there’s uncertainty now that cannot be resolved simply by names, it seems the current setup violates good development/deployment practices. It should be possible to differentiate between different libraries, even though they may be forked from the same original set of code.