第2章实时操作系统(RTOS)基础

第2章：实时操作系统(RTOS)基础：任务与调度、优先级驱动的内核、上下文切换与中断管理

各位工程师，大家好。欢迎来到《运动控制任务优先级设计实战课程》的第二章。

上一章我们聊了运动控制的整体架构，很多朋友反馈说「概念都懂，但一上RTOS就懵」。嗯，我完全理解。当年我第一次在ARM7上跑FreeRTOS，也是被任务调度搞得晕头转向。今天我们就来彻底搞懂RTOS的核心——任务、调度、优先级、上下文切换和中断管理。这些东西，说白了就是运动控制系统的「交通规则」。

2.1 任务与调度：运动控制的「多线程」本质

先问大家一个问题：一个运动控制系统，需要同时做几件事？

读取编码器位置（1kHz~10kHz）
运行PID控制算法（1kHz~20kHz）
处理上位机指令（10Hz~100Hz）
监控限位开关和急停（事件触发）
记录运行日志（1Hz）

你看，这些任务的时间要求完全不同。如果用裸机轮询，要么高频任务被低频任务拖慢，要么低频任务永远抢不到CPU。RTOS就是来解决这个问题的。

核心概念：在RTOS中，每个「任务」就是一个独立的无限循环函数，拥有自己的栈空间和优先级。调度器负责决定「现在该运行哪个任务」。

我个人习惯把运动控制任务分为三类：

任务类型	典型周期	优先级	示例
硬实时任务	50μs ~ 1ms	最高	电流环、位置环
软实时任务	1ms ~ 10ms	中	速度规划、轨迹插补
非实时任务	100ms ~ 1s	低	日志记录、参数配置

我在项目中遇到过最典型的错误：有人把日志打印任务设成了高优先级，结果运动控制周期被频繁打断，电机跑起来一顿一顿的。你想想看，打印几条日志而已，晚100ms输出有什么关系？但电流环晚100μs，电机可能就飞车了。

2.2 优先级驱动的内核：谁急谁先跑

RTOS的调度策略有很多种，但运动控制领域最常用的是优先级抢占式调度。说白了就是：谁优先级高，谁先跑；同优先级，轮流跑。

这里有个关键点：优先级必须是静态的，还是可以动态调整？

我的建议是：运动控制任务尽量用静态优先级。为什么？因为动态优先级调整会引入不确定性。我曾经在一个六轴机器人项目里试过动态优先级，结果在特定工况下出现了优先级反转，导致一个轴的控制任务被另一个轴的低优先级任务阻塞了200ms...嗯，那次调试了整整三天。

避坑指南：我曾经在STM32F4上跑FreeRTOS，把编码器读取任务优先级设为5，PID计算任务设为4。结果发现编码器读取太频繁，PID反而被饿死了。后来我调整了策略：编码器读取用中断，PID用高优先级任务，完美解决。

优先级设计的基本原则：

硬实时任务（电流环、位置环）：最高优先级，通常绑定到中断或最高优先级任务
软实时任务（速度规划、轨迹插补）：中等优先级，确保在硬实时任务空闲时及时执行
非实时任务（通信、日志）：最低优先级，有空就跑，没空就等

2.3 上下文切换：RTOS的「换人」机制

上下文切换，听起来很高大上，其实就像篮球比赛换人。当前任务下场（保存现场），新任务上场（恢复现场）。

每次上下文切换，CPU需要做三件事：

保存当前任务的寄存器、PC指针、栈指针
更新任务控制块（TCB）的状态
恢复新任务的寄存器、PC指针、栈指针

代码层面，一个典型的上下文切换（以ARM Cortex-M为例）是这样的：

; PendSV_Handler - 上下文切换入口
PendSV_Handler:
    ; 保存当前任务上下文
    MRS     R0, PSP           ; 获取当前任务栈指针
    STMDB   R0!, {R4-R11}     ; 保存R4~R11到栈
    ; 更新当前任务TCB中的栈指针
    LDR     R1, =CurrentTCB
    LDR     R2, [R1]
    STR     R0, [R2]
    
    ; 选择下一个任务
    BL      vTaskSwitchContext
    
    ; 恢复新任务上下文
    LDR     R1, =CurrentTCB
    LDR     R2, [R1]
    LDR     R0, [R2]          ; 获取新任务栈指针
    LDMIA   R0!, {R4-R11}     ; 恢复R4~R11
    MSR     PSP, R0           ; 更新栈指针
    BX      LR                ; 返回新任务

这里有个容易被忽略的细节：上下文切换的时间开销。在Cortex-M4上，一次完整的上下文切换大约需要50~100个CPU周期。如果CPU主频是200MHz，那就是0.25μs~0.5μs。看起来很快对吧？但如果你的控制周期只有50μs，而且有10个任务在频繁切换...嗯，你算算看，光切换就占了10%的CPU时间。

注意：上下文切换频率不是越高越好。我见过有人把时间片设为1个系统节拍（通常1ms），结果任务切换太频繁，CPU有效利用率反而下降了。建议运动控制任务的时间片设为5~10ms，或者干脆用事件驱动。

2.4 中断管理：RTOS的「紧急通道」

中断，是RTOS里最高优先级的「任务」。它比任何任务优先级都高。在运动控制中，中断通常用于处理：

编码器Z相脉冲（找零位）
限位开关触发（紧急停止）
定时器溢出（周期控制）
通信接收完成（数据到达）

中断处理的原则：快进快出。在中断服务函数（ISR）里，只做最必要的事，比如读取数据、设置标志位。复杂的计算和逻辑处理，交给任务去完成。

我常用的中断与任务协作模式：

// 中断服务函数 - 编码器Z相中断
void EncoderZ_IRQHandler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    
    // 1. 清除中断标志
    TIM_ClearITPendingBit(TIM2, TIM_IT_CC1);
    
    // 2. 记录当前位置（必须立即做）
    g_encoder_home_position = TIM_GetCounter(TIM3);
    
    // 3. 通知任务处理（从ISR中发送信号量）
    xSemaphoreGiveFromISR(xHomeSemaphore, &xHigherPriorityTaskWoken);
    
    // 4. 如果需要上下文切换
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

// 任务 - 归零处理
void HomeTask(void *pvParameters) {
    while(1) {
        // 等待归零信号
        xSemaphoreTake(xHomeSemaphore, portMAX_DELAY);
        
        // 执行归零后的处理（计算偏移、更新坐标系等）
        CalculateHomeOffset();
        UpdateCoordinateSystem();
    }
}

这种模式的好处是：中断只做最紧急的事（记录位置），复杂的计算交给低优先级的任务。既保证了实时性，又不会阻塞其他中断。

个人经验：我曾经在一个四轴运动控制卡上，把三个编码器的Z相中断都设成了最高优先级。结果三个中断同时触发时，CPU在中断里花了太多时间，导致主控制周期被严重延迟。后来我改用DMA+中断的方式，把数据采集交给DMA，中断只做同步，问题就解决了。

2.5 知识体系总览

为了让大家更直观地理解本章的知识结构，我画了一张图：

这张图把RTOS的四个核心模块串起来了。你想想看，运动控制系统的实时性，本质上就是这四个模块协同工作的结果。任何一个模块出了问题，整个系统都会受影响。

好了，本章的内容就到这里。记住：RTOS不是银弹，它只是工具。真正决定系统性能的，是你对任务优先级、中断管理和上下文切换的理解深度。下一章我们会深入讨论运动控制任务的优先级设计方法，到时候会结合具体的电机控制案例来讲解。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录