Using a PXI Express CAN module from a non‑Windows/non‑Linux embedded PCIe host (RTOS)

[k_tana]

Hello,

We are evaluating a setup where an embedded system (acting as a PCIe Root Complex and running an RTOS—not Windows or Linux) connects to a PXI Express chassis via cabled PCIe.
Inside the chassis we plan to use a PXI(e) CAN interface module to communicate with a CAN device under test.

Before we proceed, we would like to clarify:

1) Does your PXI(e) CAN module and driver stack support hosts that are neither Windows nor Linux (e.g., RTOS on an embedded CPU)?
2) If not, is there an OS‑agnostic, register‑level and/or DMA programming interface specification that would allow us to develop our own driver?
3) If non‑PC hosts are not supported, is the recommended architecture to use a PXIe embedded controller (running Windows or Linux) and bridge CAN traffic to our embedded system over Ethernet (e.g., a TCP/UDP or gRPC API)?
4) Are there known constraints for PXI Express remote‑control with custom embedded hosts (e.g., required chipsets, MSI/MSI‑X/ATS expectations, BAR layout, or other PCIe capabilities)?

Environment highlights (no vendor/product names):
- Host: embedded PCIe Root Complex, 64‑bit RISC CPU, RTOS
- Link: cabled PCIe to a PXI Express chassis
- Module: PXI(e) CAN interface (1–2 ch, Classical CAN and CAN FD)
- Goal: transmit/receive CAN frames (with timestamps/filters) up to [your bitrate] kbps

Any guidance, references, or examples of similar deployments would be greatly appreciated.
Thank you!

[ZYOng]

1) Does your PXI(e) CAN module and driver stack support hosts that are neither Windows nor Linux (e.g., RTOS on an embedded CPU)?

No. Only Windows and NI Linux RT. Historically supported Pharlap ETS until 2021.

2) If not, is there an OS‑agnostic, register‑level and/or DMA programming interface specification that would allow us to develop our own driver?

No. There is no register level programming support for NI-XNET hardware.

3) If non‑PC hosts are not supported, is the recommended architecture to use a PXIe embedded controller (running Windows or Linux) and bridge CAN traffic to our embedded system over Ethernet (e.g., a TCP/UDP or gRPC API)?

You may use NI gRPC Device Server and Client APIs. See Supported Languages and Operating Systems for NI Remote-Ability

4) Are there known constraints for PXI Express remote‑control with custom embedded hosts (e.g., required chipsets, MSI/MSI‑X/ATS expectations, BAR layout, or other PCIe capabilities)?

Environment highlights (no vendor/product names):
- Host: embedded PCIe Root Complex, 64‑bit RISC CPU, RTOS
- Link: cabled PCIe to a PXI Express chassis
- Module: PXI(e) CAN interface (1–2 ch, Classical CAN and CAN FD)
- Goal: transmit/receive CAN frames (with timestamps/filters) up to [your bitrate] kbps

NI drivers only support x64 CPU. ARM-based CPUs are not supported.

There is no known host PC configuration that is guarantee to work. Only NI PXIe embedded controllers are guaranteed as NI develops their own BIOS.

[k_tana]

Thank you for the clear guidance.

Based on your answers, we understand that:
- Only Windows and NI Linux RT are supported, with historical Pharlap ETS support until 2021.
- NI-XNET hardware does not expose a register/DMA-level programming interface.
- For non-PC embedded hosts, the recommended architecture is to run the PXIe controller (x64) with NI-XNET and use the NI gRPC Device Server from our embedded RTOS over Ethernet.
- NI drivers target x64 only; ARM-class CPUs are not supported. Only NI PXIe embedded controllers are guaranteed due to NI-controlled BIOS.

Follow-up questions:
1) Do you have a reference/sample for using NI gRPC Device Server with XNET CAN (Classical and CAN FD)—especially for high-rate RX with timestamping and filtering?
2) Are there recommended practices for time synchronization and latency control in a remote setup (e.g., PTP/IEEE 1588, NI-TimeSync, 1PPS in/out)?
3) For capacity planning, what is the typical end-to-end latency and sustainable RX throughput (frames/s) we should expect when using gRPC between the PXIe controller and an embedded device over a 1 Gbps LAN?

Thanks again for your support.

[ZYOng]

1. See https://github.com/ni/grpc-device/blob/main/examples/nixnet/can-signal-single-point-output.py 
2. You need PXI-6683H but unfortunately NI-Sync does not gRPC API.
3. Answer by copilot: NI does not publish NI‑specific gRPC latency/throughput numbers for PXIe controllers, we rely on generic gRPC benchmarks over LAN, which are valid because the transport layer (HTTP/2 over TCP) and serialization overhead (protobuf) are the same. Typical gRPC performance on a 1 Gbps LAN is about 100–200 µs latency per RPC and tens of thousands of messages per second (≈30k–60k unary RPC/s, higher with streaming).

[santo_13]

one can create a grpc-server in any language around the NI-SYNC APIs and expose it over network.