CANalyst II

Line 2:

==Linux==

The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN].

The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN]. The [https://python-can.readthedocs.io/ python-can] project contains a userspace driver, for which I've [https://github.com/hardbyte/python-can/pull/617 recently submitted patches] (it wasn't working when my Canalyst II arrived). This allows a Python program to use the device, which is nice, I guess.

If the <tt>usbserial</tt> kernel module is told to use the Canalyst II's USB IDs via <tt>sudo modprobe usbserial vendor=0x04d8 product=0x0053</tt>, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using <tt>slcand</tt> or <tt>slcan_attach</tt>. The <tt>usbserial</tt> module will create 6(!) <tt>ttyUSB</tt> nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN.

==lsusb output==

CANalyst II: Difference between revisions

Dank (talk | contribs)

@@ Line 2: / Line 2: @@
 ==Linux==
-The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN].
+The Linux kernel's preferred way to drive CAN adapters is via SocketCAN, which presents the device as a network interface. There does not appear to be a SocketCAN driver for the Canalyst II as of 2019-06-10. The <tt>mcba_usb</tt> driver, recompiled to use the Canalyst II's USB ID, definitely does *not* work. I'm planning to write a kernel driver; the GitHub project is [https://github.com/dankamongmen/CANalystII-SocketCAN CanalystII-SocketCAN]. The [https://python-can.readthedocs.io/ python-can] project contains a userspace driver, for which I've [https://github.com/hardbyte/python-can/pull/617 recently submitted patches] (it wasn't working when my Canalyst II arrived). This allows a Python program to use the device, which is nice, I guess.
+If the <tt>usbserial</tt> kernel module is told to use the Canalyst II's USB IDs via <tt>sudo modprobe usbserial vendor=0x04d8 product=0x0053</tt>, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using <tt>slcand</tt> or <tt>slcan_attach</tt>. The <tt>usbserial</tt> module will create 6(!) <tt>ttyUSB</tt> nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN.
 ==lsusb output==