RTX5 | 绝对延时与相对延时的实战抉择

1. 从电机控制案例看延时的重要性

去年给某工业设备做电机控制系统时，我遇到了一个典型问题：用PWM控制电机转速时，每隔10ms就要采集一次编码器数据。最初使用osDelay(10)做延时，结果发现实际采样间隔在9-12ms之间波动。这种时序抖动直接导致转速控制出现明显波动，就像开车时油门忽大忽小。

RTX5作为实时操作系统，提供了两种延时方式：

• 相对延时：osDelay(ticks)，从调用时刻开始计算延时
• 绝对延时：osDelayUntil(tick)，基于系统时钟节拍做时间锚点

这两种方式看似都能实现10ms延时，但在我的电机控制项目中，使用osDelay的转速波动幅度比osDelayUntil大了3倍。后来用逻辑分析仪抓取波形才发现，当系统处理CAN总线中断时，osDelay的误差会累积叠加，而osDelayUntil会自动补偿延迟时间。

2. 深入理解两种延时机制

2.1 相对延时的"偷拍"现象

想象你在用手机连拍功能，每按一次快门就立即设置1秒定时器（相当于osDelay）。如果某次按下快门后突然有来电打断，等接完电话再拍，整个拍摄节奏就全乱了。这就是相对延时的核心问题——不抗干扰。

在RTX5中，osDelay的工作流程是这样的：

1. 调用时刻记录当前tick值（假设为T0）
2. 将线程状态改为WAIT_DELAY
3. 当系统tick ≥ T0 + delay_ticks时唤醒线程

但如果有高优先级任务或中断占用CPU，实际唤醒时间可能是T0 + delay_ticks + Δt。更严重的是，下一次osDelay仍然基于新的调用时间计算，误差会持续累积。

c复制// 典型错误用法（误差累积）
void SensorThread(void *arg) {
    while(1) {
        ReadSensor();
        osDelay(10);  // 每次都可能少1-2个tick
    }
}

2.2 绝对延时的"节拍器"原理

绝对延时更像乐队的节拍器，无论某个音符是否弹错，下一个节拍永远准时到来。osDelayUntil的关键在于它使用系统基准时间作为同步点：

1. 首次获取基准tick（如osKer