Check out my first novel, midnight's simulacra!
CANalyst II: Difference between revisions
(kill duplicate text) |
No edit summary |
||
Line 1: | Line 1: | ||
The CANalyst II is an affordable, well-built piece of very Chinese equipment, exposing two [[CAN bus]] bus transceivers to a USB CAN adapter capable of 7k fps, and megabit CAN networks. There is very little English documentation. It appears as USB VendorID 04d8, ProductID 0053 (04d8:0053), the space of [https://www.microchip.com/ Microchip Technology, Inc.]. | |||
==Internals and Interface== | |||
The CANalyst II presents an OPEN5 [https://en.wikipedia.org/wiki/Screw_terminal screw terminal] suitable for mating with a [https://en.wikipedia.org/wiki/D-subminiature DE-9] or [https://en.wikipedia.org/wiki/Data_link_connector_(automotive) ODB-II DLC]. Two CAN channels are supported. | |||
[ | |||
The Chinese manufacturer's site claims that the device is "similar to a [https://www.zlg.com/can/can/product/id/22.html ZLG USBCAN-II+]". What exactly is meant by "similar" here is not yet known. The USBCAN-II+ claims 14Kfps using both channels, which does match the claimed performance of the CANalyst II. | |||
{| class="wikitable sortable" | |||
|- | |||
!Port !! Pin !! Name !! Function | |||
|- | |||
| picture | 1 | CAN_L | CAN_L signal wire terminal | |||
|- | |||
| picture | 2 | R- | Terminal resistance connector (connected to CAN_L internally) | |||
|- | |||
| picture | 3 | SHIELD | Shielded wire terminal (FG) | |||
|- | |||
|4 R+ Terminal resistance connector (connected to CAN_H internally) | |||
5 CAN_H CAN_H signal wire terminal | |||
==Linux== | ==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 [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. | |||
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 | |||
If the <tt>usbserial</tt> kernel module is told to use the | 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. To create a 125Kbps adapter, use something like: | ||
<nowiki>[schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0 | <nowiki>[schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0 |
Revision as of 08:19, 10 June 2019
The CANalyst II is an affordable, well-built piece of very Chinese equipment, exposing two CAN bus bus transceivers to a USB CAN adapter capable of 7k fps, and megabit CAN networks. There is very little English documentation. It appears as USB VendorID 04d8, ProductID 0053 (04d8:0053), the space of Microchip Technology, Inc..
Internals and Interface
The CANalyst II presents an OPEN5 screw terminal suitable for mating with a DE-9 or ODB-II DLC. Two CAN channels are supported.
The Chinese manufacturer's site claims that the device is "similar to a ZLG USBCAN-II+". What exactly is meant by "similar" here is not yet known. The USBCAN-II+ claims 14Kfps using both channels, which does match the claimed performance of the CANalyst II.
Port | Pin | Name | Function | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | CAN_L | CAN_L signal wire terminal | ||||||||||||||||||||
2 | R- | Terminal resistance connector (connected to CAN_L internally) | ||||||||||||||||||||
3 | SHIELD | Shielded wire terminal (FG) | ||||||||||||||||||||
4 R+ Terminal resistance connector (connected to CAN_H internally)
5 CAN_H CAN_H signal wire terminal LinuxThe 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 mcba_usb 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 CanalystII-SocketCAN. The python-can project contains a userspace driver, for which I've 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 usbserial kernel module is told to use the CANalyst II's USB IDs via sudo modprobe usbserial vendor=0x04d8 product=0x0053, it does appear to successfully bring up an SLCAN device, which can then be exposed as a network device using slcand or slcan_attach. The usbserial module will create 6(!) ttyUSB nodes for the CANalyst II. Only the first device seems to have any effect when used with SLCAN. To create a 125Kbps adapter, use something like: [schwarzgerat](0) $ sudo slcand -o -s4 -F ttyUSB0 [6] starting on TTY device /dev/ttyUSB0 [5] attached TTY /dev/ttyUSB0 to netdevice slcan0 The generated net device cannot have its bitrate set using ip, like native SocketCAN devices. Instead, the -s argument must be provided to slcand, using the following table:
lsusb outputusbutils 010, kernel 5.1.8, systemd 241. Bus 001 Device 029: ID 04d8:0053 Microchip Technology, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04d8 Microchip Technology, Inc. idProduct 0x0053 bcdDevice 3.24 iManufacturer 1 Microchip Technology Inc. iProduct 3 Chuangxin Tech USBCAN/CANalyst-II iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0066 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 12 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered |