概述
定时器分为硬件定时器与软件定时器两类， 用于实现延迟触发、周期任务与超时控制。
定时器是实时操作系统中时间管理的核心组件，允许系统在指定时间点或周期性地执行特定操作。硬件定时器由MCU内部的定时器外设实现，具有高精度、低延迟的特点，适用于对时间精度要求极高的场景。软件定时器由系统Tick驱动实现，灵活性高但精度受Tick频率限制，适用于一般性定时需求。
在HRTOS中，定时器广泛应用于周期任务调度、超时检测、心跳维护、看门狗监控等场景。周期定时器可用于定期执行数据采集、状态检查、日志记录等周期性任务。单次定时器可用于延迟操作、超时控制、异步事件触发等场景。定时器回调函数在定时器到期时被调用，开发者需确保回调函数执行时间短，避免阻塞系统。
定时器的精度直接影响系统的实时性与可靠性。硬件定时器可达到微秒级甚至纳秒级精度，适合硬实时任务。软件定时器的精度受系统Tick频率限制，通常为毫秒级，适合软实时任务。HRTOS允许开发者根据应用需求选择合适的定时器类型，在精度与灵活性之间取得平衡。
工作原理
软件定时器依赖系统Tick推进计数， 当计数达到设定值时触发回调函数执行。
软件定时器的内部实现依赖于定时器控制块（Timer Control Block）与定时器队列。每个定时器包含周期值、剩余计数、回调函数指针、定时器模式（单次/周期）等字段。系统维护一个按到期时间排序的定时器队列，在每次系统Tick中断时遍历队列，递减所有定时器的剩余计数。当剩余计数归零时，系统触发定时器回调，并根据模式决定是否重新加载周期值继续运行。
硬件定时器的实现直接利用MCU内部的定时器外设。开发者配置定时器的预分频器、自动重装载值与中断使能，硬件定时器独立于CPU运行，在计数溢出时触发中断。中断服务程序（ISR）中执行定时器回调或设置标志通知任务。硬件定时器具有高精度、低CPU开销的优势，但数量受限于硬件资源，通常仅用于关键定时任务。
定时器回调的执行上下文是重要的设计考虑。软件定时器的回调通常在系统Tick中断上下文或专门的定时器任务上下文中执行。在中断上下文中执行回调需要严格限制执行时间，避免影响中断延迟。在任务上下文中执行回调允许更复杂的处理，但会增加响应延迟。HRTOS支持两种模式，开发者可根据回调复杂度选择合适的执行上下文。
定时器管理需要考虑定时器的创建、启动、停止、删除等生命周期操作。创建定时器时从定时器池分配控制块，初始化回调函数与周期值；启动定时器时将其插入定时器队列并开始计数；停止定时器时将其从队列中移除并暂停计数；删除定时器时释放控制块回定时器池。所有操作需在临界区中执行，避免并发访问导致数据不一致。
关键接口 / 结构
相关机制： 任务延时（Delay） / 系统节拍（Tick System） / 调度节拍（Scheduler Tick） / 实时调度
os_timer_create()用于创建定时器，参数包括定时器周期、定时器模式（单次/周期）、回调函数指针。该接口从定时器池分配控制块，初始化定时器参数，但不启动定时器。创建成功返回定时器句柄，失败返回错误码。定时器池的大小在系统配置时确定，达到上限时创建失败。
os_timer_start()用于启动定时器，参数为定时器句柄。该接口将定时器插入定时器队列，开始计数。对于周期定时器，首次到期后自动重新加载周期值继续运行。启动定时器时需确保回调函数已正确设置，否则到期时无法执行任何操作。
os_timer_stop()用于停止定时器，参数为定时器句柄。该接口将定时器从定时器队列中移除，暂停计数。停止后的定时器可重新启动，从初始周期值开始计数。停止操作不影响定时器的配置参数，仅暂停其运行状态。
os_timer_delete()用于删除定时器，参数为定时器句柄。该接口停止定时器（如果正在运行），释放定时器控制块回定时器池。删除后的定时器句柄失效，不能再用于其他接口。删除操作会清除定时器的所有状态，包括未执行的回调请求。
timer结构体定义了定时器的核心属性。period字段存储定时器的周期值，以Tick为单位或以毫秒为单位取决于配置。mode字段指示定时器模式，包括单次模式（TIMER_ONESHOT）与周期模式（TIMER_PERIODIC）。callback字段存储回调函数指针，定时器到期时调用该函数。该结构体还可能包含剩余计数、定时器状态、链表指针等字段。
运行流程
创建定时器 → 设置周期 → 启动计时 → Tick递增 → 到达阈值 → 执行回调函数。
完整的软件定时器流程包括：调用os_timer_create()创建定时器，从定时器池分配控制块，初始化周期值、模式、回调函数；调用os_timer_start()启动定时器，将其插入定时器队列，初始化剩余计数为周期值；系统Tick中断定期触发，中断处理程序遍历定时器队列，递减每个定时器的剩余计数；当剩余计数归零时，系统从队列中移除该定时器，调用回调函数执行；对于周期定时器，重新加载周期值并重新插入队列继续运行；对于单次定时器，释放控制块回定时器池或保持停止状态等待重新启动。
硬件定时器的流程包括：配置硬件定时器寄存器，设置预分频器、自动重装载值、中断使能；启动定时器，硬件开始独立计数；定时器计数溢出时触发硬件中断；中断服务程序执行回调函数或设置标志通知任务；对于周期定时器，硬件自动重装载计数值继续运行；对于单次定时器，需在中断中禁用定时器或重新配置。
定时器回调执行流程包括：系统检测到定时器到期，根据配置选择执行上下文（中断上下文或任务上下文）；在中断上下文中直接调用回调函数，需确保回调函数执行时间短，不影响中断延迟；在任务上下文中，系统唤醒定时器任务，任务从定时器队列中获取到期定时器，依次执行回调函数；回调函数执行完成后，根据定时器模式决定是否重新插入队列。
定时器删除流程包括：调用os_timer_delete()接口，内核验证定时器句柄有效性；如果定时器正在运行，将其从定时器队列中移除；释放定时器控制块回定时器池；清除定时器的所有状态与关联资源；返回删除成功状态。删除操作必须在临界区中执行，避免在删除过程中定时器到期导致野指针访问。
扩展说明
HRTOS支持单次定时器与周期定时器模式， 并可与任务调度和事件系统联动使用。
定时器与事件系统的联动是常见的设计模式。定时器到期时触发事件标志，任务等待该事件后执行相应操作。这种设计解耦了定时触发与任务处理，提高了系统的灵活性。定时器也可与信号量配合，用于超时等待场景：任务在等待信号量时启动超时定时器，定时器到期后释放信号量或触发错误处理，避免任务无限等待。
在嵌入式系统中，看门狗定时器（Watchdog Timer）是重要的安全机制。硬件看门狗定时器独立于CPU运行，定期需要软件"喂狗"（重置计数器）。如果系统故障导致无法及时喂狗，看门狗定时器超时后触发系统复位。HRTOS提供软件看门狗定时器作为补充，在硬件看门狗之外提供额外的故障检测与恢复机制。
定时器的精度与抖动是实时系统关注的重点。软件定时器的精度受Tick频率限制，抖动取决于中断延迟与调度延迟。硬件定时器的精度取决于时钟源稳定性与预分频器配置。HRTOS提供高精度定时器接口，利用硬件定时器实现微秒级精度的定时需求，适用于PWM生成、精确延迟、协议时序等场景。
- 模块职责：定时器管理负责软件与硬件定时器的创建、调度、回调执行与生命周期管理
- 内部机制：基于定时器控制块、定时器队列、Tick中断、硬件中断实现，支持单次与周期模式
- 状态迁移：定时器在IDLE、RUNNING、EXPIRED状态间切换，由创建、启动、到期、停止操作驱动
- 调用流程：create → configure → start → tick → expire → callback → reload/delete
- 资源管理：定时器控制块为定时器私有资源，定时器池为全局资源需保护并发访问
- 工程案例：周期任务调度、超时检测、心跳维护、看门狗监控、PWM生成
- 边界条件：定时器池容量、Tick频率限制、硬件定时器数量、回调执行时间
- 错误场景：定时器池耗尽、回调函数为空、定时器句柄无效、硬件配置错误
- 异常处理：定时器溢出检测、回调执行异常、硬件中断故障、看门狗复位处理
- 模块关系：与Tick模块同步时间，与调度器模块联动回调，与事件模块协同触发
定时器性能优化是实时系统工程的重要环节。HRTOS采用优化的定时器队列数据结构，如时间轮（Timing Wheel）或分层时间轮，在O(1)时间内找到到期定时器，避免每次Tick中断遍历整个队列。对于大量定时器系统，这种优化显著降低了Tick中断的处理时间，提高了系统整体性能。
对于功耗敏感的嵌入式系统，定时器可与低功耗模式协同工作。当系统进入低功耗模式时，软件定时器暂停计数，硬件定时器可配置为唤醒源。定时器到期时唤醒系统，执行回调后重新进入低功耗模式。这种设计在保证定时功能的同时最小化功耗，适用于电池供电的设备。