4.8 KiB
AMI 主控 CAN / UART 协议
2026-10-03：本文 v1.0 CAN 输入已停用，当前固件协议见 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：
state[n] = (payload_u32 >> (2*n)) & 0x03
状态定义：0=未知、1=正常、2=故障；收到 3 时按未知处理。字节 4 可放发送方滚动计数，字节 5..7 保留，当前主控不解析。d0～d15 的物理含义沿用 通讯交接文档.md。建议发送周期 20～100 ms。
任一路收到 0x280 都会刷新状态。超过 500 ms 两路均未收到 0x280，主控会将全部 d0～d15 刷为 0（未知）。超过 500 ms 两路均未收到仪表帧时保留最后显示值，但点亮故障状态灯。
3. 主控与 TJC 屏幕串口
USART2 为 9600、8 数据位、无校验、1 停止位。
主控到屏幕使用 ASCII 属性赋值，每条命令后紧跟三个真实 0xFF 字节。例如车速 30 km/h：
64 61 73 68 2E 73 70 65 65 64 2E 76 61 6C 3D 33 30 FF FF FF
屏幕到主控沿用现有 6 字节任务帧：
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 的端到端时延及车辆安全动作。烧录成功也不能替代这些实物测试。