battery_comm.c

源文件路径：midware/bms/alpha/battery_comm.c 所属模块：midware / bms / alpha（ALPHAESS 自有 48V/高压电池 CAN 通信协议实现） 代码行数：2530

1. 文件职责

本文件是 ALPHAESS 自有电池（BMS）与 EMS 主控之间 CAN 总线协议的应用层实现，包含下行控制指令组帧、上行 BMS 状态帧解析、以及电池数据的落地存储三部分。

下行方向：EMS 通过 send_battery_*_cmd() 系列函数，把开关机、重启、MOS 控制、并机 SN 配置、自锁配置、激活时间、SOC 显示范围、能量同步、校时等指令打成 8 字节标准帧/扩展帧发到 CAN0。

上行方向：task_bms（midware/bms/bms.c:2731）在收到 CAN0 扩展帧后调用 alpha_bms_package_parser()，用一个巨大的 switch(id) 把不同 CAN ID 的 8 字节原始数据解码写入全局 g_t_bat_info.t_run_info，供逻辑层（充放电功率限制、故障判断）、HMI 和云平台读取。

数据流位置：CAN0 中断/驱动（hardware/can/can0.c）→ task_bms 轮询 get_can0_exten_pack() → 本文件解析 → g_t_bat_info → logic/、hmi/、net/。同时本文件也反向驱动 CAN0 发送，阻塞式等待应答。

2. 关键数据结构与宏

2.1 本文件定义的数据结构

2.2 本文件使用的宏常量

3. 函数清单

4. 核心逻辑解析

4.1 文件内静态全局

battery_comm.c:32-35 定义了本文件私有状态：

• s_u8_bms_identification_code[8] = {0xFF,0x05,0x02,0x00,0x01,0x03,0x01,0x04}：握手识别码，Battery_Ack() 原样回发，用于排除同一 CAN 总线上多台 EMS 互相干扰。
• s_u32_charge_energy[3] / s_u32_discharge_energy[3]：中值滤波用三点缓冲（历史版本遗留，当前只有 send_battery_set_code_1_cmd() 里的 memset 清零和 #if 0 段的读写）。
• s_u32_send_tick：发送节流时间戳，被 can_send_standard_pack()/can_send_exten_pack() 共享。

alpha_bms_package_parser() 内部另有三个函数级静态变量（battery_comm.c:1106-1109）：s_u32_master_lost_tick、s_u32_bat_activate_time_tick、u_single_sn，它们跨调用保持，是本文件实现"超时降级"和"SN 拼装"的关键。

4.2 CAN 帧格式与收发机制

帧格式：本项目不使用带起始码/长度/校验的串口式协议，而是直接用 CAN 帧承载：29 位扩展 ID 或 11 位标准 ID 作为"命令字"，恒为 8 字节数据域（frame_len），校验由 CAN 控制器硬件 CRC 完成，应用层无额外校验和。

发送路径：所有下行都走两个 static 包装函数（battery_comm.c:52-80）：

can_send_standard_pack()/can_send_exten_pack()
  → if (abs(OSTimeGet() - s_u32_send_tick) < 1) OSTimeDlyHMSM(0,0,0,1);  // 1 tick 内不重复发
  → s_u32_send_tick = OSTimeGet();
  → return can0_send_standard_pack(pack) / can0_send_exten_pack(pack);

响应/超时重试：本文件不做应答等待，全部是"发出即返回"。唯一的特例是 send_battery_cmd() 当 action2 == 0x1e（MOS 通断命令）时连发 3 帧、帧间 OSTimeDlyHMSM(0,0,0,20)（约 20ms），属于冗余发送而非应答重试。调用方通过 (send_xxx() == FALSE) 的返回值判断发送队列是否满，并置位相应的 *_set_flag 以便下一轮重发（见 bms.c:2787-2816）。

主动清缓冲：send_battery_restart_cmd()（162-163）、send_battery_energy_cmd()（630）、send_battery_set_code_1_cmd()（332）在发送前后调用 can0_clear_standard_pack() / can0_clear_exten_pack() 丢弃接收队列中可能堆积的旧帧，避免解析到过期数据。

4.3 下行指令帧字段映射

4.4 alpha_bms_package_parser() 主解析流程

函数入口 battery_comm.c:1088，结构为"三个超时看门狗 + 两类前置处理 + 一个巨型 switch(id)"。

超时看门狗（每帧都会执行）

1. abs(OSTimeGet() - s_u32_master_lost_tick) > 3000 → 清 u_bms_fault_code[0].bit.u8_master_battery_communication_lost。即主机丢失故障位由 ALPHA_BATTERY_GET_OPERATION_STATE_3_ID 帧置位，3 秒内无该帧则自动清除（1112-1115）。
2. abs(OSTimeGet() - s_u32_bat_activate_time_tick) > 3000 → 清 g_system_function_info.t_dev_fun.bms_fun_u.bit.u8_bat_activate_time，表示电池在连续 3 秒内未上报激活时间帧则判定该电池型号不支持此功能（1118-1121）。

欧盟电池法前置处理（1138-1171）

• 若 (id & 0xFFFFF000) == BMS_INFO_GROUP_ID(0x18FF1000)，调用 get_bms_self_info()；首次成功置位 u8_is_get_bms_self_info 并调用 Set_Setup_Config_Extend1_Status(FALSE) 触发云平台配置刷新。
• 一旦 u8_is_get_bms_self_info == TRUE，对 i = 0..BATTERY_MAX_NUM-1 巡检：若当前 tick 距 u_bms_self_info[i].u32BmsCommTick 超过 SENCOND_60S（60 s）且该电池 SN 非空，则清空 t_extend_config_data.battery_basic_info[i]、u_bms_self_info[i]、s_single_sn_splice[i]，并置 bms_self_info_clear_flag = TRUE。这是"电池被拔除后清除其档案"的实现。

switch(id) 主要分支

4.5 单台电池最大充放电功率的型号修正算法

ALPHA_BATTERY_GET_OPERATION_STATE_1_ID 分支中，当 u8_num == 1（单台）时按 bms_get_store_type() 分档修正（1201-1260）：

• ALPHA_M48100_BATTERY_ID / ALPHA_M48112_BATTERY_ID：功率 = 上报值 * 8 / 10（打 8 折）。
• ALPHA_SMILE5 / M4856_P / SMILE5_8 / SMILE5_JP：先算等效电流 上报功率 * 1000 / u16_total_volt；若 > 500（即 0.5C）则钳位为 u16_total_volt * 5 / 10（0.5C），否则用上报值。
• ALPHA_SMILE10_3 / SMILE10_1 / SMILE13_3：同样算法但阈值与钳位系数为 900 / * 9 / 10（0.9C）。
• 其它型号直接用上报值。

多台（u8_num > 1）时不做修正，直接使用 BMS 上报值。

4.6 单体温度/电压明细的分包组装

get_single_cell_temper_info(id, number, data)（940）

• 边界：id > 12 || number > 2 直接返回；u8_cell_temper_number[id-1] > 12 也返回。
• 采样点数 ≤ 6：单帧直接写入 s16_single_cell_temper_sample[id-1][0..count-1]。
• 采样点数 > 6：j = (count%2==0) ? count/2 : count/2+1，把每帧的 j 个点写到 [i + (number-1)*j]，即 number=1 写前半段、number=2 写后半段。
• 每点温度 = (s16)(data[i] - 40)。

get_single_cell_volt_info(id, number, info, data)（995）

• 边界：id > 12 || info > 4 || number > 2 直接返回。
• 每帧 4 组大端 16bit 电压；仅当 u16_cell_volt != 0 才写入（0 视为无效点，保留旧值）。
• 偏移计算：info == 0 → offset = 0；否则 number == 2 → offset = 15；否则 offset = 0。
• 写入位置 u16_single_cell_volt_sample[id-1][info*4 + j + offset]。
• 文件内 982-994 行注释给出了 3.8S 电池 30 串的协议排布表，代码按该表硬编码（注释明确写"每个电池协议都不一样，暂时先按照 3.8s 的写死"）。该偏移分支与注释表存在不一致，见第 7 节。

4.7 激活时间解析的合法性校验

get_battery_activate_time()（908）先把 u8_bat_get_time_info[id] = TRUE、把功能位 u8_bat_activate_time = 1 置上，然后校验 data[4..7]：

年 = (data[4]<<8)|data[5]   月 = data[6]   日 = data[7]
非法条件：年 == 0 || 年 > 2099 || 年 <= 2000 || 月 == 0 || 月 > 12 || 日 == 0 || 日 > 31
非法时写 年=1 / 月=1 / 日=1（占位值，表示"未激活"），否则写实际值

注意年月日的判断用的是 data[4] 起，即跳过 data[0..3]（其中 data[1] 等字段在本文件中未被使用）。

4.8 定时/调度与 uCOS-II 的配合

• 驱动者：task_bms（user/main.c:200 用 OSTaskCreateExt 静态创建，优先级 TASK_BMS_PRIO）。该任务的主循环一次迭代顺序为：bms_get_ready_enable() 判电池是否接入 → bms_comm_detect() 判通信丢失 → 升级判断（优先） → 各种 send_battery_* 下行 → while(get_can0_exten_pack(...)) 批量取扩展帧并逐帧调用 alpha_bms_package_parser()（bms.c:2858-2884）→ 各类后处理。
• 批量收帧的 50ms 上限：while 内每次成功解析后检查 abs(l_u32_bms_recv_tick - OSTimeGet()) > 50 即 break（bms.c:2882-2885），防止 BMS 持续压帧时本任务饿死其它任务。
• 本文件不使用信号量、消息邮箱或互斥量：所有数据交换都通过全局 g_t_bat_info 直接读写，靠"单一写者（task_bms）+ 多读者"的约定保证一致性，没有加锁。
• 阻塞点：send_battery_cmd() 在 action2 == 0x1e 时连续 OSTimeDlyHMSM(0,0,0,20) 两次；send_battery_set_code_1_cmd() 在清能量时 OSTimeDlyHMSM(0,0,1,100)（1.1 秒）；can_send_*_pack() 内部最多延时 1ms。这些都会阻塞 task_bms。
• 10 秒通信超时：由 bms.c 用 l_u32_bms_comm_tick 自己维护，而不是本文件。
• 本文件的周期性：send_battery_set_code_1_cmd() / send_battery_set_code_2_cmd() 由 bms.c:2847-2854 的 abs(OSTimeGet()-l_u32_set_bat_tick) > 1000 条件驱动，即每秒一次（另外清能量标志或 SOC 显示设置标志置位时立即触发）。

4.9 关键全局变量的读写关系

5. 对外接口

5.1 本文件导出（供外部调用）

5.2 本文件调用的外部函数/变量

6. 依赖关系

依赖（battery_comm.c:13-24 的 include 列表）

battery_comm.h → includes.h + bms.h
includes.h
bms.h
meter.h
system_aux.h
inverter.h
can1.h
gd32f4xx_libopt.h
system_config.h
crc.h
sdram.h
ems.h

实际使用到的核心外部资源：CAN_MSG_TYPEDEF_T 与 can0_* 系列（can0.h，经 includes.h 间接引入）、g_t_bat_info / BATTERY_MAX_NUM / BATTERY_SET_SN_TABLE_T / BMS_SINGLE_SN_U（bms.h）、SYSTEM_DATETIME / g_system_function_info（system_config.h）。

被依赖

7. 备注与风险点

1. get_single_cell_volt_info() 的偏移分支与注释表不一致（潜在真实缺陷）。代码 1006-1017：

   if (info == 0)        offset = 0;
   else if (number == 2) offset = 15;
   else                  offset = 0;

info 由 (id - 0x18241101) >> 16 得出，0x18241102（ALPHA_BATTERY_1ID_VOLT_1_INFO_2_AFE）的 info 计算结果为 0，因此走第一分支 offset = 0，把第 2 分包的 4 个单体电压写到 [0..3]，覆盖了第 1 分包已写的数据；按 982-994 行注释表，它应当写到 [15..18]（即第 16~19 串）。其它型号/帧号的组合（info != 0）反而正确。若 3.8S 电池确实按该表逐帧上报，则第 16~19 串电压会读到旧值、第 1~4 串电压被反复覆写。建议改为先判 number 再判 info。

1. 单体电压为 0 时跳过写入（1024）。if(u16_cell_volt != 0) 使得"单体电压确实为 0 mV"与"该点未上报"无法区分，异常电池可能长期保留上一次的旧值。

1. get_single_cell_volt_info 的 number 校验方向不严：判断为 number > 2，number == 0 会通过，虽然当前 id & 0x0F 只会取到 1/2，但缺少下界检查。

1. ALPHA_BATTERY_GET_SINGLE_CELL_VOLT_x_ID 宏疑似漏写一位十六进制。battery_comm.h:80-91 定义为 0x0CF1012、0x0CF1022…，而同族温度帧是 0x0CF1013、0x0CF1023…（7 位十六进制也没问题），但电压帧缺少与温度帧对应的第 8 位。由于解析用的是"与基址做差再右移"的相对算法（1618），所以目前自洽可运行，一旦有人按温度帧的写法"修正"成 0x0CF10120，与 BMS 实际 ID 不匹配即会整族解析失效。

1. send_battery_set_code_c_cmd() 越界风险：533/538 处 s_src_single_sn_splice[(u8_send_sequence_number)*6 + i]，u8_send_sequence_number 无任何范围校验，若为 5 及以上则读到 s_src_single_sn_splice[32] 之外（索引 30、31 尚可，≥32 即越界）。调用方 bms.c 目前保证包号在 0..4，属"调用者约定"型隐患。

1. send_battery_set_brand_cmd() 调试打印引用了不存在的标识符（493、499）：printf("... Brand %d ...", bat_id, brand_code) 中的 brand_code 并不存在于函数作用域（形参名是 brand）。目前因 DEBUG_ALPHA_BAT == 0 未参与编译，一旦打开调试开关会直接编译失败。

1. 多处把联合体按整数格式化输出：如 854 printf("%x", g_t_bat_info...u_bms_protection_code[id]) 把一个 u64 联合体直接传给 %x，属未定义行为；同样只在调试开关打开时暴露。

1. get_battery_alarm_code() 只填 32 位：u_bms_protection_code[id].u64_all = (u32)(...)，高 32 位恒为 0，而 BMS_FAULT_U/BMS_PROTECTION_U 是 64 位联合体，若后续 BMS 协议扩展出 bit32+ 的保护位，此处需要同步修改。

1. get_master_battery_lost() 的循环上界是 i <= u8_num（2265），当 u8_num == BATTERY_MAX_NUM(12) 时访问 u_bms_fault_code[12]；该数组声明为 [BATTERY_MAX_NUM + 1]（bms.h:894）恰好够用，但这是"靠数组多留一个元素"兜住的边界，若 u8_num 被污染成 >12 就会越界（u8_num 在 STATE_1 分支有 <= BATTERY_MAX_NUM 校验，风险较低）。

1. CAN 发送节流用 abs(OSTimeGet() - s_u32_send_tick) < 1（54、72）：两个 tick 相同时延时 1ms。这是"同一次任务迭代内不连发两帧"的写法，但 s_u32_send_tick 由标准帧与扩展帧两个函数共享，可能出现标准帧刚发完、扩展帧被强制等 1ms 的情况，对时序影响可接受但含意不直观。

1. 大量代码被 #if 0 关闭但仍保留在文件中（电池日志 FSM 2287-2469、电量同步 1753-1813、send_battery_self_info_clear_cmd 1043-1079、日志查询指令 693-779），以及 battery_comm.h:412-416 把头文件的三个日志函数声明也注释掉了。这是明确的版本遗留代码：对应的 BAT_LOG_T/BAT_LOG_PACK_T 结构体和 ALPHA_BATTERY_QUERY_LOG_* 宏仍在头文件中有效，容易被误当"可用功能"。

1. g_t_bms_log_buff / g_t_bms_log_pack_buff / g_u8_bat_log_send_flag 的定义也被注释（38-40），与 BAT_LOG_FSM_E 状态机一起构成一组"半删除"的死代码。

1. 无并发保护：g_t_bat_info.t_run_info 由 task_bms 写、被 task_system_logic_control/task_hmi_parse/task_net_app 读，本文件没有任何临界区保护。多字节字段（如 u32_max_charge_power、u16_total_volt）在 32 位 MCU 上虽是单指令访问，但"一组相关字段同时更新"与"读者读到一半"之间仍存在逻辑撕裂窗口。

1. 魔法数字密集：温度偏移 -40、SOC 系数 *4、电流零点 32000（及压缩帧的 127 * 50）、容量除数 6000、0.5C/0.9C 钳位的 500/900、*5/10、*9/10、*8/10 等散落在代码中，没有宏或注释说明来源，修改协议时需要逐处确认。