21 多帧传输中的流控状态机：从“死等”到“优雅协商”开篇故事上个月，我帮一个团队排查CAN通信故障。他们的ECU在发送超过8字节的Diagnostic数据时，偶尔会出现“通信卡死”现象——发送方发完第一帧后，接收方既不回复流控帧，也不超时重试，整个诊断会话就这么僵住了。用CANoe抓到的log显示，发送方在等待流控帧时，状态机一直卡在“kWaitFlowControlState”，直到应用层超时（30秒）才强行终止。更诡异的是，同样的代码在另一款MCU上跑得好好的。团队Leader挠着头问我：“难道是CAN控制器硬件差异导致的？”我让他把接收方的流控帧处理代码发给我，一看就明白了——接收方在收到连续帧（CF）后，居然没有检查当前状态是否允许接收，直接就把数据写入了缓冲区。当发送方发完第一帧后，接收方因为缓冲区满，本该回复FC(FlowControl)的Wait状态，却因为代码逻辑错误，压根没发任何流控帧。这就是典型的“流控状态机”实现漏洞。今天我们就来彻底拆解这个隐藏在MultiFrame传输背后的核心机制。痛点拆解常见错误1：把流控当成“可选项”很多初学者的实现是这样的：发送方发完FF（First Frame）后，直接sleep一个固定时间，然后一股脑把剩下的CF发完。# 反例代码：忽略流控的“
