性能计数器不能直接校准定时器，但可通过动态测量误差并补偿来逼近设定间隔：在回调中读取入口/出口时间戳计算实际耗时与目标偏差，下次启动时调整等待值；高精度场景应结合硬件定时器单次模式与性能计数器闭环反馈修正重载值。
定时器精度不等于“设多少就准多少”，真正影响执行间距的，是一整条从硬件时钟源到软件调度的误差链。性能计数器（如 Windows 的 QueryPerformanceCounter 或 ARM 的 DWT_CYCCNT）本身不能直接“校准”定时器，但它能提供高分辨率时间戳，让你在运行时观测、建模并补偿关键延迟，从而逼近设定的执行间距。
为什么单纯靠系统节拍无法保证精度
大多数 RTOS 或操作系统依赖固定节拍（如 1ms tick）驱动软件定时器。但实际触发存在三重偏移：
- 硬件层抖动：晶振温漂、电源噪声导致基础时钟周期波动；
- 中断延迟：定时器溢出→CPU响应→进入 ISR，通常耗时几十纳秒至数微秒；
- 调度延迟：ISR 返回后，RTOS 调度器决定何时执行回调函数，受任务抢占、就绪队列长度影响。
这些延迟叠加后，一个标称 10ms 的软件定时器，实测间隔可能在 10.02ms–10.18ms 波动——性能计数器正是用来量化这部分偏差的工具。
用性能计数器做“动态误差测量”
不是一次性校准，而是每次触发时记录真实耗时，用于下一次启动的补偿调整：
- 在定时器回调开始处调用
QueryPerformanceCounter（Windows）或DWT->CYCCNT（Cortex-M），获取入口时间t_in； - 执行完业务逻辑后再次读取，得出口时间
t_out； - 计算本次实际耗时：
delta = t_out - t_in； - 与目标间隔
T_target比较，得出本次误差：error = delta - T_target； - 下次启动定时器时，将原定等待值减去该误差（或按比例补偿），例如：若目标是 10ms，但上次慢了 8μs，则下次设为 9.992ms。
硬件定时器 + 性能计数器协同优化
对精度要求更高的场景，应绕过软件节拍，直接使用硬件定时器触发中断，并用性能计数器做闭环反馈：
- 配置硬件定时器为单次模式（One-shot），初始重载值按理论计算设置；
- 中断服务程序中立即读取性能计数器，记录中断实际到达时刻；
- 对比理论触发时刻（上一次 + 目标周期），算出本次偏移；
- 动态修正下一次重载值：新重载 = 原重载 − 偏移 × 频率换算系数；
- 避免在 ISR 中做复杂运算，只更新寄存器，把补偿逻辑放在主循环或低优先级任务中处理。
注意事项与边界条件
性能计数器不是万能解药，使用时需注意：
- 时基稳定性：确保性能计数器所依附的时钟源（如 HPET、DWT）本身稳定，避免用 PLL 不稳的内部 RC 振荡器驱动；
- 读取开销：频繁读取性能计数器会引入额外指令周期，建议仅在关键点采样，而非每毫秒都读；
- 溢出处理：64 位计数器虽大，但在高频下仍可能溢出，需检查并处理 wrap-around；
- 不可补偿项：上下文切换、缓存未命中、内存访问延迟等非确定性开销无法通过计数器消除，只能靠降低系统负载或提升优先级缓解。
