NTCAN Device Drivers and CAN Interface Families
A single esd NTCAN device driver supports more than one CAN interface in most cases due to the technological relationship. For this reason, the operating system-specific installation and configuration instructions of a device driver at esd are usually provided for a complete CAN interface family. Each device driver of a CAN family is assigned a unique signature, which is used in protocol messages etc. to distinguish drivers of different CAN interface families on the same host system, and a device driver name, which follows one of two possible naming conventions. The following diagram gives an overview of the CAN interfaces or boards covered by a CAN family driver, the signatures and device driver names assigned to them.
New and up-to-date! The CAN interfaces of our C402 driver family convince with many features. You can find more information here.
Matrix of supported Operating Systems of the individual Driver Families
Explanation
All esd CAN device drivers require an interrupt. RTX does not support sharing IRQ lines with Windows devices. Therefore, the interrupt line used by the driver must be available for exclusive use by RTX, but can be shared between RTX devices. Finding an exclusive IRQ often requires moving hardware around the system or disabling other Windows devices.
For the PCIe bus, the most trouble-free solution is to use the 402 family because these CAN cards support MSI, which means that interrupts are never shared and the problems described above do not occur.
There is currently no version of this driver family available for this operating system. If you need a driver for this driver family, please contact our sales team.
Information about supported Operating Systems
Windows
- Windows 11 (64-Bit)
- Windows 10 (32-/64-Bit)
Legacy1:
- Windows 9x/ME3
- Windows NT3
- Windows 20003
- Windows XP (32-/64-Bit)3
- Windows Vista (32-/64-Bit)3
- Windows 7 (32-/64 Bit)2
- Windows 8 / 8.1 (32-/64 Bit)2
1 esd no longer provides support and maintenance for operating systems that are classified as "legacy" according to the table above.
2 Microsoft has discontinued support to enable in-house cross-signing of device driver code. Because of this, it is no longer possible to release new or updated device drivers for Windows 7, Windows 8, and Windows 8.1 based systems.
3 All device driver binaries are digitally signed with our SHA2 (EV) code signing certificate and countersigned by Microsoft to support the stringent driver signing requirements for Windows 10. As a result, Windows XP and Windows Vista, which do not support SHA2 kernel mode code signing, are no longer supported by new driver versions.
Drivers for Windows - Differences WDF and WDM
The CAN device drivers for Windows are based either on the older WDM (Windows Driver Model) or the more modern WDF (Windows Driver Foundation). The WDM was introduced with Windows 2000 and further developed in 2006 to the WDF as a robust object-based interface for device drivers based on WDM. The WDF consists of a Kernel Mode Driver Framework (KMDF) and a User Mode Driver Framework (UMDF). All WDF-based CAN device drivers are KMDF drivers.
The KMDF is delivered as a library that is either already part of Windows or installed together with the CAN device driver once per system using a WDF Co-Installer. The WDF-based CAN drivers currently use the KMDF library version 1.9, which has been part of Windows since Windows 7.
A Windows Driver Model (WDM) based device driver already exists for most of the supported CAN hardware. The Windows Driver Framework (WDF) replaces and complements the WDM with the aim of increasing the robustness and security of the driver by providing standard implementations for common event handling tasks in the framework. The major version number of all WDF-based drivers is 4.x.x, while the WDM-based drivers are 3.x.x or 2.x.x.
In addition to this fundamental change in the driver framework, the new driver generation (from 4.x.x) differs from its predecessors in the following technical aspects:
- The internal driver architecture is already prepared for the larger payload (up to 64 bytes) of the CAN FD standard.
- The driver supports power management (standby/hibernation), which is not supported by the 3.x.x WDM drivers.
- CAN data is processed by a high-priority worker thread on a passive level instead of processing in a deferred procedure call (DPC). The advantage is that the DPC latencies caused by a CAN driver are reduced to a minimum and the overall system performance on multicore architectures is improved.
Hardware IDs for PCI, PCIe, PCIe Mini, CPCI, CPCIserial, PMC and XMC
An esd CAN interface connected to the PCI, PCIe, PCIe Mini, CPCI, CPCIserial, PMC or XMC bus can be uniquely identified by the ID pair for the main chip (Vendor ID and Device ID) and a vendor-specific ID pair for the device (Subsystem Vendor ID and Subsystem ID). Each ID is 16 bits long and the vendor and subsystem vendor IDs are assigned by the PCI SIG.
CAN Interface | Vendor ID | Device ID | Subsystem Vendor ID | Subsystem ID | Class / Subclass |
CAN-PCI/200 | 0x10B5 | 0x9050 | 0x12FE | 0x0004 | 0x06 / 0x80 |
CAN-PCI/266 | 0x10B5 | 0x9056 | 0x12FE | 0x0009 | 0x06 / 0x80 |
CAN-PCIe/200 | 0x10B5 | 0x9056 | 0x12FE | 0x0200 | 0x0C / 0x09 |
CAN-PCI104/200 | 0x10B5 | 0x9030 | 0x12FE | 0x0501 | 0x0C / 0x09 |
CPCI-CAN/200 | 0x10B5 | 0x9030 | 0x12FE | 0x010B | 0x02 / 0x80 |
PMC-CAN/266 | 0x10B5 | 0x9056 | 0x12FE | 0x000E | 0x06 / 0x80 |
CAN-PCI/331 | 0x10B5 | 0x9050 | 0x12FE | 0x0001 | 0x06 / 0x80 |
CPCI-CAN/331 | 0x10B5 | 0x9050 | 0x12FE | 0x0001 | 0x06 / 0x80 |
PMC-CAN/331 | 0x10B5 | 0x9050 | 0x12FE | 0x0001 | 0x06 / 0x80 |
PMC-CAN/331 (3,3 V) | 0x10B5 | 0x9030 | 0x12FE | 0x000C | 0x06 / 0x80 |
CAN-PCI/360 | 0x10E3 | 0x0860 | 0x12FE | 0x0000 | 0x06 / 0x80 |
CPCI-CAN/360 | 0x10E3 | 0x0860 | 0x12FE | 0x0007 | 0x06 / 0x80 |
CAN-PCI/400 | 0x10B5 | 0x9056 | 0x12FE | 0x0200 | 0x0C / 0x09 |
CAN-PCIe/400 | 0x10B5 | 0x9056 | 0x12FE | 0x0201 | 0x0C / 0x09 |
CPCI-CAN/400-2 | 0x10B5 | 0x9056 | 0x12FE | 0x0141 | 0x0C / 0x09 |
CPCI-CAN/400-4 | 0x10B5 | 0x9056 | 0x12FE | 0x0142 | 0x0C / 0x09 |
CPCI-CAN/400-4I | 0x10B5 | 0x9056 | 0x12FE | 0x0143 | 0x0C / 0x09 |
CPCI-CAN/400-2-PXI | 0x10B5 | 0x9056 | 0x12FE | 0x0144 | 0x0C / 0x09 |
CPCI-CAN/400-4-PXI | 0x10B5 | 0x9056 | 0x12FE | 0x0145 | 0x0C / 0x09 |
CPCI-CAN/400-4I-PXI | 0x10B5 | 0x9056 | 0x12FE | 0x0146 | 0x0C / 0x09 |
PMC-CAN/400-4 | 0x10B5 | 0x9056 | 0x12FE | 0x04C2 | 0x0C / 0x09 |
PMC-CAN/400-4I | 0x10B5 | 0x9056 | 0x12FE | 0x04C3 | 0x0C / 0x09 |
CAN-PCIe/402 | 0x12FE | 0x0402 | 0x12FE | 0x0401, 0x0402, 0x0403 | 0x0C / 0x09 |
CAN-PCI/402 | 0x12FE | 0x0402 | 0x12FE | 0x0401, 0x0402, 0x0403 | 0x0C / 0x09 |
CPCI-CAN/402 | 0x12FE | 0x0402 | 0x12FE | 0x0401, 0x0402, 0x0403 | 0x0C / 0x09 |
CPCIserial-CAN/402 | 0x12FE | 0x0402 | 0x12FE | 0x0401, 0x0402, 0x0403 | 0x0C / 0x09 |
CAN-PCIeMini/402 | 0x12FE | 0x0402 | 0x12FE | 0x0401, 0x0402, 0x0403 | 0x0C / 0x09 |
CAN-PCI/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
CAN-PCIe/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
CAN-PCIeMini/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
CPCIserial-CAN/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
PMC-CAN/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
XMC-CAN/402-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
CAN-M.2/402-2-FD | 0x12FE | 0x0402 | 0x12FE | 0x1402, 0x1403 | 0x0C / 0x09 |
CAN-PCI/405 | 0x1014 | 0x0156 | 0x12FE | 0x0008 | 0x02 / 0x80 |
Hardware IDs for USB CAN Interfaces
An esd CAN interface connected to the USB bus can be uniquely identified by an ID pair consisting of a manufacturer ID and a manufacturer-specific device ID.
CAN Interface | Vendor ID | Device ID |
CAN-USB/Mini | 0x0AB4 | 0x0001 |
CAN-USB/Micro | 0x0AB4 | 0x0011 |
CAN-USB/2 | 0x0AB4 | 0x0010 |
CAN-USB/3-FD | 0x0AB4 | 0x0014 |
CAN-AIR/2 | 0x0AB4 | 0x0018 |
CAN-CBX-AIR/2 | 0x0AB4 | 0x0019 |
CAN-USB/400 | 0x0AB4 | 0x0400 |
CAN-USB/400-IRIG-B | 0x0AB4 | 0x0401 |
CAN-USB/400-FD | 0x0AB4 | 0x0402 |
CAN-USB/400-FD-IRIG-B | 0x0AB4 | 0x0403 |