Check out my first novel, midnight's simulacra!
CANalyst II: Difference between revisions
No edit summary |
No edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The CANalyst II is an affordable, well-built piece of very Chinese equipment, exposing two [[CAN bus]] | [[File:CANalystII-above.png|thumb|right|alt=Picture of the CANalyst II from above.|The CANalyst II, an enigma (for now).]] | ||
The Canalyst II is an affordable, well-built piece of very Chinese equipment, exposing two [[CAN 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.]. Both channels come equipped with independently-selectable 120Ω resistors necessary for ISO 11898-2 High-Speed CAN buses (such a resistor should not be used with ISO 11898-3 Reliable CAN buses). It also offers baud rate detection functionality. | |||
== | Note that the manual refers to ohms as euros, which is pretty indicative of the documentation's quality overall. | ||
The CANalyst II presents | |||
I suspect there to be a 16MHz [https://www.nxp.com/products/analog/interfaces/in-vehicle-network/can-transceiver-and-controllers/stand-alone-can-controller:SJA1000T SJA1000] chip inside, but have not verified this. | |||
==Hardware== | |||
[[File:CANalystII-test-setup.png|thumb|left|alt=Wiring diagram for self-test|Wired thusly, the CANalyst II can self-test both channels.]] | |||
The CANalyst II is powered entirely over its USB connection--there is no dedicated input for power. | |||
Upon being powered on, the red PWR LED lights up. The blue SYS LED lights once whenever the OS makes a connection to the device. A self-test capability is included on the device, which will see the blue LED light twice in succession on a successful test. The wiring diagram for the self-test mode can be seen to the left. The CANalyst II presents a senary [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]. | |||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
|- | |- | ||
!Port !! Pin !! Name !! Function | !Port !! Pin !! Name !! Function | ||
|- | |- | ||
| | | rowspan="6" | [[File:6screwterm.jpg|thumb]] || 1 || CAN_H || CAN_H signal wire, channel 0 | ||
|- | |- | ||
| | | 2 || SHIELD || Terminal resistance connector, channel 0 | ||
|- | |- | ||
| | | 3 || CAN_L || CAN_L signal wire, channel 0 | ||
|- | |- | ||
|4 | | 4 || CAN_H || CAN_H signal wire, channel 1 | ||
|- | |||
| 5 || SHIELD || Terminal resistance connector, channel 1 | |||
|- | |||
| 6 || CAN_L || CAN_L signal wire, channel 1 | |||
|- | |||
|} | |||
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. | |||
==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 | [[File:Canalystii-iface.png|thumb|right|alt=Hardware interfaces of the CANalyst II|Business ends of the CANalyst II.]] | ||
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 | 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 | ||
Latest revision as of 02:07, 15 December 2020
The Canalyst II is an affordable, well-built piece of very Chinese equipment, exposing two CAN 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.. Both channels come equipped with independently-selectable 120Ω resistors necessary for ISO 11898-2 High-Speed CAN buses (such a resistor should not be used with ISO 11898-3 Reliable CAN buses). It also offers baud rate detection functionality.
Note that the manual refers to ohms as euros, which is pretty indicative of the documentation's quality overall.
I suspect there to be a 16MHz SJA1000 chip inside, but have not verified this.
Hardware
The CANalyst II is powered entirely over its USB connection--there is no dedicated input for power. Upon being powered on, the red PWR LED lights up. The blue SYS LED lights once whenever the OS makes a connection to the device. A self-test capability is included on the device, which will see the blue LED light twice in succession on a successful test. The wiring diagram for the self-test mode can be seen to the left. The CANalyst II presents a senary screw terminal suitable for mating with a DE-9 or ODB-II DLC.
| Port | Pin | Name | Function |
|---|---|---|---|
 |
1 | CAN_H | CAN_H signal wire, channel 0 |
| 2 | SHIELD | Terminal resistance connector, channel 0 | |
| 3 | CAN_L | CAN_L signal wire, channel 0 | |
| 4 | CAN_H | CAN_H signal wire, channel 1 | |
| 5 | SHIELD | Terminal resistance connector, channel 1 | |
| 6 | CAN_L | CAN_L signal wire, channel 1 |
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.
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 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:
| ASCII Command | CAN Bitrate |
|---|---|
| s0 | 10 Kbit/s |
| s1 | 20 Kbit/s |
| s2 | 50 Kbit/s |
| s3 | 100 Kbit/s |
| s4 | 125 Kbit/s |
| s5 | 250 Kbit/s |
| s6 | 500 Kbit/s |
| s7 | 800 Kbit/s |
| s8 | 1000 Kbit/s |
lsusb output
usbutils 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
