# AMI 主控 CAN / UART 协议

**2026-10-03：本文 v1.0 CAN 输入已停用，当前固件协议见 [SDC_BMS协议.md](SDC_BMS协议.md)。** 原 `0x180 / 0x181 / 0x280` 仅留作历史记录；UART 和 `0x300` 任务接口仍保留，当前有效性规则以新文档为准。

版本：1.0（2026-09-30）

两路 CAN 功能完全相同，均接收全部仪表/安全状态并可发送任务请求。所有报文均为 11 位标准 ID、Classic CAN 数据帧、Intel/Little-Endian；FDCAN1、FDCAN2 均为 500 kbit/s、87.5% 采样点。

## 1. CAN1 / CAN2：车辆数据与任务请求

### 0x180 仪表快速量（CAN → 主控，8 字节）

| 字节 | 类型 | 信号 | 比例 | 屏幕目标 |
| --- | --- | --- | --- | --- |
| 0..1 | uint16 | 车速 | 0.1 km/h/bit | `dash.speed.val`，四舍五入到 1 km/h |
| 2..3 | uint16 | 高压电压 | 0.1 V/bit | `dash.ts.val`，四舍五入到 1 V |
| 4..5 | int16 | 高压电流 | 0.1 A/bit | `dash.dl.val`，四舍五入到 1 A |
| 6..7 | int16 | 扭矩千分比 | 1 ‰/bit | `dash.mct.val` |

建议发送周期 10～20 ms。主控只把发生变化后的最新值送到屏幕；屏幕串口慢于 CAN 时，中间旧值会被合并丢弃，保证画面跟随最新状态。

示例：`7B 00 B8 0B CE FF F4 01` 表示 12.3 km/h、300.0 V、-5.0 A、500 ‰。

### 0x181 温度量（CAN → 主控，8 字节）

| 字节 | 类型 | 信号 | 比例 | 屏幕目标 |
| --- | --- | --- | --- | --- |
| 0..1 | int16 | 电机温度 | 0.1 °C/bit | `dash.djwd.val`，四舍五入到 1 °C |
| 2..3 | int16 | MCU/逆变器温度 | 0.1 °C/bit | `dash.mcuwd.val`，四舍五入到 1 °C |
| 4..5 | int16 | 最高单体温度 | 0.1 °C/bit | `dash.dtwd.val`，四舍五入到 1 °C |
| 6..7 | - | 保留 | 必须发送 0 | - |

建议发送周期 50～100 ms。

### 0x300 任务请求（主控 → CAN，8 字节）

主控只在收到屏幕合法确认帧后发送。它表示驾驶员/操作员请求，不表示车辆已经执行，VCU 仍须完成状态机和安全互锁判断。

| 字节 | 含义 |
| --- | --- |
| 0 | 协议版本，固定 1 |
| 1 | 任务号：1 八字绕环、2 直线加速、3 高速循迹、4 车检测试、5 EBS 测试、6 手动驾驶 |
| 2 | 请求序号，每次合法请求加 1，0～255 循环 |
| 3 | 来源，固定 1=AMI 屏幕 |
| 4..7 | 主控 `HAL_GetTick()` 毫秒值，uint32，小端 |

任务请求发送到最近 500 ms 内收到过本协议报文的 CAN 口；两路都活跃时发送到两路。如果两路都尚未收到报文，则尝试发送到两路。若 TX FIFO 暂满，任务保留在软件队列中稍后发送。

## 2. CAN1 / CAN2：安全/debug 状态

### 0x280 安全状态（CAN → 主控，8 字节）

字节 0..3 是 16 个 2 bit 状态，`d0` 位于 bit 1:0，`d15` 位于 bit 31:30：

```text
state[n] = (payload_u32 >> (2*n)) & 0x03
```

状态定义：0=未知、1=正常、2=故障；收到 3 时按未知处理。字节 4 可放发送方滚动计数，字节 5..7 保留，当前主控不解析。`d0～d15` 的物理含义沿用 [通讯交接文档.md](通讯交接文档.md)。建议发送周期 20～100 ms。

任一路收到 0x280 都会刷新状态。超过 500 ms 两路均未收到 0x280，主控会将全部 `d0～d15` 刷为 0（未知）。超过 500 ms 两路均未收到仪表帧时保留最后显示值，但点亮故障状态灯。

## 3. 主控与 TJC 屏幕串口

USART2 为 9600、8 数据位、无校验、1 停止位。

主控到屏幕使用 ASCII 属性赋值，每条命令后紧跟三个真实 `0xFF` 字节。例如车速 30 km/h：

```text
64 61 73 68 2E 73 70 65 65 64 2E 76 61 6C 3D 33 30 FF FF FF
```

屏幕到主控沿用现有 6 字节任务帧：

```text
AA 55 01 NN 0D 0A
```

`NN=01～06`。接收器按连续字节流搜索帧头并校验类型、任务号和帧尾，不依赖一次 DMA 回调刚好收到一帧。屏幕上电数据和官方 `bkcmd` 返回不会被误认为任务请求。

## 4. LED 与延迟边界

- PA0/脚 11：运行心跳，每 500 ms 翻转。
- PA1/脚 12：两路均未及时提供仪表量或 debug 状态时点亮；不要求两个接口必须同时连接。
- 两灯默认高电平有效，可在 `ami_app.h` 中切换极性。
- CAN 接收与 UART 收发均为中断/DMA；应用主循环不做阻塞等待。
- 屏幕链路物理上限由 9600 bit/s 决定：一条约 15～22 字节的赋值命令通常占用约 16～23 ms 线速时间。突发多字段更新会依次发送，但每个字段只保留最新值。

## 5. 验证边界

已验证：CubeMX 6.15 生成成功；GNU Arm GCC 13.3.1 Debug/Release 可编译；引脚复用、CAN 位时序和 UART 9600 配置进入生成代码。

未验证：实物芯片具体容量、LED 极性、CAN 收发器、终端电阻、整车实际波特率、屏幕电平、UART 实收发、任务按钮到 CAN 的端到端时延及车辆安全动作。烧录成功也不能替代这些实物测试。