CAN Test

一个面向 Linux 的桌面 CAN / CAN FD 调试工具，使用 Rust + Slint 编写，界面风格接近串口调试助手：左侧扫描接口，中间发送帧，右侧实时监听，下方提供版本说明。

功能概览

• 自动扫描 can* / vcan* / slcan* 接口
• 启动后自检 candump / cansend / ip 是否可用
• 缺少 can-utils 或 iproute2 时，在界面顶部直接提示安装
• 集成 candump 实时监听
• 支持按节点 ID 筛选监听内容，减少无关报文干扰
• 集成 cansend 发送 CAN / CAN FD 帧
• 预留 canbusload 总线负载监控开关，默认关闭
• 支持直接输入完整帧串，例如 024#23011000E0FFFFFF
• 支持按字段拼装 CAN FD 帧，最多 64 字节
• 内置版本说明区域，便于发布时给出简单功能介绍

运行依赖

软件本体是 Rust/Slint 桌面程序，但 Linux 调试行为基于系统里的 can-utils 与 iproute2 命令。

另外，这个程序是 GUI 桌面软件，不是终端程序。即使二进制已经静态链接，也仍然需要目标系统提供图形运行环境：

• 需要在 X11 或 Wayland 桌面会话中启动
• 纯 SSH、纯 TTY、无桌面的 Ubuntu Server、容器 shell 中不能直接打开窗口
• winit 在 Linux 上会在运行时使用 X11 / Wayland 相关系统库

Ubuntu / Debian:

sudo apt update
sudo apt install can-utils iproute2 libx11-6 libx11-xcb1 libxcb1 libxkbcommon0 libwayland-client0

如果这些命令未安装，软件打开后会在顶部显示醒目提示：

未检测到必要命令: candump, cansend, ip。建议先执行 sudo apt install can-utils iproute2

使用方式

1. 准备 CAN 接口

如果当前机器本地没有真实 CAN 设备，也可以先创建一个虚拟 vcan 接口来调试软件界面、发送流程和监听流程。

先执行：

sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
ip link | grep can

正常情况下会看到类似输出：

3: vcan0: <NOARP,UP,LOWER_UP> mtu 72 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/can

这样即使本机没有真实 CAN 硬件，也可以先虚拟创建 vcan0，再打开本软件做本地调试。

然后正常使用 cansend 发送数据测试即可。

如果你已经接了真实 SocketCAN 设备，再继续按下面方式拉起 can0。

针对物理 CAN FD 设备，有时需要先手动拉起接口：

ip link set can0 up type can bitrate 500000 dbitrate 2000000 fd on

检查接口是否存在：

ip link | grep can

2. 启动软件

cargo run

如果是发布后的静态版：

./can-test

注意：

• 请在 Ubuntu 22 桌面会话里运行
• 不要在纯 root shell / SSH shell / 无桌面环境里直接执行
• 如果必须从 root 启动 GUI，通常还需要正确传递 DISPLAY 和 XAUTHORITY

打开后建议按下面流程操作：

1. 点击左侧“刷新”，确认接口列表里有 can0 或 vcan0
2. 点选目标接口后，软件会自动启动 candump 监听
3. 如需只看某个节点，可在“实时监听”里填写十六进制节点 ID 并应用筛选
4. 如需观察总线负载，可打开“总线负载”开关；如果系统装有 canbusload，软件会自动读取接口波特率并开始采样
5. 在“Frame / ID”里输入完整帧串，或只输入 ID 并在 Payload 中填入数据
6. 点击“发送帧”
7. 在监听窗口查看总线回显和设备反馈

如果你当前使用的是虚拟接口，本地联调时可以优先选择 vcan0。

3. 调试示例

文档中的开灯命令可以这样发送：

• 接口: can0
• Frame / ID: 024#23011000E0FFFFFF

或者拆开填写：

• 接口: can0
• Frame / ID: 024
• Payload: 23011000E0FFFFFF
• CAN FD: 关闭
• BRS: 关闭

收到回显时，监听区会看到类似内容：

[RX] can0  024   [8]  23 01 10 00 E0 FF FF FF
[RX] can0  3A4   [8]  60 01 10 00 00 00 00 00

CAN FD 帧格式说明

软件支持两种输入方式。

方式一：直接输入完整帧串

• 普通 CAN: 024#23011000E0FFFFFF
• CAN FD: 123##1AABBCCDDEEFF

说明：

• # 表示普通 CAN
• ## 表示 CAN FD
• ## 后第一个十六进制字符是 FD flags
• 当前程序会在勾选 BRS 时自动写入 1

方式二：分别填写 ID 与 Payload

例如：

• Frame / ID: 024
• Payload: 23 01 10 00 E0 FF FF FF

程序会自动移除空格、点号、下划线、连字符与冒号，并规整成 cansend 可接受的格式。

Linux 构建

仓库默认构建目标是 x86_64-unknown-linux-gnu，采用发行版常见的动态链接方式使用系统库。推荐构建方式：

cargo build --release

构建完成后，产物路径是：

target/x86_64-unknown-linux-gnu/release/can-test

当前仓库里，cargo build --release 会直接生成上面这个 GNU 发布产物。

当前 .cargo/config.toml 已经：

• 将默认构建目标设置为 x86_64-unknown-linux-gnu

说明：

• 这样构建出来的程序会正常依赖目标系统提供的 libc 等运行时库
• GUI 仍依赖 Linux 图形栈环境，建议在目标发行版上做一次实际启动验证

GitHub CI

仓库已经提供 GitHub Actions 工作流：

• 在 ubuntu-22.04 上构建并上传产物
• 在 ubuntu-24.04 上构建并上传产物
• 上传内容包含打包好的 zip 与对应 sha256

工作流文件：

• .github/workflows/build-linux-artifacts.yml

项目结构

can-test/
├── .cargo/config.toml
├── build.rs
├── Cargo.toml
├── README.md
├── src/
│   ├── about.rs
│   ├── app_controller.rs
│   ├── can.rs
│   ├── logging.rs
│   ├── main.rs
│   ├── runtime.rs
│   ├── system.rs
│   └── ui.rs
└── ui/app-window.slint

版本说明页

软件底部保留了“版本说明”区域，当前会展示：

• 软件版本号
• 所用 UI 技术栈
• 监听与发送后端说明
• 当前版本包含的主要能力
• 静态构建建议

后续如果你要对外发布，这一块可以继续扩成：

• 发布说明
• 兼容硬件列表
• 常见问题
• 现场调试注意事项

后续可以继续增强的方向

• 周期发送
• 发送历史和收藏帧
• 解析 ASCII / UDS / 自定义协议字段
• 将 ip link set can0 up ... 做成带参数的引导页