UDS over LIN实现稳定OTA升级的工程实践-平芜编程栈

1. 这不是“刷个固件”那么简单：UDS+LIN+OTA组合拳的真实战场

你搜“UDS LIN OTA”，页面上全是零散的关键词堆砌、论坛里一句“求个例程”、GitHub上几个没注释的裸机工程，甚至还有人把LIN线当CAN线接——结果烧了三块STM32F103C8T6才搞明白：LIN根本不能靠“串口透传”硬怼。我干汽车电子诊断开发八年，从博世ECU刷写工具链到国产域控制器OTA系统，亲手调通过7种不同MCU平台上的UDS over LIN方案，最深的体会是：这不是协议栈拼接游戏，而是一场对时序精度、错误容忍度和状态机鲁棒性的极限压测。核心关键词——UDS、LIN、OTA、诊断协议、通信——每一个都不是孤立存在：UDS定义“说什么”，LIN决定“怎么传”，OTA解决“传多少、怎么验、断了怎么办”，三者咬合处稍有松动，整套升级就卡在0x7F NRC 0x33（条件不满足）或LIN帧校验失败的死循环里。适合谁看？不是刚学完《嵌入式C语言》的学生，而是正在为某款车灯控制器、座椅调节模块或BMS从属节点设计远程升级能力的工程师；也不是只关心“APP点一下就能升级”的产品经理，而是得亲手改中断服务程序、调波特率容差、拆解UDS 0x31子功能0x01/0x02/0x03逻辑的固件开发者。它解决的不是“能不能升”，而是“升得稳、升得准、升得可追溯”——当整车厂要求OTA失败率低于0.001%，当售后工程师拿着诊断仪连不上LIN节点时，你写的那段LIN帧解析代码，就是第一道防线。

2. 为什么非得用UDS over LIN？绕开这三点，你的OTA就是空中楼阁

2.1 UDS不是“高级串口协议”，而是诊断领域的ISO标准契约

很多人把UDS（Unified Diagnostic Services，ISO 14229-1）当成CAN总线上跑的“增强版AT指令”，这是致命误区。UDS本质是一套强约束的状态机协议，它规定了服务请求/响应的完整生命周期：从0x10会话控制切换、0x27安全访问解锁、0x31例程控制执行擦除、0x34/0x36/0x37数据传输，到0x31子功能0x03验证校验和——每一步都必须严格遵循时序窗口、NRC（Negative Response Code）反馈规则和会话状态依赖。比如0x31服务执行擦除前，必须处于Extended Diagnostic Session（0x03），且安全等级已通过Seed-Key认证；若直接发0x34请求下载，ECU必然返回0x7F 0x31 0x22（条件不满足）。而LIN作为物理层和数据链路层（ISO 17987系列），只负责把UDS报文封装成LIN帧（Header + Response）可靠送达。这就决定了：UDS over LIN不是“把CAN报文改成LIN格式”，而是将UDS服务语义映射到LIN有限的带宽与容错机制上。LIN最大波特率20kbps（实际常用19.2kbps），一帧Header仅6字节，Response最多8字节数据，而一个完整的UDS 0x34请求下载可能需要发送数百帧——这意味着你必须设计分片策略、重传机制和超时恢复逻辑，这些在CAN上由硬件自动处理的部分，在LIN上全得靠软件扛。

2.2 LIN的“单主多从”架构，让OTA升级变成一场资源调度战争

LIN总线天生是主从结构：只有一个Master（通常是BCM或网关），多个Slave（车灯、雨刮、门锁等）。OTA升级时，Master不仅要协调自身任务，还要为Slave节点争取通信窗口。关键矛盾在于：LIN调度表（Schedule Table）是静态预编译的，而OTA过程是动态长周期行为。例如，标准LIN调度表中，某个Slave的响应槽位（Response Slot）可能每100ms才分配一次，每次仅允许8字节数据。但UDS 0x36下载数据块最小单位是128字节（含SID+Subfn+Data），需拆成16帧LIN传输，耗时至少1.6秒——这期间调度表若未预留连续Slot，就会触发LIN错误帧（Sync Error或Checksum Error）。我见过最典型的翻车场景：某车灯厂商用现成LIN库直接跑UDS 0x36，结果升级到72%时总线报错，抓波形发现Master在第5帧后跳到了下一个调度周期，导致Slave响应超时。解决方案不是换芯片，而是重构调度表——在OTA专用Schedule中，为升级节点分配连续10~20个Slot，并插入“OTA Busy”状态标识，禁止其他诊断请求抢占。这要求你深度理解LIN 2.2A规范中的Schedule Designer工具链，而非只调用HAL_LIN_Transmit()函数。

2.3 OTA的“全量包”陷阱：LIN带宽下，压缩与校验必须重新设计

热词里反复出现“ota全量包”“ota zip连接”，但直接把Android APK式的ZIP包扔进LIN总线，等于给蜗牛装火箭发动机。LIN有效载荷率计算如下：

单帧LIN Header：Sync Break（13bit）+ Sync Field（8bit）+ ID Field（6bit）= 27bit，实际占用约3.4字节
单帧LIN Response：Data Field（1~8字节）+ Checksum（1字节）= 最大9字节
按19.2kbps波特率，理论最大吞吐≈19200/(10bit/byte) = 1920 byte/s，但因Header开销、Slot间隔、错误重传，实际可持续速率仅300~500 byte/s。
一个128KB的固件全量包，在理想条件下需升级4~7分钟——这远超用户耐心阈值，更致命的是：长时间通信增大了电源波动、EMI干扰导致帧错误的概率。因此，必须放弃“全量OTA”，转向“差分OTA+本地解压”：

在服务器端用bsdiff生成差分包（delta），体积常压缩至原包5%~15%；
终端MCU收到delta后，用轻量级zlib（如miniz）在RAM中解压，再写入Flash；
校验环节必须分层：LIN帧级用LIN标准Checksum（0x00~0xFF累加取反），UDS层用0x31服务返回的CRC32校验码，应用层用SHA256哈希比对。
我实测过STM32F103C8T6（64KB Flash）跑miniz解压128KB delta包，耗时2.3秒，内存峰值占用仅18KB——这比硬传全量包靠谱十倍。

3. 核心细节拆解：从LIN物理层到UDS服务实现的七道生死关

3.1 LIN物理层与电平适配：别让3.3V和12V互相伤害

LIN总线标称电压12V，但MCU GPIO是3.3V，直接接线必烧芯片。必须用LIN收发器（如TI的SN65HV230、Infineon的TLE7250），其核心作用不是简单电平转换，而是实现LIN规范要求的显性/隐性电平驱动与故障检测。以SN65HV230为例：

TXD输入3.3V TTL电平，内部驱动电路将其转为LIN总线显性电平（≤1.5V）和隐性电平（≥8V）；
RXD输出3.3V兼容电平，但关键在WAKE引脚——当总线检测到大于2.5V持续50μs的唤醒脉冲，WAKE拉高通知MCU准备接收；
更重要的是FAULT引脚：当总线短路、开路或过温时，FAULT拉低，MCU需立即停止发送并进入错误处理流程。
常见坑：有人用普通光耦隔离替代LIN收发器，结果无法识别唤醒信号，或在电磁干扰下误触发FAULT。实操要点：PCB布线时，LIN走线必须远离高频信号（如USB、SWD），长度超过1m需加1kΩ终端电阻（靠近Slave端），收发器GND必须独立于数字地，用磁珠隔离。我调试某座椅控制器时，因LIN线与电机驱动线平行走线30cm，升级中途频繁丢帧，加磁环后问题消失。

3.2 LIN帧结构与UDS报文封装：Header里的ID字段是调度命脉

LIN帧由Header和Response组成，Header包含Sync Break、Sync Field和ID Field。其中ID Field（6bit）决定整个帧的行为：

ID 0x00~0x3F：标准数据帧，对应调度表中预定义的Response Slot；
ID 0x3C/0x3D：诊断帧（Diagnostic Frame），专用于UDS通信；
ID 0x3E：用户定义帧，可用于自定义协议。
UDS over LIN必须使用ID 0x3C（Master Request）和0x3D（Slave Response），因为只有这两个ID被LIN规范明确定义为诊断用途，且调度表中为其预留了专用Slot。封装逻辑如下：
Master发UDS请求：LIN Header ID=0x3C → LIN Response Data=UDS Request Payload（如0x10 0x03）；
Slave收帧后解析UDS SID，执行对应服务 → LIN Header ID=0x3D → LIN Response Data=UDS Response Payload（如0x50 0x03 0x00 0x00）。
关键细节：ID字段的校验位（Parity Bit）由收发器硬件自动生成，但MCU软件必须确保发送的ID值符合LIN规范（如0x3C的奇偶校验位为1）。曾有个项目因ID写成0x3C但校验位算错，Slave始终不响应，示波器抓到Header但无Response——根源在LIN库的ID生成函数未启用硬件校验。

3.3 UDS会话管理与安全访问：0x27服务不是“填空题”，而是密钥博弈

UDS 0x27服务（Security Access）是OTA前的“通关密码”，绝非简单发0x27 0x01再回0x67 0x01。其本质是基于种子-密钥（Seed-Key）的挑战应答机制：

Master发0x27 0x01请求种子 → Slave返回6字节随机Seed（如0xA5 0x3F 0x12 0x88 0x00 0x44）；
Master用预置算法（如XOR+ROT+加盐）计算Key → 发0x27 0x02 + 6字节Key；
Slave用相同算法验证Key，成功则进入安全状态，允许后续0x31/0x34操作。
陷阱在于：算法必须与ECU固件完全一致，且Key计算需在100ms内完成（否则Slave超时重置）。我遇到过最棘手的问题：某供应商提供的Key算法文档缺失“加盐值”，导致量产车无法升级。解决方案是逆向分析Slave固件二进制，找到seed_key_calc函数，提取盐值0x1A2B3C4D。实操建议：在STM32上用HAL_TIM_Base_Start_IT()启动微秒级定时器，Key计算完成后立即发帧，避免HAL_Delay()引入不可控延迟。

3.4 UDS 0x31例程控制：擦除Flash不是“清空硬盘”，而是扇区手术刀

UDS 0x31服务（Routine Control）的子功能0x01（擦除）是OTA最危险环节。LIN环境下，擦除操作必须满足：

原子性：擦除必须在单个LIN帧内完成，不能分片（否则断电即变砖）；
可中断性：需支持0x31 0x03（Stop Routine）随时终止；
状态反馈：擦除中Slave需返回0x78（requestCorrectlyReceived-ResponsePending），完成后返回0x61（routineSuccessfullyCompleted）。
以STM32F103C8T6为例，Flash擦除最小单位是Page（1KB），但UDS要求指定地址范围。正确做法：

收到0x31 0x01 + 地址/长度参数后，先校验地址是否对齐Page边界；
启动独立任务（FreeRTOS Task或裸机状态机）逐页擦除，每擦一页发0x78响应；
擦除中监听LIN中断，若收到0x31 0x03则立即停止并返回0x7E（subFunctionNotSupported）。
血泪教训：曾有团队直接调用HAL_FLASHEx_Erase()擦除整个Sector，结果升级中断时Sector部分擦除，Bootloader无法启动——后来改为按Page擦除，每页后写入状态标记，重启后可续擦。

3.5 UDS 0x34/0x36/0x37数据传输：LIN带宽下的流控艺术

UDS 0x34（Request Download）、0x36（Transfer Data）、0x37（Request Transfer Exit）构成数据传输闭环。LIN限制下，必须重构流控逻辑：

0x34响应：Slave返回最大块长度（MaxNumberOfBlocks），非固定值。需根据剩余Flash空间和RAM缓冲区动态计算，如RAM仅2KB，则设Max=256字节（256/8=32帧）；
0x36分片：每帧LIN Response发8字节UDS数据（含SID+Subfn+Data），需在MCU RAM中缓存完整块再写Flash；
0x37校验：Slave执行0x31 0x03验证写入数据CRC32，成功返回0x67，失败返回0x7F 0x37 0x31（routineFailed）。
关键优化：用DMA双缓冲接收LIN数据，CPU在Buffer A接收时处理Buffer B数据，避免中断频繁打断。STM32F103的USART DMA配置要点：

hdma_usart1_rx.Init.Mode = DMA_CIRCULAR; // 循环模式防溢出 hdma_usart1_rx.Init.Priority = DMA_PRIORITY_HIGH; // 确保实时性 HAL_DMA_Start(&hdma_usart1_rx, (uint32_t)&huart1.Instance->DR, (uint32_t)rx_buffer, RX_BUFFER_SIZE);

3.6 OTA升级状态机：从“开始”到“完成”的17个状态跃迁

LIN OTA不是线性流程，而是复杂状态机。我定义的标准状态机包含17个状态，覆盖所有异常分支：

状态ID	状态名	触发条件	关键动作
S0	IDLE	上电初始化	清空升级标志位，初始化LIN外设
S1	WAIT_WAKEUP	检测到LIN唤醒脉冲	启动定时器等待Header
S2	RECEIVE_HEADER	收到有效Header	解析ID，判断是否0x3C
S3	PARSE_UDS_REQ	收到UDS请求	提取SID，跳转对应服务处理
...	...	...	...
S15	VERIFY_CRC	执行0x31 0x03	计算写入数据CRC32，比对UDS响应
S16	ACTIVATE_NEW_FW	校验通过	设置BOOT_FLAG，触发软复位
S17	ERROR_RECOVERY	任意步骤失败	记录错误码，进入安全模式
最易忽略的状态是S17错误恢复：当LIN通信中断或电源跌落，必须保存当前进度（如已写入的Block数、校验和），下次唤醒后从断点续传。这要求在Flash中划出专用区域（如最后1KB）存储升级日志，用wear-leveling算法避免擦写寿命耗尽。

3.7 Bootloader与Application双区设计：让升级失败也能“一键回滚”

OTA成功的最后一道保险是双区Bootloader。典型布局：

Bank0（0x08000000）：Bootloader区（16KB），永不更新；
Bank1（0x08004000）：Application区（48KB），OTA目标；
Bank2（0x08010000）：Backup区（48KB），存储旧版本。
升级流程：

新固件写入Bank1；
校验通过后，将Bank1内容复制到Bank2（备份）；
更新跳转地址（Vector Table Offset Register）指向Bank1。
关键技巧：用STM32的SYSCFG_MEMRMP寄存器实现Bank切换，无需修改链接脚本。代码片段：

// 切换到Bank1执行 SCB->VTOR = FLASH_BASE + 0x4000; // Bank1起始地址 __DSB(); __ISB(); JumpAddress = *(__IO uint32_t*) (FLASH_BASE + 0x4000 + 4); JumpToApplication = (pFunction) JumpAddress; __set_MSP(*(__IO uint32_t*) (FLASH_BASE + 0x4000)); JumpToApplication();

这样即使Bank1固件损坏，重启后Bootloader可检测到校验失败，自动从Bank2加载旧版，用户无感知。

4. 实操全流程：从STM32CubeMX配置到量产烧录的23步手把手

4.1 STM32CubeMX基础配置：避开80%的硬件坑

第一步不是写代码，而是CubeMX配置。针对STM32F103C8T6的LIN OTA，必须设置：

RCC：HSE=8MHz晶振，PLL配置为72MHz（APB1=36MHz，满足LIN波特率精度）；
SYS：Debug选Serial Wire（保留SWD调试口），Timebase Source选TIM1（高精度定时）；
USART1：Mode选Asynchronous，Baud Rate=19200，Word Length=8 Bits，Stop Bits=1，Parity=None；
DMA：Enable USART1_RX DMA Channel 5，Circular Mode OFF（避免覆盖）；
GPIO：PA9（TX）推挽复用，PA10（RX）浮空输入，PB12（LIN Wake）下拉输入；
NVIC：Enable USART1 Global Interrupt，Preemption Priority=0（最高）。
致命配置项：在USART1的Advanced Settings中，必须勾选“Over Sampling by 16”，否则19200波特率误差超2%（LIN要求<1.5%）。实测：若选Over Sampling by 8，波特率误差达3.2%，导致LIN帧校验失败。

4.2 LIN协议栈移植：从裸机到FreeRTOS的无缝衔接

官方HAL库不提供LIN协议栈，需自行实现或移植第三方。推荐基于AUTOSAR Lite的轻量级LIN库（如lin_stack_v1.2），移植要点：

时钟适配：将库中lin_get_timer_value()指向HAL_TIM_ReadCounter(&htim1)；
中断绑定：在USART1_IRQHandler中调用lin_uart_rx_callback()，解析Header；
FreeRTOS集成：用xQueueSendFromISR()将LIN帧放入队列，Task中用xQueueReceive()处理UDS服务。
关键代码：

void USART1_IRQHandler(void) { HAL_UART_IRQHandler(&huart1); if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { // LIN帧结束标志 __HAL_UART_CLEAR_IDLEFLAG(&huart1); lin_uart_rx_callback(); // 调用LIN库回调 } }

测试方法：用Vector CANoe发送LIN诊断帧，示波器抓PA10波形，确认Header Sync Field（0x55）和ID字段正确。

4.3 UDS服务框架搭建：用状态机代替if-else链

UDS服务不能用巨型switch-case实现，必须用状态机。以0x10会话控制为例：

typedef enum { SESSION_IDLE, SESSION_WAIT_REQ, SESSION_PROCESSING, SESSION_SEND_RESP } session_state_t; session_state_t session_state = SESSION_IDLE; uint8_t session_req[8]; uint8_t session_resp[8]; void uds_session_handler(void) { switch(session_state) { case SESSION_IDLE: if (uds_rx_queue_pop(session_req)) { // 从LIN队列取帧 session_state = SESSION_WAIT_REQ; } break; case SESSION_WAIT_REQ: if (session_req[0] == 0x10) { // SID匹配 session_resp[0] = 0x50; // 响应SID session_resp[1] = session_req[1]; // 会话类型 session_state = SESSION_SEND_RESP; } break; case SESSION_SEND_RESP: lin_send_frame(0x3D, session_resp, 2); // 发送LIN响应 session_state = SESSION_IDLE; break; } }

此结构可无限扩展，添加0x27/0x31服务只需新增状态枚举和case分支，避免代码爆炸。

4.4 OTA升级引擎开发：差分包解析与Flash写入实战

差分包解析是OTA核心。采用bsdiff生成delta包后，MCU端解析流程：

读取delta包头（Magic Number + Old Size + New Size）；
解析Patch Header（Control Block + Diff Block + Extra Block）；
按Control Block指令，从旧固件（Bank2）读取数据，与Diff Block XOR，写入新固件（Bank1）。
关键代码（miniz解压）：

#include "miniz.c" uint8_t *decompressed = malloc(new_size); int ret = mz_uncompress(decompressed, &new_size, delta_data, delta_size); if (ret != MZ_OK) { // 记录错误，进入S17状态 } // 将decompressed写入Flash Bank1 flash_write_page(FLASH_BANK1_START, decompressed, new_size);

实操心得：STM32F103的Flash写入必须按Page（1KB）对齐，且写入前需解锁（FLASH_Unlock()）和清除标志位（__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_PGERR)）。

4.5 全流程联调与量产烧录：从实验室到产线的跨越

联调必须模拟真实场景：

环境：用CANoe模拟Master，STM32板卡为Slave，电源用可编程直流源（模拟12V跌落）；
用例：
1. 正常升级：全程无错误，耗时≤5分钟；
2. 中断升级：在0x36第50帧时断电，重启后自动续传；
3. 错误注入：故意发错误ID帧，验证Slave返回0x7F；
量产烧录：用ST-LINK Utility烧录Bootloader（Bank0），用自研上位机烧录Application（Bank1），上位机集成bsdiff和签名验证。
产线避坑指南：

提示：产线烧录时禁用Bootloader的UART升级功能，防止工人误操作。方法是在Bootloader中检测特定GPIO电平（如PC13按下），仅在此状态下开放UART升级入口。
注意：所有LIN节点必须统一分配ID（0x3C/0x3D），避免调度表冲突。用J-Link Commander批量烧录时，执行mem32 0x08000000 1检查Bootloader首地址是否为有效代码。

5. 常见问题与排查技巧实录：那些让工程师彻夜难眠的LIN OTA Bug

5.1 “LIN帧接收中断不触发”——不是代码问题，是硬件唤醒失效

现象：MCU上电后，LIN总线有信号，但USART1_IRQHandler从不进入。
排查路径：

用示波器测PB12（Wake引脚）：无唤醒脉冲（>2.5V, 50μs）→ 检查Master是否发送唤醒；
有唤醒脉冲但WAKE引脚无反应 → 检查SN65HV230的WAKE上拉电阻（必须10kΩ）；
WAKE拉高但中断不触发 → CubeMX中确认PB12配置为EXTI Line12，NVIC Enable；
EXTI触发但无USART中断 → 检查USART1的CR1寄存器，UE和RE位是否为1。
独家技巧：在EXTI15_10_IRQHandler中加LED闪烁，确认唤醒中断是否生效，比查寄存器更快。

5.2 “UDS响应0x7F 0x31 0x22”——安全访问未解锁的连锁反应

现象：发0x34请求下载，Slave返回0x7F 0x31 0x22（条件不满足）。
根因分析：

未执行0x10会话控制（当前为Default Session）；
或执行了0x10但未通过0x27安全访问；
或0x27 Key计算超时，Slave重置安全状态。
快速定位法：在0x27服务处理函数开头加HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5)，用示波器看LED是否闪烁——若不闪，说明0x27请求未到达；若闪但无响应，检查Key计算时间。

5.3 “升级到85%卡死”——LIN调度表Slot不足的隐性故障

现象：OTA进度条停在85%，LIN总线无错误帧，但Slave不再响应。
本质：调度表中为OTA分配的Slot用尽，Master跳转到其他Slot，Slave等待超时。
抓包验证：用CANoe的LIN Monitor观察ID字段，若在0x3C后长期无0x3D响应，且ID序列跳变，即为Slot耗尽。
解决方案：

用LIN Designer重新生成Schedule Table，为OTA增加20个连续Slot；
在Slave固件中添加调度表版本检查，若版本不匹配则拒绝升级。

5.4 “Flash写入后校验失败”——STM32擦写时的电压陷阱

现象：0x37服务返回0x7F 0x37 0x31（routineFailed），但示波器显示写入成功。
真相：STM32F103在Flash写入时，VDD必须≥2.4V。若用电池供电，电压跌至2.3V，写入数据为0xFF。
实测数据：用万用表监测VDD，当电压<2.35V时，写入失败率100%。
对策：

升级前检测VDD，低于2.5V禁止升级；
用LDO稳压器（如AMS1117-3.3）替代DC-DC，减少纹波。

5.5 “两台电脑UDP通信”类比误区——LIN不是网络协议

热词中“两台电脑udp通信使用网络调试助手”暴露了常见误解：LIN不是IP网络，没有IP地址、端口、路由概念。它更像一条“单向广播总线”，Master发Header，所有Slave监听，仅ID匹配的Slave响应。试图用网络调试助手模拟LIN，注定失败。正确调试工具链：

硬件：Vector VN1630A（LIN接口卡）；
软件：CANoe + LIN Panel，可编辑Schedule Table、发送诊断帧、监控总线负载；
替代方案：用ESP32做LIN Master（需CH340转LIN收发器），运行开源LIN库发送测试帧。

6. 工程师的实战笔记：那些文档里不会写的血泪经验

我在某新能源车企做BMS从节点OTA时，踩过最深的坑是LIN总线的“隐性竞争”。当时12个Slave节点（包括座椅、空调、灯光）共用一条LIN线，OTA升级时，其他节点仍在发送传感器数据（如温度、电压），导致总线负载率超80%，LIN帧错误率飙升。解决方案不是增加Master算力，而是推行“OTA静默协议”：

升级前，Master广播0x31 0x01（Start Routine）通知所有Slave进入静默模式；
静默期间，Slave关闭所有非必要上报，仅响应OTA相关帧；
升级完成后，发0x31 0x02（Stop Routine）恢复常态。
这个协议写进ECU需求文档，成为整车厂验收标准之一。

另一个教训关于“OTA提取器”。热词里“ota提取器app官方下载”暗示很多人想用APP直接升级，但LIN OTA必须通过诊断仪（如VCDS、Launch X431）触发。因为APP走Wi-Fi/蓝牙，到ECU需经网关转换，而网关对LIN诊断帧的转发有严格白名单——未在网关配置表中注册的UDS服务（如0x31子功能0x03），会被直接丢弃。所以，真正的OTA入口永远在诊断协议层，APP只是前端。

最后分享一个小技巧：LIN OTA的进度反馈。用户需要知道“升到哪了”，但LIN带宽不允许实时上报。我的做法是在Slave端每完成10个Block，触发一次“进度事件”，用LIN ID 0x10（用户定义帧）发送2字节进度值（0~100），Master端解析后更新UI。这样既节省带宽，又保证用户体验——毕竟，让用户盯着“升级中...”转圈圈五分钟，和看到“已完成73%”是完全不同的心理感受。