kelong_comm.c

源文件路径：midware/inverter/kelong/kelong_comm.c 所属模块：midware/inverter/kelong（科隆逆变器 CAN 通信协议） 代码行数：2350

1. 文件职责

本文件是 EMS 主控与科隆（Kelong）逆变器之间的 CAN 通信实现主体，承担"EMS 主动轮询 + 参数下发 + 状态回读"的全部双向数据流。它通过 CAN1（11 位标准帧，DLC 固定 8 字节）把 EMS 的调度结果翻译成科隆协议帧下发（开关机命令、DC 充放电功率给定、电池限值/保护参数、并网保护参数 9 帧、安规参数 15 帧），并把逆变器上报的运行数据、安规配置、额定参数、故障告警字解码进全局 g_t_inv_info。文件被 midware/inverter/inverter.c 的 task_inverter 任务以 kelong_inverter_comm() + kelong_inverter_data_check() 两个函数成对调用，是"逻辑调度 → 逆变器执行"这条链路的最后一公里。当云端下发了逆变器固件时，本文件会把主循环整体切换到升级通道，把收发权交给 kelong_upgrade.c 的 kelong_upgrade_handle()。

2. 关键数据结构与宏

3. 函数清单

4. 核心逻辑解析

4.1 通信物理层与帧格式

• 物理层：CAN1，can1_mode_init(8)（kelong_comm.c:242），can1.c 内固定 SJW=3TQ / BS1=16TQ / BS2=4TQ，配合分频 8 得到注释标称的 250 kbps；GPIO 为 PB12(RX)/PB13(TX)，过滤器全通（mask=0）到 FIFO0，中断 CAN1_RX0_IRQHandler 把帧压入 80 深的环形队列 s_t_can1_standard_pack[80]。
• 帧格式：全部为 11 位标准数据帧（CAN_FT_DATA），DLC 固定 8 字节。没有应用层起始码、长度字和校验字——CAN 控制器硬件的 15 位 CRC 即是唯一校验，"命令字"直接由 11 位帧 ID 承担（如 0x184 = 开关机控制）。因此本协议不存在"帧内长度/校验解析"，只有帧 ID 分发。
• 字节序：多字节量一律大端（高字节先发），代码中反复出现 frame_data[0] = (u8)(v >> 8 & 0x00ff); frame_data[1] = (u8)(v >> 0 & 0x00ff);（例：kelong_comm.c:472-479）。32 位量按 <<24|<<16|<<8|<<0 拼四个字节（例：kelong_comm.c:1986-1989 的发电量统计）。
• 无应答重试：常规帧下发不做逐帧 ACK 等待，唯一保障是 CAN_Send_Msg 的 15 ms 发送节流与参数下发前后的整段节奏控制；只有升级协议（kelong_upgrade.c）才有 ACK + 超时重试。

4.2 主循环结构：升级/常规双通道

kelong_inverter_comm()（kelong_comm.c:1355）以 is_inverter_firm_download_finished()（来自 net/inv_download.h）作为总开关，形成两个互斥分支：

if (固件下载完成) {
    if (s_u8_upgrade_flag == FALSE) {   // 首次进入本分支
        s_u8_upgrade_flag = TRUE;
        kelong_comm_init();             // 全量同步标志复位
        u8_inverter_comm_lost_flag = FALSE;
        memset(&u16_pv1_volt, 0, &u8_run_mode - &u16_pv1_volt);   // 清运行数据区
    }
    s_u32_inv_lost_tick = OSTimeGet();  // 升级期间视为在线，不报通讯丢失
    if (kelong_read_upgrade_flag_master() == TRUE) u8_run_mode = cUpdateMaster;
    else if (kelong_read_upgrade_flag_slave() == TRUE) u8_run_mode = cUpdateSlave;
    kelong_upgrade_handle();            // 收发权交给升级模块
} else {
    s_u8_upgrade_flag = FALSE;
    ... 常规发送 + 接收解析 ...
}

关键点：进入升级通道后本文件完全不发常规帧、不解析常规帧，0x181~0x28C 全部让位；s_u32_inv_lost_tick 被每轮刷新，避免升级长阻塞期间误报通讯丢失。g_t_inv_info.t_run_info.u8_run_mode 被写入 cUpdateMaster / cUpdateSlave，供 HMI/云端显示升级中状态。

4.3 常规发送调度与状态迁移

常规通道内部再分两级：握手未完成与握手完成。

阶段 A：握手（u8_ems_inv_idcode_flag == TRUE）

if (OSTimeGet() - u32_ems_inv_idcode_tick > 2000) {   // 2 s 周期
    send_ems_inv_idcode_cmd();                        // 发 0x181 "AlphaESS"
    u32_ems_inv_idcode_tick = OSTimeGet();
}

握手帧唯一作用是被逆变器识别为"AlphaESS 上位机"；收到 0x201 (INV_EMS_IDCODE_PACK) 后（kelong_comm.c:1618）延时 2 s、清 u8_ems_inv_idcode_flag、清通讯丢失标志、调 Set_Setup_Config_Status(FALSE)，然后 fall through 到阶段 B。整个 A 阶段除握手帧外不发任何其它帧，这是协议强制的"先建链再配置"时序。

阶段 B：常规循环（u8_ems_inv_idcode_flag == FALSE），发送顺序固定为：

1. 边沿帧：u8_ems_set_inv_ctrl_command_flag1 → 0x184；..._flag2 → 0x185；u8_ems_set_inv_power_ctrl_mode_flag1 → 0x190；u8_ems_set_inv_bat_limit_power_flag1 → 0x194；u8_ems_set_inv_ctrl_arg_flag1 → 0x195；u8_ems_set_inv_bat_protect_arg_flag1 → 0x1A1。均为"发一帧即清标志"。
2. 周期帧：0x191 每 50 ms（u32_ems_send_inv_ctrl_power_tick1）；0x1A0 每 500 ms（u32_ems_send_inv_bat_run_data_tick1）。
3. 参数批下发（关机→改参→开机）：kelong_comm.c:1453-1606 用一个巨型或判断覆盖了 9 个并网保护标志 + 22 个安规标志（其中 arge、argf 在判断中未包含，见风险点）。命中后执行固定时序：

l_u8_temp_value = s_u8_temp_work_mode;
s_u8_temp_work_mode = 0x01;                    // 强制关机
send_ems_ctrl_inv_command1();                  // 发 0x184 关机（内部再延时 2 s）
... 依次下发 0x1B0~0x1B8 与 0x1D0~0x1DE 中所有被置位的帧 ...
（0x1D0 下发后额外 OSTimeDlyHMSM(0,0,2,0) 再延 2 s）
s_u8_temp_work_mode = l_u8_temp_value;        // 恢复原模式
send_ems_ctrl_inv_command1();                  // 发 0x184 开机
u8_ems_inv_idcode_flag = TRUE;                 // 重新走一遍握手+全量同步

即："并网/安规参数只能在停机态写入"，且改完必须重新握手让逆变器回读全量配置。这一段单次阻塞时间可达 4 s 以上（两次 2 s 延时 + 大量 15 ms 节流的帧），是该模块最大的实时性风险来源。

4.4 CAN_Send_Msg 的发送节流

static u32 s_u32_send_tick = 0;
if (abs(OSTimeGet() - s_u32_send_tick) < 15)  OSTimeDlyHMSM(0, 0, 0, 15);
s_u32_send_tick = OSTimeGet();
return can1_send_standard_pack(TxMsg);

OS_TICKS_PER_SEC = 1000（UCOSII/uCOS-CONFIG/os_cfg.h:51），所以这是 15 ms 最小帧间隔。注意：不足时 OSTimeDlyHMSM(0,0,0,15) 是无条件再等 15 ms（不是补足差额），实际间隔会变成"上次发送 + 15 ms 后 + 15 ms"，属偏保守实现。

4.5 接收解析：switch 分发 + 时间窗

接收在 kelong_comm.c:1612 起：

s_u32_inv_recv_tick = OSTimeGet();                       // 本轮起始时刻
while (get_can1_standard_pack(&l_t_inveter_info) == TRUE) {
    s_u32_inv_lost_tick = OSTimeGet();                   // 每收到一帧刷新在线时刻
    switch (l_t_inveter_info.frame_id) { ... 约 100 个 case ... }
    if (abs(s_u32_inv_recv_tick - OSTimeGet()) > 50) break;   // 单轮最多占用 50 ms
}

即每轮最多连续处理 50 ms 的积压帧，防止 CAN 洪泛时饿死同任务内的其它厂商协议分支（task_inverter 是一个大 for(;;) 依次轮询所有逆变器类型）。

各 case 的解码分组：

4.6 故障/告警码映射

get_error_mapping_table1/2()（kelong_comm.c:102 / 165）是纯位搬运：把静态联合体的 bit.* 逐位赋给 g_t_inv_info.t_run_info 的三个位域。两处特殊处理：

• bms_get_ready_enable() == TRUE 时，先清掉逆变器自报的电池类故障位（bat_ovp/bat_uvp/battery_lose/bat_otp/bat*_ocp/bat*_hw_ocp/bat_reverse/bat_relay_fault）与电池告警位。含义是"有 BMS 时以 BMS 判据为准，不信逆变器的电池判断"。
• battery_stops_running_alarm 无条件清 0，即该告警在 EMS 侧被屏蔽。

注意 s_u_error_mapping_table1/2 是每次收到 0x270/0x271 后整体覆盖的（word.word0..3 四个 16 位字全写），因此逆变器"只发变化位"也不会造成残留。

4.7 版本联动与配置落盘

0x205 帧处理里有两段业务规则（kelong_comm.c:1652-1667）：

1. 从机新版本禁用从机升级：若 u8_slave_ver 前 6 字节 == "V1.010" 且配置位 u8_inv2_app_upgrade_disable == FALSE，则置 TRUE 并请求保存；反之若版本不再匹配且配置为 TRUE 则清回 FALSE。
2. 硬件版本变化记录：u8_hw_ver 与 t_config_data.u8_hw_ver 不同则拷贝并请求保存。

整轮解析结束时（kelong_comm.c:2120）统一 if (l_u8_config_save_flag == TRUE) save_job_post(INVERTER_CONFIG_PAGE); —— 这是攒批落盘：所有"配置变了"的事件只置一个局部标志，循环末尾一次性投递保存作业（INVERTER_CONFIG_PAGE = 4075，来自 data/system_config/system_config.h:27），避免回读帧密集时反复擦写 EEPROM/Flash。

4.8 通讯丢失检测与恢复

if (abs(OSTimeGet() - s_u32_inv_lost_tick) > 15*1000) {         // 15 s
    if (u8_inverter_comm_lost_flag == FALSE) {
        can1_clear_standard_pack();                             // 清空接收队列
        u8_inverter_comm_lost_flag = TRUE;
        kelong_comm_init();                                     // 回到握手态，全量重同步
    }
}

15 s 无任何帧即判定断线：清接收队列（防止恢复后处理陈旧帧）→ 置丢失标志 → 重新执行 kelong_comm_init() 把状态机拉回握手阶段（因为 kelong_comm_init 会置 u8_ems_inv_idcode_flag = TRUE）。这是一条"自动重连"路径。

4.9 kelong_inverter_data_check：下发值计算与触发

入口即短路：if (g_t_kelong_comm_info.u8_ems_inv_idcode_flag == TRUE) return; —— 未握手时不做任何数据检查。

计算四组量：

1. 电池最大充/放电功率：取自 pvcharger_read_bat_max_charge_power()/...dischg_power()，取绝对值后用 t_config_data.u32_dc_rate_charge_power / u32_dc_rate_discharge_power 封顶，放电侧再保底 1000（W）。有变化则更新 t_run_info.u16_dc_max_*_power 并置 u8_ems_set_inv_bat_limit_power_flag1。
2. 工作模式决定：电池未启动 && BMS 未就绪 && 不在升级 BMS → s_u8_temp_work_mode = 0x01（关机）；否则取 t_control_cmd.u8_start_stop。另按 t_run_info.u8_bb_enable 把 relay_n_test_flag / backup_gfci_test_flag / n_pe_short_flag 在 0x01(开)/0x02(关) 之间切换。MPPT 扫描请求 u8_mpptscan_start 被消费后置 u8_ems_set_inv_ctrl_command_flag2 = TRUE。
3. 控制命令变化检测：把 8 个控制位与影子 s_t_run_control_cmd 逐项比较，任一变则整体拷贝并存"模式"，置 u8_ems_set_inv_ctrl_command_flag1。
4. 电池保护参数：电流取 pvcharger_read_bat_max_dischg|charge_current()；放电截止电压 = pvcharger_read_bat_dischg_cut_off_volt() * 92 / 100（留 8% 裕量的魔法数），充电截止电压 = pvcharger_read_bat_charge_cut_off_volt()。随后与 t_config_data 的额定值取"更保守者"（放电电压取下限保护、充电电压取上限保护、电流取小值），并对放电电流保底 100（0.1 A）。有变化则置 u8_ems_set_inv_bat_protect_arg_flag1。
5. 安规与恢复点：u8_safety/u8_safesub 与回读值不一致 → 置 u8_ems_set_inv_safety_arg_flag1；u16_regulation_rate 强制为 6000 → 置 ..._arg_flag2；当安规为 DEFAULT_50HZ / DEFAULT_60HZ 时，把 OVP/UVP/OFP/UFP 恢复点分别设为对应一阶保护值 -100 / +100（0.1 V/0.01 Hz 单位）→ 置 u8_ems_set_inv_grid_protect_arg_flag2。

4.10 与 uCOS-II 任务/时序的配合

• 调用方是 midware/inverter/inverter.c 的 task_inverter（inverter.c:1078-1079），条件编译 INVERTER_TYPE == INVERTER_MAX || KELONG_TYPE 且运行时 get_inverter_type() == KELONG_TYPE。该任务在 OSFlagPend(g_t_fast_dispatch_flag, PEND_LOGIC_CALCULATE_DONE, ..., 20, &err) 之后运行，即被逻辑调度完成事件驱动，超时 20 tick。
• 本文件不使用任何信号量或消息邮箱：与其它任务的全部交互都通过 g_t_inv_info / g_t_kelong_comm_info 这两个全局结构体的字段（在 uCOS-II 中属非原子共享，见风险点）。
• 阻塞点：CAN_Send_Msg 的 15 ms、send_ems_ctrl_inv_command1 的 2 s、0x1D0 后的 2 s、参数批下发整段。这些延时直接占用 task_inverter，期间其它厂商协议（SET / GINLONG / ALPHAESS …）分支都不会被调度。
• 中断侧：CAN1_RX0_IRQHandler（hardware/can/can1.c）通过 OSIntEnter()/OSIntExit() 进入临界区，把帧写入 80 深环形队列；get_can1_standard_pack 在任务侧出队。

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

5. 对外接口

本文件导出（供谁调用）

• void kelong_comm_init(void) — 被 inverter.c:68（inverter_state_init 流程）与本文件内部（断线恢复、升级开始）调用
• void kelong_inverter_comm(void) — 被 inverter.c:1078（task_inverter）调用
• void kelong_inverter_data_check(void) — 被 inverter.c:1079（task_inverter）调用
• KELONG_TABLE_T g_t_kelong_comm_info — 全局定义，经 kelong_comm.h:373 的 extern 对外暴露

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

6. 依赖关系

• 依赖：inverter.h、bms.h、meter.h、logic.h、kelong_comm.h、kelong_upgrade.h、can0.h、can1.h、server.h、inv_download.h、bms_download.h、ems.h、data.h、system_config.h
• 被依赖：
  • midware/inverter/inverter.c（task_inverter 调用 kelong_inverter_comm / kelong_inverter_data_check；inverter_state_init 调用 kelong_comm_init）
  • midware/inverter/inverter.c:3807/3843/3878/3913 的 inverter_read_upgrade_flag_master/percent_master/flag_slave/percent_slave 在 KELONG_TYPE 时转调 kelong_upgrade.c 的对应函数（间接依赖 g_t_kelong_comm_info 所在编译单元）

7. 备注与风险点

1. send_dc_ctrl_inv_power_1 强制 AC 有功下限 50 W（kelong_comm.c:458-461）：前置限幅已允许该值为负（充电），紧接着 if (l_s16_ac_set_actpower < 50) l_s16_ac_set_actpower = 50; 会把停机指令 0 与所有充电指令都改成 +50 W 放电。这极可能是遗留的调试残留或未更新的保护阈值，是单元测试/现场调试必须优先确认的点。
2. l_s16_ac_set_reactpower 恒为 0：变量声明后初始化为 0，其后的限幅分支是死代码，0x191 第 6、7 字节永远发 0。说明无功给定功能未实现。
3. 参数批下发的标志判断不完整：kelong_comm.c:1453-1475 的长条件里包含 u8_ems_set_inv_safety_arg_flag1..flage，缺少 flagf（该帧的置位源在 kelong_inverter_data_check 中也不存在），但批下发体内（kelong_comm.c:1597-1600）却会处理 flagf。若将来有人给 flagf 置位，0x1DE 永远不会被下发（因为外层条件不成立）。
4. 0x202 参数设置结果帧只做空 switch：kelong_comm.c:1627-1644 的内层 switch 只有 case EMS_INV_IDCODE_PACK: break; 和一个 default: break;，没有对下发结果做任何判错或重发。参数是否被逆变器接受完全不可知。
5. 0x220 帧 AC 充/放功率取自同一字节对：kelong_comm.c:1681-1682 中 u32_ac_rate_charge_power 与 u32_ac_rate_discharge_power 都来自 frame_data[2..3]，放电额定功率实际未被区分。需对照科隆协议手册确认是否本应取 [4..5]（该位置被 DC 放电占用）。
6. 巨型阻塞延时会挤占 task_inverter：send_ems_ctrl_inv_command1 内的 2 s、参数批下发中 0x1D0 后的 2 s、以及每次发送 15 ms 节流叠加，单次参数同步可能阻塞任务 4 s 以上。该任务同时承载 SET / GINLONG / ALPHAESS 等所有厂商分支，会连带拖慢它们。
7. memset 用结构体成员地址差计算长度：kelong_comm.c:1372

memset((u8*)&g_t_inv_info.t_run_info.u16_pv1_volt, 0x00, ((u8*)&g_t_inv_info.t_run_info.u8_run_mode - (u8*)&g_t_inv_info.t_run_info.u16_pv1_volt)); 依赖 u8_run_mode 在结构体中位于 u16_pv1_volt 之后（inverter.h:1701 vs 1789，成立），但一旦将来调整结构体成员顺序会产生负长度（转为巨大 size_t），属于高危脆弱写法。

1. 时间戳回绕保护是死代码：kelong_comm.c:1396/1423/1443 的 else if (tick > OSTimeGet()) tick = OSTimeGet(); 永远不会执行——因为无符号加法回绕后 OSTimeGet() - tick 会变成极大值，直接命中第一个 if 分支并立刻发帧。真正的时间戳回绕（约 49.7 天）会导致一帧"提前发送"，影响轻微但逻辑与预期不符。
2. abs() 用于无符号差值：abs(OSTimeGet() - s_u32_send_tick)、abs(s_u32_inv_recv_tick - OSTimeGet()) 等处的实参是 u32，超过 INT_MAX 时传给 int 形参属未定义行为（实践中 ARM 上得到原值或负值），与第 8 点叠加使超时判断在回绕窗口内不可靠。
3. 0x205 版本判定使用字符串前 6 字节 memcmp：u8_slave_ver 为 16 字节缓冲，snprintf(...,10,...) 写入最多 9 字符 + '\0'，memcmp(..., 6) 读的是 "V1.010"，逻辑成立；但"V1.010"作为硬编码的功能开关判决值（禁用从机升级）语义晦涩，且一旦版本命名规则变化就会静默失效。
4. u16_regulation_rate 被无条件强写 6000（kelong_comm.c:2317-2321）：上一轮刚从 0x241 回读该值，下一轮就把本地改成 6000 并回发。若不等于 6000 就会形成"每轮都回写"的稳定帧流，需确认 6000 是否即协议规定的唯一合法值。
5. u16_pvN_cur 反算存在除零风险：kelong_comm.c:1901/1902/1909 中 u32_pvN_power*10/u16_pvN_volt，当逆变器上报 PV 电压为 0（夜间/未接 PV）时发生整数除零。在 GD32（Cortex-M4）上整数除零默认返回 0 或触发 UsageFault（取决于是否使能 DIV_0_TRP），属明确缺陷。
6. 故障告警位被静默屏蔽：get_error_mapping_table2 无条件清 battery_stops_running_alarm，且 bms_get_ready_enable() 时清掉逆变器自报的全部电池类故障。前者无注释解释，可能导致真实告警在 EMS/云端完全不可见。
7. 0x1A0 电池运行数据 500 ms 周期与 0x191 50 ms 周期的节拍基准都存于 g_t_kelong_comm_info，但该结构在文件被多个上下文（kelong_comm_init 被 inverter.c:68 的外部路径调用）无锁访问，若这些调用跨任务则存在竞态。