单总线脉冲通信接收器代码实现及现有代码问题排查

协议回顾 #

采用脉冲的单总线通信协议规则：

• 发送端每3秒发送一次数据
• 单个bit的周期为10ms：
  • 10ms内总线持续低电平 → 代表数据0
  • 10ms内高电平持续6ms（剩余4ms为低电平）→ 代表数据1

现有代码 #

void pulse_comm_handle(void)
{
    uint8_t stream[30];

    memset(stream, 0xFF, 30);
    p.change_time = GetSysTickMs();

    uint16_t i = 0;
    uint8_t flag = 0;
    while (i < 30)
    {
        if (flag == 8)
        {
            flag = 0;
            rt_kprintf("%d\n", stream[i]);
            i++;
        }
        
        if (rt_pin_read(p.pin) == 0 && GetSysTickMs() >= p.change_time + 10)
        {
            p.change_time = GetSysTickMs();
            stream[i] &= ~(0x80 >> flag);
            flag++;
        }
        
        if (rt_pin_read(p.pin) == 1 && GetSysTickMs() > p.change_time  + 3)
        {
            flag++;
            p.change_time  += 10;
        }
    }

    pulse_flag = 0;
}

代码问题分析 #

• 死循环阻塞系统：函数通过while(i<30)全程轮询引脚状态，会独占CPU资源，若通信中断或引脚异常，会一直卡在循环中，完全破坏嵌入式系统的实时性。
• 数据1的判断逻辑完全不符合协议：协议要求数据1是10ms周期内高电平持续6ms，但代码仅判断高电平持续3ms就认定为数据1，阈值错误；同时没有验证高电平是否维持到6ms，也未处理后续4ms的低电平阶段，会导致时间基准混乱。
• 数据0的判断不严谨：仅判断10ms后引脚为低就认定为0，但未校验这10ms内是否全程为低电平，若存在短暂高电平干扰，会直接误判。
• 时间基准维护错误：处理数据1时直接用p.change_time +=10更新时间，而非读取当前SysTick值，会累积时间误差，导致后续所有bit的判断偏差越来越大。
• 无帧同步机制：未处理帧起始信号，无法识别一帧数据的开始，可能从任意bit位置开始接收，导致整帧数据错误。
• 无超时退出逻辑：若发送端停止发送或通信故障，函数会永久卡在while循环中，无法退出并重置状态。
• bit赋值逻辑存在隐患：处理数据1时未对stream[i]做任何赋值（依赖初始的0xFF保持1），但如果时间判断错误导致误触发，会出现bit位错误；同时没有处理bit周期内的电平变化异常情况。

内容的提问来源于stack exchange，提问作者Torch