概述
Delay机制允许任务主动暂停执行一段时间， 在时间到达后重新进入就绪队列等待调度。
任务延时机制用于让任务在指定时间内进入阻塞状态，是时间管理与调度控制的重要基础能力。与忙等待不同，延时机制将任务从运行态转换为阻塞态，释放CPU资源供其他任务使用，提高系统利用率。延时机制由系统节拍（Tick）驱动，通过延时队列管理等待任务，确保定时精度与实时性。
延时机制分为相对延时与绝对延时两种模式。相对延时指定任务暂停的持续时间，如os_delay(100)表示暂停100毫秒。绝对延时指定任务唤醒的绝对时间点，如os_task_delay_until(target_tick)表示在指定tick值时唤醒。相对延时适用于周期性任务控制，绝对延时适用于精确时间同步场景。HRTOS支持两种模式，满足不同应用需求。
延时机制的精度取决于系统节拍频率。节拍频率越高，延时精度越高，但系统开销也越大。HRTOS支持可配置的节拍频率，开发者可根据应用需求选择合适的精度与开销平衡。典型节拍频率包括1kHz（1ms精度）、10kHz（0.1ms精度）等。对于高精度延时需求，系统还支持硬件定时器直接唤醒，提供微秒级精度。
工作原理
当任务调用延时接口后，系统将其从运行态移出， 加入延时队列，由系统节拍（Tick）驱动计时， 到期后恢复为就绪状态。
延时机制的内部实现依赖于延时队列与系统节拍。延时队列是一个优先级队列，按到期时间排序，确保最早到期的任务位于队列头部。系统节拍是周期性中断，每次中断时递增全局tick计数器，并检查延时队列头部任务是否到期。如果到期，将任务从延时队列移除，状态从BLOCKED转换为READY，插入就绪队列，触发调度决策。
相对延时的实现流程包括：任务调用os_delay(ms)接口，系统将毫秒转换为tick数；计算到期时间 = 当前tick + 延时tick数；将任务状态从RUNNING转换为BLOCKED；创建延时条目（包含到期时间与任务指针），插入延时队列；触发调度器选择下一个任务执行。延时期间任务不占用CPU资源，系统可执行其他任务或进入低功耗模式。
绝对延时的实现流程包括：任务调用os_task_delay_until(target_tick)接口；检查目标tick值是否大于当前tick；如果是，将任务状态从RUNNING转换为BLOCKED；创建延时条目（包含目标tick与任务指针），插入延时队列；触发调度器选择下一个任务执行。绝对延时适用于需要精确时间同步的场景，如周期性任务在固定时间点执行。
延时到期唤醒流程包括：系统节拍中断触发；中断服务程序递增全局tick计数器；检查延时队列头部任务的到期时间；如果到期时间小于等于当前tick，将任务从延时队列移除；将任务状态从BLOCKED转换为READY；将任务插入就绪队列；如果被唤醒任务优先级高于当前运行任务，触发抢占调度。整个过程在中断上下文中快速完成，确保实时性。
关键接口 / 结构
相关接口文档： 时间管理 / 调度机制 / 实时调度 / 任务状态模型
os_delay()用于相对延时，参数包括延时毫秒数。该接口将毫秒转换为tick数，计算到期时间，将任务状态从RUNNING转换为BLOCKED，插入延时队列。延时成功返回0，失败返回错误码。该接口适用于周期性任务控制、任务节拍调整等场景。
os_sleep()用于tick级延时，参数包括延时tick数。该接口直接使用tick作为延时单位，避免毫秒转换开销，适合对精度要求不高的场景。延时成功返回0，失败返回错误码。该接口通常用于简单的延时需求，如任务休眠一段时间。
os_task_delay_until()用于绝对延时，参数包括目标tick值。该接口检查目标tick值是否大于当前tick，如果是，将任务状态从RUNNING转换为BLOCKED，插入延时队列。延时成功返回0，失败返回错误码。该接口适用于需要精确时间同步的场景，如周期性任务在固定时间点执行。
delay_entry结构体定义了延时队列条目的核心属性。expire_tick字段存储任务到期时间（tick值）。task字段指向延时任务的任务控制块。该结构体还可能包含链表指针、优先级等字段。结构体大小取决于配置，HRTOS通过优化字段布局减少内存占用。
运行流程
任务调用延时 → 进入阻塞态 → 加入延时队列 → Tick递增 → 到期 → 恢复就绪态。
完整的延时流程包括：任务调用os_delay(ms)接口；系统将毫秒转换为tick数；计算到期时间 = 当前tick + 延时tick数；将任务状态从RUNNING转换为BLOCKED；创建延时条目（包含到期时间与任务指针），插入延时队列；触发调度器选择下一个任务执行；系统节拍中断周期性触发；中断服务程序递增全局tick计数器；检查延时队列头部任务是否到期；如果到期，将任务从延时队列移除；将任务状态从BLOCKED转换为READY；将任务插入就绪队列；如果被唤醒任务优先级高于当前运行任务，触发抢占调度。
相对延时与绝对延时的使用场景不同。相对延时适用于周期性任务控制，如传感器采样任务每100毫秒执行一次。任务在执行完成后调用os_delay(100)，确保下一次执行在100毫秒后。绝对延时适用于精确时间同步，如音频播放任务需要在固定时间点输出音频数据。任务调用os_task_delay_until(target_tick)，确保在指定tick值时唤醒，保证音频输出节奏稳定。
延时过程中的ISR使用注意事项包括：如果任务在中断服务程序中调用延时接口，系统可能无法立即触发调度决策，因为中断上下文中不允许调度。HRTOS提供中断安全版本的延时接口，将延时操作推迟到中断退出后执行。开发者应避免在ISR中长时间延时，影响系统实时性。
扩展说明
HRTOS支持精确延时与绝对时间延时两种模式， 可用于周期任务控制与实时节拍同步。
延时机制是周期性任务控制的基础。周期性任务需要在固定时间间隔内重复执行，如传感器采样、控制回路更新、数据采集等。任务在执行完成后调用相对延时接口，确保下一次执行在指定时间间隔后。HRTOS提供周期性任务配置工具，支持自动计算延时时间，避免手动计算误差。
延时机制还支持实时节拍同步。在音频播放、视频解码、网络通信等场景中，任务需要在固定时间点执行，保证数据输出的节奏稳定。绝对延时接口允许任务指定唤醒的绝对时间点，确保任务在精确时间执行。系统还支持硬件定时器直接唤醒，提供微秒级精度，满足高精度同步需求。
- 模块职责：延时机制管理负责任务延时控制，确保任务在指定时间后唤醒
- 内部机制：基于延时队列、系统节拍、优先级队列、到期检查实现，支持相对与绝对延时
- 状态迁移：任务在RUNNING、BLOCKED、READY状态间转换，由延时接口与节拍中断驱动
- 调用流程：delay_call → tick_convert → expire_calc → block → queue_insert → schedule_trigger → tick_isr → expire_check → wake
- 资源管理：延时队列为共享资源需保护并发访问，延时条目为任务私有资源
- 工程案例：传感器采样系统、音频播放器、视频解码器、网络协议栈
- 边界条件：节拍频率、延时范围、队列容量、中断延迟
- 错误场景：延时参数无效、队列溢出、节拍溢出、唤醒失败、延时精度不足
- 异常处理：参数校验、队列扩容、节拍回滚、告警机制、降级处理
- 模块关系：与时间管理模块协作提供节拍驱动，与调度器模块协调唤醒与调度
延时机制的性能优化是实时系统工程的重要环节。HRTOS采用优化的延时队列数据结构，在O(log n)时间内插入与移除延时条目。系统支持位图延时队列，在O(1)时间内检查到期任务。对于多核SMP系统，每个核心独立维护延时队列，避免核心间竞争。这些优化确保了延时机制的高效性，满足实时系统的性能要求。
对于功耗敏感的嵌入式系统，延时机制的使用会影响系统功耗管理。任务延时期间系统可进入低功耗模式，降低CPU频率或关闭部分外设，减少功耗。HRTOS提供智能功耗管理机制，在所有任务处于延时状态时自动进入低功耗模式，在任务到期时快速唤醒。系统还支持任务级功耗配置，允许开发者根据任务重要性选择功耗策略，平衡实时性与功耗。