CAN Isolated Compatibility
Review the pending Windows, Linux, macOS and browser paths and the DVT evidence required before MallMars publishes a compatibility claim.
The planned host and workflow matrix for CAN Isolated. Every row stays pending until it is tied to a traceable unit, firmware build, host version and retained DVT record.
Host compatibility status
Scroll the table horizontally on a narrow screen.
| Host and path | Intended workflow | Current status | Evidence required before release |
|---|---|---|---|
| Windows · WinUSB/candleLight path | Native USB access through a named application or library. | Not released · DVT pending | Exact Windows build, device VID/PID, firmware hash, signed-driver source, install, capture and recovery record. |
| Windows · SLCAN COM port | Serial-line CAN through a named COM-port application. | Not released · DVT pending | Exact Windows build, USB-serial identity, firmware, baud and CAN bitrate mapping, error and reconnect behavior. |
| Windows · vendor SDK | Vendor driver and SDK integration when the final supplier path requires it. | Not selected · supplier pending | Redistribution rights, installer source, SDK/API version, supported applications, sample code and recovery record. |
| Linux · SocketCAN gs_usb | Kernel CAN network interface for candump, can-utils and compatible applications. | Not released · DVT pending | Distribution, kernel, driver binding, USB identity, firmware hash, bitrate cases, counters and long-run capture. |
| Linux · SocketCAN SLCAN | TTY-backed CAN network interface through slcan tooling. | Not released · DVT pending | Distribution, kernel, serial identity, firmware, serial bitrate, CAN bitrate mapping, error and reconnect record. |
| macOS · backend pending | Local capture through a backend selected after supplier and firmware lock. | Not selected · DVT pending | Supported macOS versions, install and permission path, device identity, backend version, capture and recovery evidence. |
| Browser analyzer | Local raw capture, import and decode workflow without a mandatory cloud account. | Prototype target · release pending | Supported browser versions, connection API and permissions, firmware/driver dependency, file export, error and privacy tests. |
Workflow boundaries
- Classical CAN: planned for the first pilot; CAN FD is not promised.
- DBC: a future workflow may import an authorized DBC, but MallMars does not supply a proprietary vehicle database.
- J1939: raw PGN work does not imply RP1210 compatibility or access to a proprietary diagnostic database.
- CANopen: raw CAN access does not by itself prove EDS/DCF tooling, SDO timeout behavior or PDO configuration support.
- Vehicles and machines: connector shape, nominal bitrate or a plausible frame never proves universal compatibility.
Preparation guides
- Windows driver-path selection;
- Linux SocketCAN setup;
- SLCAN versus gs_usb;
- python-can backend selection;
- SavvyCAN connection paths.
How a row becomes supported
- Lock the supplier, BOM, hardware revision, firmware source and binary hash.
- Name the host, driver or backend, application and test configuration.
- Retain install, send/receive, error, reconnect, long-run and recovery evidence.
- Publish the exact conditions, known limits and evidence identifier.
- Repeat material rows after a hardware, firmware, driver or host update.
No matching row means no claim
Prepare the controlled-bench record, then check the public validation ledger. Do not infer support from a similar adapter name or upstream firmware family.