Add library for CANBus

[krwq]

cc: @BretStateham

i.e.:

• SocketCAN C# wrapper

[shaggygi]

I'm working on a Mcp25625 (SPI) binding. Hardware should arrive tomorrow. While it won't be based around core CAN APIs, it will open the door for...

1. to use CAN on Windows (since WinRT doesn't support that I know of).
2. others to use CAN devices with new API.
3. future path where we can experiment with this device to implement possible ICanController similar to what @JeremyKuhne did with IGpioController and Mcp23xxx.

[krwq]

@shaggygi any luck with this or would you recommend a different device. Do you perhaps know if linux perhaps have a kernel driver for it? Perhaps we can use SocketCAN for that?

Per some conversations on the internet I've read MCP2515 and Mcp25625 have the same registers so perhaps you might be able to reuse that driver and go with SocketCAN.

Direct SPI support is fine too though (as you said it will work also on Windows)

[shaggygi]

@krwq This appears to be a popular device for CAN. I have a bunch of the register classes added to project, but not much meat yet. My effort was going to add code like many of our bindings that interface with SPI and I2C. I have the device and related tooling, but wanted to finish my other assigned issues before getting to0 deep first.

From my little research, I don't believe WinRT has CAN APIs like the other pin types. This brings up another topic as I planned to create a new issue to ask... What is the proper channel to request interaction with Microsoft to request new features/APIs to OS? It might be good to add native CAN to WinRT, but this would help when other issues/requests arise. For example, if #201 is approved, we might need to ask for WinRT SPI hooks to control CS line active state.

As for Linux, I've seen a few libraries. I guess we would end up using a popular one. However, I would like to see it be extensible to interface with multiple types like python-can offers.

If you think this is something more important, I can push back #225 and #226 and work on this.

[krwq]

@shaggygi if you haven't already started on any of these issues I think this one might be more important, if you have then go ahead and finish. How much time do you think they'll take assuming you haven't started?

Btw for Linux implementation I'd go with generic interface (SocketCAN) so that we cover more devices and this seems to be what industry is using and similarly for Windows once they have one (if there is no kernel driver the SPI is fine too since we have to shape the API first anyway).

What is the proper channel to request interaction with Microsoft to request new features/APIs to OS?

Theoretically somewhere here:

• https://wpdev.uservoice.com/
• https://social.msdn.microsoft.com/Forums/en-US/home?forum=Win10SDKToolsIssues

but I suspect those are a bit noisy and likely your issue will get lost somewhere.

I'd recommend you to put your specific request here (if you got specific APIs you'd like to see or if not then I can write something generic) and I'll forward it internally and see if we can get more traction (can't promise anything though).

[shaggygi]

@krwq I made little progress with both, but nothing too far along (basic projects/registers setup, hardware soldered, etc.). I planned to take a little longer on these as they included topics I wanted to study while implementing. So I can push back for now.

As for the Mcp25625, I want to continue implementing with the focus on SPI interface for now. I also wanted to study up on the CAN tooling I have to get up-to-speed on its capabilities. The PR will be to get basic code in so we can play around with the expectation it will be modified to something more generic/extensible. I'll add docs for related datasheets and basic wiring, but don't plan on doing the usual Fritzing and such as this will be changing as we progress. We can do a full sample once we get something more stable.

Last, I have found it a little difficult on trying to name the classes for this binding to fit the coding standards. RXFxEID0 registers for example. I tried playing around with the camel-casing, but found it much easier to name based exactly how the datasheet provides. This makes it easier to search and understand terminology when navigating back/fourth between docs and code. I'll take my lashes on these during my PR 😄

Cross fingers and hopefully I'll have something in a few days for ya.

[krwq]

Thank you @shaggygi! 😄 Fine with keeping the names as long as they are internal, if not then in some situations we can do exceptions.

[krwq]

@shaggygi my MCP2515 just came so I'll be looking at the SocketCAN. Will be nice to have both full control over SPI which works everywhere and implementation which covers family of devices on Linux

[krwq]

I'm closing this since #438 is already merged. We can improve on the design and possibly adjust MCP2515 bindings to expose similar interface to what SocketCan offers.

Going forward I think these will mature a bit better once we start adding CAN based devices/libraries