python-can icon indicating copy to clipboard operation
python-can copied to clipboard

usb2can-libusb driver for native 8devices CAN on OSX and other platforms

Open bri3d opened this issue 4 years ago • 5 comments

This is a very primitive/basic pyusb based native driver for the 8Devices USB2CAN hardware. The current 8Devices USB2CAN driver uses their "Canal" abstraction layer and is Windows-only.

I tested this driver with a "Korlan USB2CAN" I purchased a few days ago, with firmware "2.3." My test harness is an M1 MacBook Air (OS X) performing ISO-TP communication (P2=0.05s) with an ECU CAN bus running at 500kbaud that spams around 300 messages/second, so the driver has been pretty well stress-tested and does seem viable for practical applications. Besides serial CAN, I think this is the first fully cross-platform (Linux, Windows, MacOS) driver, which is nice.

Unfortunately the 8Devices USB2CAN hardware is not well documented at all. So, this driver is based on the 8Devices Linux SocketCAN kernel module (https://github.com/8devices/usb2can/blob/master/usb_8dev.c) which, while it lives in the 8Devices GitHub organization, itself seems to have been based on a combination of private-thread email lore and reverse engineering.

I hope these tests are adequate. I tried to fence the USB part well enough to not require PyUSB for the test suite or on install.

The device does support a loopback mode that could be used to produce a hardware-in-the-loop integration test for owners of the hardware, although I didn't really see precedent for one in the codebase.

One thing I was uncertain of is the desired pattern for handling so-called "error frames." I just pass through the native device "error frames" as error frames directly to Python-CAN for now, which is what other devices seem to do as well.

bri3d avatar Feb 12 '21 19:02 bri3d

Codecov Report

Merging #979 (394e7fb) into develop (71580d8) will decrease coverage by 0.24%. The diff coverage is 63.50%.

@@             Coverage Diff             @@
##           develop     #979      +/-   ##
===========================================
- Coverage    70.49%   70.24%   -0.25%     
===========================================
  Files           79       83       +4     
  Lines         7679     7964     +285     
===========================================
+ Hits          5413     5594     +181     
- Misses        2266     2370     +104     

codecov[bot] avatar Feb 12 '21 19:02 codecov[bot]

Working on lint and docs as well of course :)

bri3d avatar Feb 12 '21 19:02 bri3d

Unfortunately the 8Devices USB2CAN hardware is not well documented at all. So, this driver is based on the 8Devices Linux SocketCAN kernel module (https://github.com/8devices/usb2can/blob/master/usb_8dev.c) which, while it lives in the 8Devices GitHub organization, itself seems to have been based on a combination of private-thread email lore and reverse engineering.

The USB2CAN from 8 devices https://www.8devices.com/products/usb2can originally has been built by Bernd Krumboeck here: https://github.com/krumboeck/usb2can and I recently made some updates for a out-of-tree compilation on an Linux 5.5 RasPi https://github.com/hartkopp/usb2can.

But all these out-of-tree drivers are not really well maintained so I would suggest to look into the latest mainline Linux driver here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/usb/usb_8dev.c

And you should make sure that the device has the latest v1.7 firmware as you might get problems when restarting the host with a powered USB-Hub otherwise.

hartkopp avatar Jul 15 '21 09:07 hartkopp

I checked the kernel in-tree driver, thanks for the link - it is a lot cleaner than the one in the 8devices repository. The overall message structure of course looks the same, but there are a few more error masks I may be able to use for some more specific backend errors (to the PR comments). So thank you for that! Unfortunately several features which the device seems to support via CANAL on Windows are still not documented/supported in any open source way- namely and particularly, message filtering, so that's a bit of a downer.

That tangent aside, I will address the PR comments later this week. All seems good to address and perfectly reasonable to me - I see that after I asked about more specialized CAN errors, they were indeed added, so happy to support those. And I totally missed the setup.py extras!

bri3d avatar Jul 19 '21 18:07 bri3d

Ping

As a note: Before merging this, the new exceptions should be used (see here).

felixdivo avatar Dec 06 '21 09:12 felixdivo