系统节拍（Tick）概念
好，咱们今天聊聊RTOS里最基础、也最容易让人忽视的一个概念——系统节拍，也就是Tick。
我刚开始接触RTOS那会儿，觉得Tick不就是个定时器中断嘛，有啥好研究的？后来踩了坑才明白，Tick选得好不好，直接决定了你的系统是“丝般顺滑”还是“卡成PPT”。
Tick的定义
说白了，Tick就是RTOS的心跳。它是由硬件定时器周期性触发的一个中断。
每次Tick中断到来，内核都会做三件事：
- 检查当前正在运行的任务是否用完了时间片
- 更新所有任务的延时计数器
- 如果有更高优先级的任务就绪了，触发任务切换
你可以把Tick想象成一个节拍器。每“滴答”一声，内核就醒过来看一眼，看看有没有事情需要处理。
核心要点：Tick是RTOS驱动任务调度、延时管理、超时检测的底层时钟源。没有Tick，RTOS就“死”了。
Tick与实时性的关系
这里有个常见的误解：很多人觉得Tick频率越高，系统实时性就越好。
嗯，这话只说对了一半。
实时性取决于两件事：
- 事件响应延迟——从事件发生到任务开始处理的时间
- 任务切换开销——每次切换任务消耗的CPU时间
Tick频率高了，内核检查得更频繁，理论上响应延迟会降低。但代价是什么？
我曾在项目中遇到过这样一个情况：把Tick从100Hz调到1000Hz，结果系统反而变慢了。为什么？因为CPU把大量时间花在了Tick中断处理和任务切换上，真正干活的时间反而少了。
避坑指南：我曾经在一个电机控制项目里，为了追求“极致响应”，把Tick设到了10kHz。结果中断服务程序占用了超过30%的CPU时间，电机控制算法反而跑不满了。后来老老实实降到1kHz，配合硬件PWM才解决问题。
所以，Tick和实时性的关系不是简单的正比关系。你想想看，如果Tick中断本身占用了太多CPU时间，那实时性反而会下降。
这里有个经验公式：
- Tick中断处理时间 < Tick周期的5%，系统表现良好
- Tick中断处理时间 > Tick周期的20%，系统开始出现明显抖动
- Tick中断处理时间 > Tick周期的50%，系统基本废了
Tick频率选择
那么问题来了：Tick频率到底怎么选？
我个人习惯从三个维度来考虑：
| 维度 | 说明 | 典型值 |
|---|---|---|
| 应用需求 | 任务需要的最小延时精度 | 延时精度 = 1/Tick频率 |
| CPU负载 | Tick中断占用的CPU百分比 | 建议 < 5% |
| 硬件能力 | 定时器支持的最大频率 | 通常没问题，但注意功耗 |
我一般会这样选：
- 低功耗物联网设备：10Hz ~ 100Hz。省电第一，响应慢点没关系
- 工业控制：100Hz ~ 1kHz。平衡响应和负载
- 音频/高速数据采集：1kHz ~ 10kHz。需要快速响应，但要做好优化
- 电机控制/高频开关：建议用硬件外设，别靠Tick
我的建议：如果你不确定，先从100Hz开始。大多数应用场景下，100Hz的Tick配合好的任务设计，已经能应付90%的情况了。等系统跑起来后，用逻辑分析仪抓一下Tick中断的耗时，再决定要不要调高。
最后说一个我踩过的坑：
有一次做智能家居网关，Tick设了500Hz。结果发现WiFi模块经常断连。排查了好久才发现，Tick中断优先级设得太高，把WiFi的中断给抢了。WiFi模块收不到ACK，自然就断连了。
所以，Tick频率的选择不只是算算CPU负载那么简单。你还要考虑：
- 中断优先级怎么分配
- Tick中断会不会阻塞其他关键中断
- 低功耗模式下Tick怎么处理
嗯，这些内容咱们后面章节会详细讲。今天先把Tick的概念吃透，后面就好办了。