CAN系列 — (6) CAN FD 带宽、CPU、中断：工程上是如何一起算的？

CAN系列 --- (1) 一帧 CAN 报文在 ECU 中的完整生命周期
 CAN系列 --- (2) CAN 接收中断是如何触发的？一帧一中断真的合理吗？
CAN系列 --- (3) Radar Object List 在 MCU 内部是如何被拼装、校验并最终被消费的？
CAN系列 --- (4) Radar Header 报文：为什么它是 MCU 感知周期的"锚点"
CAN系列 --- (5) COM / PduR / CanIf 的职责边界：为什么它们不能互相越界
 CAN系列 --- (6) CAN FD 带宽、CPU、中断：工程上是如何一起算的？
CAN系列 --- (7) Alive、Counter、Timeout：CAN 报文里的功能安全不是"多几个字段"
CAN系列 --- (8) 为什么 Radar Object List 不适合"直接走 CAN 信号"

在很多 CAN 项目里，带宽、CPU、中断通常是三本分开算的账，甚至有时只算其中一本。

但在毫米波雷达这种 周期性、成批、强实时 的数据源面前，这三本账往往会在同一个时间窗口内同时被拉满。

这一篇，我们不讨论"怎么优化"，而是先把一个工程上最容易被忽略的问题讲清楚：

CAN FD 的发送负载、MCU 的接收中断、以及周期性 Object 处理，到底该怎么算，才能算对？

1. 工程背景设定

在开始算之前，必须先把工程假设说清楚，否则所有结论都没有意义。

1.1 Radar 侧（发送端）设定

项目	数值	说明
Radar 输出周期	50 ms	主流量产毫米波雷达
每周期 Object 数	64	常见上限
CAN FD Payload	64 Bytes	满载
每帧承载 Object 数	4 个	与前文保持一致
Object List 帧数	16 帧 / 周期	64 ÷ 4

一个非常重要但经常被忽略的事实是：

Radar 并不是在 50 ms 内"均匀地"发送 16 帧，
而是通常在一个很短的窗口内"成簇"发完。

这点会直接影响 MCU 的中断和 CPU 行为。

1.2 系统级假设：5 个 Radar 并发

在中高阶 ADAS / 自动驾驶 ECU 中，一个非常典型的配置是：

前向 Radar × 1
角 Radar × 4

因此本文统一假定：

系统中同时存在 5 个 Radar，它们共享同一条 CAN FD 总线。

2. 发送侧视角：Radar 在总线上真正"占用"了什么？

这一部分，只回答一个问题：

CAN FD 总线，是否扛得住？

2.1 一帧 64B CAN FD 报文占用多少时间？

假设工程常见配置：

Arbitration Phase：500 kbps
Data Phase：2 Mbps
标准 ID

（1）数据段时间

复制代码

64 Bytes × 8 = 512 bit
512 / (2 × 10⁶) = 256 μs

注：通信速率使用 十进制 Mbps（10⁶），不是 1024 体系。

（2）仲裁段 + CRC + 控制字段

工程经验值（含 Stuff Bit）：

text 复制代码

≈ 60 μs

（3）帧间隔（IFS）

复制代码

≈ 10 ~ 15 μs

（4）单帧总时间

复制代码

≈ 256 + 60 + 15 ≈ 330 μs

工程经验结论：一帧 64B CAN FD ≈ 300 ~ 350 μs

2.2 单个 Radar 的 CAN 占用率

每个 Radar 每周期发送：

复制代码

16 帧 × 330 μs ≈ 5.28 ms

Radar 周期是 50 ms，因此：

复制代码

单 Radar CAN 占用率 ≈ 5.28 / 50 ≈ 10.6%

2.3 5 个 Radar 的总线占用

复制代码

5 × 10.6% ≈ 53%

这是一个非常典型的量产级结果：

总线负载 ≈ 50%
有余量，但并不宽松
其他 ECU 的 CAN 报文必须被严格控制

这也解释了为什么在实际项目中：

Radar Object List 基本只跑 CAN FD
不可能再"顺手"加大量调试报文

3. 接收侧视角：MCU 真正承受的中断压力

关键点来了：

Radar 的输出周期是 50 ms，

但 MCU 接收到的并不是"平滑的 50 ms 数据流"。

3.1 MCU 接收到的是"突发帧簇"

在真实系统中，常见行为是：

Radar 在 1~2 ms 内
连续发完 16 帧 Object List
接下来 40 多 ms 基本没有 Object 数据

也就是说：

平均速率不高，但瞬时压力很集中。

3.2 一帧一中断的接收情况

单 Radar：

复制代码

16 帧 / 50 ms
⇒ 320 帧 / 秒
⇒ 320 次 Rx 中断 / 秒

5 个 Radar：

复制代码

320 × 5 = 1600 次 Rx 中断 / 秒

这个数字并不小，而且是：

稳定存在
与 Radar 周期强相关
容易和应用层计算叠加

3.3 使用 FIFO + Watermark 后的中断负载

假设：

Rx FIFO Watermark = 4 帧

那么：

复制代码

单 Radar：320 / 4 = 80 次 / 秒
5 Radar：80 × 5 = 400 次 / 秒

这一数量级，才是 MCU 长期稳定运行更合理的区间。

这不是"性能优化"，而是系统节奏管理。

4. CPU 视角：Object List 是"周期性脉冲负载"

4.1 Object 处理负载并没有因为 50 ms 变小

每个 Radar：

Object 数：64
单 Object 基础处理：≈ 15 μs

text 复制代码

64 × 15 μs ≈ 1.0 ms / Radar / 周期

5 个 Radar：

text 复制代码

≈ 5 ms CPU / 50 ms
⇒ 平均 CPU ≈ 10%

4.2 真正危险的是"周期边界对齐"

如果多个 Radar：

Object List 接收时间接近
Header 触发处理几乎同时发生
感知 / 融合任务同步唤醒

那么 MCU 看到的将是：

在某些 50 ms 边界，
CPU 突然出现 4~6 ms 的集中计算峰值。

这正是：

Watchdog 抖动
实时任务延迟
"偶现卡顿、难复现问题"

的典型根源。

5. 把三本账放在一起，才是工程结论

现在我们把结果汇总在一起：

维度	数值（5 Radar）
CAN 总线占用率	≈ 53%
Rx 中断（无 FIFO）	≈ 1600 次 / 秒
Rx 中断（FIFO=4）	≈ 400 次 / 秒
CPU 平均负载	≈ 10%
CPU 峰值负载	周期边界显著抬升

真正的工程问题不是：

"平均值高不高？"

而是：

"这些压力会不会在同一个时间窗口内叠加？"

6. 总结

如果你只记住这一篇的一句话，那就是：

Radar 周期拉长，只会降低平均负载，

不会自动消除 CAN、中断和 CPU 的瞬时压力。

而成熟的工程分析方式是：

发送侧算总线占用率，

接收侧算中断密度和突发性，

应用层算周期性 CPU 峰值。