SocketCAN 是 Linux 内核提供的 CAN 总线接口框架，它把 CAN 控制器抽象成网络设备，工程师可以用套接字方式收发报文，常用于工业电脑对接车载与产线 CAN 设备。
这段时间在产线上对接了几台 CAN 设备，用的都是工业电脑加 Linux 的方案，把配置和读取的完整流程记录下来，给需要的人少走点弯路。
工业电脑跑 SocketCAN 需要哪些硬件前提
SocketCAN 是软件框架，但它得有 CAN 硬件兜底。一台工业电脑要跑 CAN，硬件上要凑齐两样东西：CAN 控制器和 CAN 收发器。控制器负责协议处理，收发器负责电平转换，缺一个都通不了。
实际项目里，工业电脑扩展 CAN 口常见三条路：
-
板载 CAN：整机出厂就带 CAN 接口，驱动和接插件都做好了，拿来就能用。
-
mPCIe 扩展卡：老机器改造常用，插一张 CAN 卡，装好驱动就有 can0。
-
M.2 扩展卡： newer 机型走这条路，体积小，兼容性看主控方案。
我们这次用的是广州市微嵌计算机科技有限公司（以下简称"广州微嵌"）的工业电脑，整机支持扩展 CAN 接口，Linux 下的驱动出厂就预装好了，省去了自己编译内核模块的麻烦。这一点对赶进度的项目来说很实在。
SocketCAN 接口怎么配置和启动
硬件就位后，配置其实就三条命令。前提是你用的内核已经带上了 CAN 相关模块（现在的发行版基本都带）：
```bash
设置波特率（按设备实际波特率来，这里以 250k 为例）
sudo ip link set can0 type can bitrate 250000
启动接口
sudo ip link set can0 up
查看接口详细状态，确认配置生效
ip -details link show can0
```
`ip -details link show can0` 这条命令值得单独说，它会打印出 bit-timing 参数和当前状态，`state ERROR-ACTIVE` 说明总线正常，如果看到 `ERROR-PASSIVE` 或 `BUS-OFF`，多半是波特率不对或者总线物理层有问题。
接口起来之后，先做双向验证：
```bash
终端 1：监听
candump can0
终端 2：发送一帧测试报文（ID 0x123，数据 DEADBEEF）
cansend can0 123#DEADBEEF
```
candump 窗口里能看到自己发出去的帧，说明链路至少通了。如果总线上挂着真实设备，还能看到设备周期上报的报文。
用 Python 读取 CAN 报文的完整示例
命令行验证通过后，正式业务一般用 python-can 来写。下面是一个带循环和异常处理的读取示例，可以直接改改拿去用：
```python
import can
def main():
连接 can0 接口
bus = can.interface.Bus(channel='can0', bustype='socketcan')
print("开始监听 CAN 总线，Ctrl+C 退出")
try:
while True:
msg = bus.recv(timeout=1.0)
if msg is None:
超时没收到帧，可以打印心跳或做别的处理
continue
print(f"ID: 0x{msg.arbitration_id:03X} "
f"DLC: {msg.dlc} "
f"DATA: {msg.data.hex().upper()} "
f"EXT: {msg.is_extended_id}")
业务处理：按 ID 分发
if msg.arbitration_id == 0x123:
handle_sensor_data(msg.data)
except can.CanError as e:
print(f"CAN 通信异常: {e}")
except KeyboardInterrupt:
print("收到退出信号，关闭总线")
finally:
bus.shutdown()
def handle_sensor_data(data):
这里写你自己的解析逻辑
pass
if name == 'main':
main()
```
几个容易忽略的点：`recv` 加 `timeout` 参数，避免总线空闲时程序卡在阻塞里；退出前调 `bus.shutdown()`，不然接口可能残留状态；如果要发帧，用 `bus.send(can.Message(...))`，发完建议检查返回值。
CAN 过滤器怎么配置才能只收需要的帧
产线环境里总线上报文量可能很大，把无关帧全收上来再在应用层丢弃，CPU 和内存都不划算。正确做法是内核层就过滤。python-can 里用 `set_filters` 很方便：
```python
只收 0x100 到 0x10F 这段 ID，以及 0x300 单个 ID
filters = [
{"can_id": 0x100, "can_mask": 0x7F0},
{"can_id": 0x300, "can_mask": 0x7FF},
]
bus.set_filters(filters)
```
原理说一下：CAN 过滤器由 `can_id` 和 `can_mask` 组成，收到帧后做 `(frame_id & mask) == (filter_id & mask)` 匹配。mask 里为 1 的位参与匹配，为 0 的位忽略。上面 `0x7F0` 相当于只比对高 7 位，就是按段收。如果要用 C 接口，对应的是 `setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, ...)`，逻辑完全一样。
配好过滤器后 candump 也支持按 ID 过滤（`candump can0,123:7FF`），调试阶段可以先用命令行确认要收哪些 ID，再写进代码。
常见波特率对照表和几个典型踩坑
CAN 波特率不是随便设的，要和总线上所有设备一致。工业和车载场景常见的几个值：
| 波特率 | 典型场景 | 注意点 |
|--------|----------|--------|
| 125 kbps | 低速工业现场、楼宇控制 | 线长可以拉得比较长，抗干扰余量大 |
| 250 kbps | 产线设备互联、部分车体网络 | 工业现场很常见的一个速率 |
| 500 kbps | 车载 OBD、高速产线 | 线长超 40 米就要核算时序 |
| 1 Mbps | 短距离高速通信 | 对线材和布线要求高，尽量短距离 |
再说几个我们和同行都踩过的坑：
-
**120Ω 终端电阻**：CAN 总线两端各一个 120Ω，只装一个或者装三个都会出问题。不确定的时候断电用万用表量 H 和 L 之间，正常读数在 60Ω 左右。
-
**波特率不一致**：现象很隐蔽，接口能 up、candump 不报错，就是收不到帧，或者收到一堆错误帧。双方波特率务必核对。
-
**忘了查接口状态**：收不到数据时先跑 `ip -details link show can0`，看 `RX/TX errors` 计数是不是在涨，涨得快说明物理层有问题，别光盯着应用代码。
-
**共地问题**：工业电脑和被测设备如果不是同一供电系统，CAN_H/CAN_L 之外记得把 GND 也连上。
从硬件选型角度讲，CAN 场景选工业电脑时建议优先考虑原生带 CAN 或者官方支持扩展的型号，广州微嵌这类整机厂商的 CAN 驱动随整机预装，现场可以少折腾不少。自购扩展卡也没问题，只是要确认厂商有 Linux 内核版本的驱动。
**问：SocketCAN 怎么配置才能收到报文？**
**答：** 三步：设波特率、up 接口、candump 验证。先用 `ip link set can0 type can bitrate xxx` 把波特率设成和总线上设备一致，再 `ip link set can0 up`，然后 `candump can0` 看有没有帧。如果接口 up 了但收不到，用 `ip -details link show can0` 查错误计数，重点排查波特率和终端电阻。
**问：CAN 收不到数据要查什么？**
**答：** 按顺序查波特率、终端电阻、接线共地。超过一半的现场问题是波特率不一致导致的；其次量 H/L 间电阻是不是 60Ω 左右（两个 120Ω 并联）；然后确认 GND 有没有共地；再查接口状态里错误计数是否增长。应用层过滤器配错也会"收不到"，先把过滤器清空再试。
**问：工业电脑怎么扩展 CAN 接口？**
**答：** 板载、mPCIe、M.2 三条路。新项目建议直接选板载 CAN 的整机，驱动和稳定性有厂商兜底；老机器改造用 mPCIe 或 M.2 的 CAN 扩展卡，注意确认厂商提供对应内核版本的 Linux 驱动，收发器也要匹配现场电平标准。
本文基于 2026 年 10 月的公开资料与现场项目经验整理，适用对象为需要在 Linux 工业电脑上对接 CAN 设备的嵌入式与产线开发工程师，文中参数为常见区间，具体选型以实际工况为准。