4、中断管理与时间管理：中断服务程序设计、临界区保护、系统时钟节拍、软件定时器

各位同学，咱们今天聊点硬核的——中断与时间管理。

说实话，搞工控系统这么多年，我见过太多因为中断没处理好导致系统崩溃的案例。你想想看，一个实时操作系统，如果连中断都管不好，那还谈什么实时性？

4.1 中断服务程序设计——别让ISR成为你的噩梦

中断服务程序，简称ISR。说白了，就是硬件触发后，CPU放下手头活，先去处理紧急事件的那段代码。

我刚开始做嵌入式那会儿，犯过一个低级错误——在ISR里调用了printf。结果呢？系统直接卡死。为什么？因为printf本身可能触发中断，这就形成了递归中断，栈空间瞬间爆炸。

⚠️ 避坑指南： ISR里千万别做这些事：
  • 调用可能引起阻塞的函数（如printf、malloc）
  • 执行浮点运算（除非你的CPU有硬件FPU且上下文保存完整）
  • 执行耗时过长的循环
  • 直接操作全局变量而不加保护

那ISR应该怎么写？我个人的习惯是：

  1. 极简原则——ISR里只做最必要的事，比如读取硬件寄存器、清除中断标志、发送信号量或消息给任务。
  2. 快速进出——ISR执行时间越短越好，最好控制在微秒级。
  3. 避免嵌套——除非你非常清楚硬件行为，否则尽量关掉中断嵌套。
// 一个典型的中断服务程序示例
void TIM2_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    
    // 清除中断标志
    TIM_ClearITPendingBit(TIM2, TIM_IT_Update);
    
    // 发送信号量给等待的任务
    xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
    
    // 如果有更高优先级的任务被唤醒，立即切换
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
💡 经验之谈： 我在一个电机控制项目中，曾经把整个PID计算都放在ISR里。结果中断频率一高，系统就频繁抖动。后来我把PID计算挪到任务里，ISR只负责触发采样和发送信号量，问题迎刃而解。

4.2 临界区保护——别让共享数据打架

临界区，就是那些不能被多个任务或中断同时访问的代码段。你想想看，如果任务A正在更新一个全局变量，突然被中断打断，中断服务程序也去修改同一个变量——那数据不就乱套了吗？

保护临界区，常用的方法有几种：

方法 适用场景 缺点
关中断 ISR与任务共享数据 影响实时性，不能长时间关中断
互斥信号量 任务间共享数据 可能引起优先级反转
任务锁 多核系统 实现复杂

我个人最常用的是关中断的方式，尤其是在ISR和任务之间共享数据时。为什么？因为简单可靠，而且FreeRTOS、uC/OS这些RTOS都提供了现成的API。

// 使用关中断保护临界区
void vUpdateSharedData(void)
{
    taskENTER_CRITICAL();
    
    // 这里访问共享变量，不会被中断打断
    g_uiCounter++;
    g_ulTimestamp = get_system_time();
    
    taskEXIT_CRITICAL();
}
⚠️ 注意： 关中断的时间一定要短！我曾经见过一个同事，在临界区里做了个耗时100ms的运算，结果系统时钟节拍都丢了，整个系统时间错乱。记住：临界区里只做必要的读写操作，复杂的计算放到外面去。

4.3 系统时钟节拍——RTOS的心跳

系统时钟节拍，就是RTOS的脉搏。它由硬件定时器周期性触发中断产生，每次中断就是一次“心跳”。

这个心跳频率怎么定？我一般遵循这个原则：

  • 任务切换频繁的场景：1000Hz（1ms一个节拍）
  • 一般工控应用：100Hz~500Hz（2ms~10ms）
  • 低功耗场景：10Hz~50Hz

为什么不能太高？你想想看，如果节拍频率是10kHz，那CPU每100us就要进一次中断。中断处理本身有开销，再加上任务切换，CPU的有效利用率就大打折扣了。

🔑 关键点： 系统时钟节拍决定了RTOS的时间精度。所有基于时间的功能——任务延时、超时等待、软件定时器——都依赖这个节拍。节拍频率越高，时间精度越高，但CPU开销也越大。

我记得在一个数据采集项目中，客户要求采样间隔精确到100us。我一开始把节拍设成了10kHz，结果系统负载直接飙到80%。后来我改用硬件定时器直接触发DMA采集，节拍只用来做任务调度，问题就解决了。

4.4 软件定时器——灵活的时间管理工具

软件定时器，说白了就是基于系统时钟节拍实现的虚拟定时器。它不需要占用硬件定时器资源，可以创建任意多个。

软件定时器有两种模式：

  • 单次模式：定时时间到后执行一次回调，然后自动停止。
  • 周期模式：定时时间到后执行回调，然后自动重新开始计时。
// 创建一个周期性的软件定时器
TimerHandle_t xTimer;
xTimer = xTimerCreate(
    "LED_Timer",           // 定时器名称
    pdMS_TO_TICKS(500),    // 定时周期：500ms
    pdTRUE,                // 周期模式
    (void *)0,             // 定时器ID
    vTimerCallback         // 回调函数
);

// 启动定时器
xTimerStart(xTimer, 0);

// 回调函数
void vTimerCallback(TimerHandle_t xTimer)
{
    // 每500ms切换一次LED状态
    vToggleLED();
}
💡 实战建议： 软件定时器的回调函数是在定时器任务中执行的，所以它本质上还是一个任务上下文。不要在回调里做耗时操作，否则会影响其他定时器的精度。我一般把定时器回调当作“触发信号”，真正的处理逻辑放在普通任务里。

这里有个容易踩的坑——软件定时器的精度。它受限于系统时钟节拍。如果你的节拍是10ms，那软件定时器的精度最多也就是10ms。想要更高精度？那就得用硬件定时器了。

好了，中断和时间管理这块，核心就是这些。记住几个原则：ISR要短、临界区要保护、节拍频率要合理、软件定时器要轻量。把这些搞明白了，你的RTOS应用就稳了一大半。

← 上一章 📖 返回目录 下一章 →