parallel_can.h

源文件路径：midware/inverter/parallel_comm/parallel_can.h 所属模块：midware/inverter/parallel_comm（并机通信 / CAN 通道） 代码行数：70

1. 文件职责

本文件是 EMS 并机 CAN 通道的协议字典：它把"主机 → 从机"和"从机 → 主机"两个方向上全部使用的 CAN 扩展帧 ID 用宏一一枚举出来，并定义了广播地址（0）与扩展 ID 的通信标识位。业务层（parallel.c）把要下发的功率指令写进 g_t_host_machine_running_info[] 字段；通信层（parallel_can.c）按本文件给出的 ID 逐帧组包发出，并在收帧时用 frame_id & 0xFFFFFF 反查这些 ID 决定拆包到哪个字段。因此本文件是"字段 ↔ CAN ID"映射的唯一权威来源，改任何一个宏都会同时影响发送与接收两侧。本文件只做宏定义与两个函数声明，不含代码，被 parallel.c（包含本头以使用 PARALLEL_MAX_NUM 相关的 CAN 语义）与 parallel_can.c 使用。

2. 关键数据结构与宏

3. 函数清单

本文件为纯头文件，不含任何函数定义，仅有 2 个函数声明：

两个函数均由 midware/inverter/parallel.c:1037/1041 在 parallel_can_comm_handle() 内按 u8_parallel_mode 分发调用。

4. 核心逻辑解析

本文件无执行代码，其"逻辑"是CAN 扩展帧 ID 的位域复用规则与收发 ID 的对称/不对称关系。

4.1 扩展 ID 的位域划分

结合 parallel_can.c:57-58（发送）与 parallel_can.c:335-340（接收）可还原出 29 位扩展 ID 的实际用途：

bit28      : 并机报文标志，恒为 1（= PARALLEL_COMMUNICATION_ADDRESS_OFFSET 0x10000000）
bit24-27   : 机器地址（send_id & 0xF），主机发时为 0（广播）或从机地址 i（单播）
bit0-23    : 基础 ID，取本文件定义的 0x181 / 0x190 / ... / 0x2C0

发送侧 parallel_can.c:57-58：

TxMsg->frame_id |= PARALLEL_COMMUNICATION_ADDRESS_OFFSET;   // 置 bit28
TxMsg->frame_id |= (send_id & 0xF) << 24;                   // 置 bit24-27

接收侧 parallel_can.c:335-337：

l_u8_parallel_comm_rx_addr = ((frame_id >> 24) & 0xF);                    // 取位 24-27
if (((frame_id & PARALLEL_COMMUNICATION_ADDRESS_OFFSET) == FALSE) ||      // bit28 必须为 1
    (l_u8_parallel_comm_rx_addr >= PARALLEL_MAX_NUM))  continue;          // 地址必须 < 16

之后用 frame_id & 0xFFFFFF 取基础 ID 做 switch 分派（parallel_can.c:345、parallel_can.c:369、parallel_can.c:776）。注意 & 0xFFFFFF 只保留 bit0-23，因此 bit24-27 的地址与 bit28 的标志被同时剥离，这是位域划分能成立的前提。

4.2 收发 ID 的对称关系

三类不对称/空洞可直接从宏定义与实现对照看出：

1. 0x201 是双向复用但语义相反：主机侧定义 PARALLEL_HOST_MACHINE_NETWORKING_0X201（远程帧请求），从机侧定义 PARALLEL_FROM_MACHINE_NETWORKING_0X201（数据帧应答），两个宏值相同。接收侧靠 frame_type == CAN_FT_REMOTE 区分（parallel_can.c:352、parallel_can.c:783）。
2. 0x181 的方向注释是错的：宏名叫 PARALLEL_HOST_MACHINE_NETWORKING_0X181（"主机"），但它在 parallel_can.c:779（从机侧接收 switch）和 parallel_can.c:347（主机侧接收 switch，注释写"多主机"）里都出现在接收分支。实际方向是"主机 → 从机"的地址分配答复，所以名字里的 HOST 表示"由主机发出"，而 0x201 的 HOST/FROM 两个宏则表示"主机请求 / 从机应答"——命名体系不自洽。
3. 0x202（返回数据出错信息）、0x267（从机逆变器运行信息）、0x240（从机并网参数）三个宏全工程无使用。0x262（PV 充电器 PV/电池功率）主机侧有解析（parallel_can.c:397）但从机侧从不发送。这五处构成"定义了协议但未实现"的空洞。

4.3 载荷格式约定（无长度冗余）

从 parallel_can.c 的组帧可见所有并机 CAN 帧都是固定 8 字节数据域（frame_len = 8），无长度字段、无功能码：字段语义完全由 ID 决定，字段排列为大端（>> 8 高字节在前，>>24/16/8/0 四字节大端）。这一约定由 hardware/can/can1.h 的 CAN_MSG_TYPEDEF_T（frame_id / frame_type / frame_len / frame_data[8]）承载，本文件不重复定义结构体。

校验上分两类：

• 组网帧（0x201 / 0x181）带 CRC8/MAXIM：第 8 字节为前 7 字节的 GetCrcCode_8_MAXIM()（parallel_can.c:152、parallel_can.c:527、parallel_can.c:92-96、parallel_can.c:542-546）。
• 数据帧不带应用层校验：完全依赖 CAN 控制器自身的 CRC 与 ACK 机制，因此 0x190~0x2C0 的载荷没有校验字段。

5. 对外接口

5.1 本文件导出

• 宏：PARALLEL_BROADCAST_ADDR、PARALLEL_COMMUNICATION_ADDRESS_OFFSET，以及"主机 ID 段"12 个（0x181、0x201、0x190~0x197、0x19A、0x19B、0x1C0）和"从机 ID 段"18 个（0x201、0x202、0x220、0x240、0x260~0x26A、0x290、0x2A0~0x2A2、0x2C0）。
• 函数声明：parallel_can_comm_host_machine_handle、parallel_can_comm_from_machine_handle。
• 导出方式为无 #include 条件的裸宏，任何包含本头的文件都会看到全部 ID。

5.2 使用方

5.3 本文件依赖

• #include "chip.h" —— 提供 u8/u16/s16/s32 基础类型。本文件本身没有使用这些类型（只有宏与两个 void 函数声明），因此这个 include 在头文件层面是冗余的，实际是被 .c 顺带获得的。

5.4 相关但不在本文件的外部符号

parallel_can.c 使用了以下不在本头文件声明的符号：

6. 依赖关系

• 依赖：chip.h（且是冗余依赖，见第 7 节）。
• 被依赖：
  • midware/inverter/parallel_comm/parallel_can.c（唯一重度使用者）
  • midware/inverter/parallel.c（仅用于调用两个入口函数）
  • 间接受影响：midware/inverter/inverter.c（通过 task_inverter_can → parallel_can_comm_handle()）

7. 备注与风险点

1. 三个宏定义后从未使用（死代码）：
   • PARALLEL_FROM_MACHINE_DATA_CHECK_0X202（第 37 行）——"返回数据出错信息"，全工程仅有此一处定义，无发送方也无接收方。协议层预留但未落地，或已被数据帧的隐式 CRC 取代。
   • PARALLEL_FROM_MACHINE_INVERTER_RUNNING_DATA_0X267（第 50 行）——主机侧接收 switch（parallel_can.c:369-479）中没有 0x267 分支，从机组帧（parallel_can.c:664-761）也不发 0x267。ID 被跳过。
   • PARALLEL_FROM_MACHINE_SAFETY_REGULATION_0X240（第 41 行）——注释是"从机并网参数"，但实际方向是主机用 0x19B 下发给从机，从机从不回报安规。这个 ID 的存在会让读者误以为有从机安规上报通道。

1. 0x262 只收不发，形成"孤儿接收分支"：parallel_can.c:397-402 会解析 0x262 帧填充 s32_Ppv_pvcharger / s32_Pbat_pvcharger，但 parallel_can.c:664-761 的从机发送逻辑没有任何一帧使用 0x262。同时 parallel.c:209-210 把本机的这两个字段硬置 0，说明该数据源在 CAN 通道上事实上不可用。

1. 0x201 双向复用导致头文件命名误导。PARALLEL_HOST_MACHINE_NETWORKING_0X201（第 21 行，注释"主从机组网帧(远程帧)"）与 PARALLEL_FROM_MACHINE_NETWORKING_0X201（第 36 行，注释"主从机组网帧(数据帧)"）是同一个 ID。任何按名字判断"哪一个 ID 是主机发的"的读者都会误判方向；区分只能靠 frame_type。同理 0x181 被归在"主机 CAN ID"段却由主机发出、从机接收，命名与语义方向不一致。

1. 缺少"从机数据帧无校验"的一致性说明。组网帧带 CRC8/MAXIM，数据帧不带；本头文件对 ID 的注释只描述内容不描述校验，读者必须读 parallel_can.c 才能发现这个差异。建议在头文件里对两类帧明确标注校验方式。

1. PARALLEL_COMMUNICATION_ADDRESS_OFFSET 与地址掩码的耦合未文档化。0x10000000 的注释只写"通讯地址偏移"，没有说明它是"并机报文标志位"以及"地址在 bit24-27"这一分层。收帧侧如果只写 frame_id & 0xFFFFFF 而不先检查 bit28，就会把其它模块发的 0x190 等 ID 误判为并机帧——parallel_can.c:336 恰好有这个检查，但规则未在头文件中固化，新增收发点容易遗漏。

1. 头文件包含 chip.h 但自身不需要。本文件通篇只有宏和两个 void f(void) 声明，不依赖 chip.h 的任何类型。该 include 会让任何只想要 ID 宏的文件被迫引入整个 chip.h，增加编译耦合与循环包含风险。

1. ID 空间未做区间保护。0x1C0（主机 EMS 上报）与 0x2C0（从机 EMS 上报）相距 0x100，看起来是"主机段 0x1xx / 从机段 0x2xx"的划分，但 0x201 同时出现在两段（第 21 行与第 36 行），破坏了这一规律。若将来需要按段批量过滤（例如只接收 0x2xx），会因为 0x201 而被误伤。