2. 实时操作系统基础：RTOS核心概念、任务与调度、中断管理、资源同步机制
各位同学，欢迎来到第二章。上一章我们聊了DSP伺服系统的整体轮廓，今天咱们深入底层，看看支撑这一切运转的“骨架”——实时操作系统（RTOS）。
说实话，我早年做伺服驱动时，用的是裸机跑大循环。那时候觉得RTOS是“杀鸡用牛刀”。直到有一次，一个多轴联动项目，中断嵌套和任务时序搞得我焦头烂额，一个优先级反转问题让电机在高速下剧烈抖动……嗯，从那以后，我彻底成了RTOS的拥趸。你想想看，伺服系统对时间的要求是“微秒级”的，没有一套可靠的调度机制，就像在高速公路上开没有方向盘的跑车。
核心观点：RTOS不是“操作系统”，而是“时间管理大师”。它的核心使命是确保每个任务在规定的截止时间前完成。
2.1 RTOS核心概念：任务、内核、上下文
咱们先捋清几个最基础的概念。RTOS里，最小的执行单元叫任务（Task），也叫线程。每个任务都有自己的栈空间、优先级和状态。我习惯把任务想象成一个“独立的小程序”，它们轮流占用CPU。
内核（Kernel）是RTOS的心脏。它负责调度任务、管理中断、提供同步机制。市面上常见的RTOS内核有FreeRTOS、uC/OS-III、RT-Thread等。我个人偏爱FreeRTOS，因为它开源、轻量，在Cortex-M系列DSP上跑得飞起。
这里有个关键概念——上下文切换（Context Switch）。当CPU从一个任务切换到另一个任务时，需要保存当前任务的寄存器、栈指针、状态字等信息，再恢复新任务的这些信息。这个过程必须快，通常由汇编代码实现。我在项目中曾遇到过上下文切换耗时过长导致控制周期抖动的问题，后来通过优化栈空间对齐和禁用不必要的浮点寄存器保存，把切换时间从3微秒降到了1.2微秒。
避坑指南：我曾经在任务栈分配上吃过亏。栈太小，任务跑着跑着就溢出了，数据被踩得一塌糊涂。建议每个任务至少分配512字节，复杂任务建议1KB以上。可以用RTOS自带的栈水印检测工具来监控。
2.2 任务与调度：谁先跑？跑多久？
调度器是RTOS的“交通警察”。它决定哪个任务获得CPU使用权。伺服系统中最常用的是优先级抢占式调度（Preemptive Scheduling）。说白了，高优先级的任务随时可以打断低优先级的任务。
为什么伺服系统必须用抢占式？因为电流环、速度环这些实时任务必须在固定周期内完成。如果让它们和通信任务“公平竞争”，那电机控制就乱套了。
常见的调度策略有几种：
| 调度策略 | 特点 | 伺服场景适用性 |
|---|---|---|
| 优先级抢占式 | 高优先级任务立即抢占低优先级 | 非常适合，电流环最高优先级 |
| 时间片轮转 | 同优先级任务轮流执行固定时间片 | 适合后台通信、日志等非实时任务 |
| 协作式 | 任务主动让出CPU | 不推荐，无法保证实时性 |
我建议在伺服系统中这样分配优先级：
- 最高优先级（0-1）：电流环中断服务函数（ISR）
- 高优先级（2-3）：速度环任务、位置环任务
- 中优先级（4-5）：通信任务（EtherCAT、CANopen）
- 低优先级（6-7）：状态监测、故障记录、人机交互
注意：优先级不要超过8级。优先级太多会导致调度开销增大，而且容易引发优先级反转问题。我曾经在一个项目里设了16级优先级，结果调试时发现任务切换时间翻了一倍，得不偿失。
2.3 中断管理：让CPU“听指挥”
中断是实时系统的灵魂。伺服系统中，PWM定时器中断、编码器捕获中断、通信中断……这些中断信号就像“紧急电话”，必须优先处理。
RTOS对中断的管理有几个关键点：
- 中断优先级与任务优先级是两套体系。中断永远高于任何任务。即使最低优先级的中断，也能打断最高优先级的任务。
- 中断服务函数（ISR）要短小精悍。我见过有人把整个FOC算法放在ISR里跑，结果导致其他中断丢失。正确的做法是：ISR只做最紧急的事（如读取ADC值、置位标志位），然后通过信号量或消息队列唤醒一个任务来处理后续工作。
- 中断嵌套要谨慎。虽然RTOS支持中断嵌套，但嵌套层数太多会导致栈溢出和时序不可控。我一般限制嵌套不超过2层。
这里分享一个我常用的中断处理模式：
// PWM定时器中断 - 电流环采样
void PWM_ISR(void) {
// 1. 清除中断标志
// 2. 读取ADC电流值
// 3. 执行电流环PI控制（极简版）
// 4. 更新PWM占空比
// 5. 发送信号量给速度环任务
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(xSpeedLoopSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
你看，ISR里只做了最核心的电流控制，然后把速度环的计算“外包”给了任务。这样既保证了实时性，又避免了ISR过于臃肿。
2.4 资源同步机制：别让任务“打架”
多个任务访问共享资源（如全局变量、外设寄存器）时，必须同步。否则就会出现数据竞争——一个任务在写，另一个任务在读，读到的数据可能是“半成品”。
RTOS提供了几种同步机制：
- 信号量（Semaphore）：用于任务同步或资源计数。二值信号量像一把“钥匙”，谁拿到谁执行。计数信号量可以管理多个同类资源。
- 互斥量（Mutex）：带优先级继承的信号量，专门解决优先级反转问题。我强烈建议在伺服系统中使用互斥量保护共享数据。
- 消息队列（Message Queue）：用于任务间传递数据。比如编码器位置数据通过队列从ISR传给位置环任务。
- 事件标志组（Event Group）：用于多条件触发。比如等待“编码器就绪”和“电流环就绪”两个事件同时发生。
实战经验：我曾经在一个六轴机器人项目中，因为使用了二值信号量保护共享的电机参数表，导致高优先级的轨迹规划任务被低优先级的通信任务阻塞——典型的优先级反转。后来换成互斥量，问题立刻解决。记住：保护共享数据，优先用互斥量，别图省事用信号量。
还有一个容易被忽视的点——临界区（Critical Section）。当需要保护非常短的代码段（比如几条指令）时，可以临时关闭中断。但关闭中断的时间不能超过10微秒，否则会影响其他中断的实时性。
// 临界区示例：更新电机状态结构体
taskENTER_CRITICAL();
motor.status = RUNNING;
motor.speed = current_speed;
motor.position = encoder_position;
taskEXIT_CRITICAL();
2.5 知识体系总览
说了这么多，咱们用一张图来总结本章的核心逻辑。这张图展示了RTOS在伺服系统中的角色和各个组件之间的关系。
这张图清晰地展示了从硬件到应用的层次关系。中断管理层负责响应硬件事件，RTOS内核层提供调度和同步服务，应用任务层实现具体的控制算法。每一层都依赖下一层的服务，但又相互隔离——这就是RTOS的魅力所在。
个人建议：刚开始学RTOS时，不要急着把所有功能都用上。先跑通两个任务（一个控制任务、一个通信任务），用信号量同步它们。等跑顺了，再逐步加入中断管理、消息队列等高级特性。我当年就是这么一步步过来的。
好了，这一章的内容就到这里。RTOS是伺服系统的“操作系统”，理解它的核心概念，你就能更好地驾驭多任务并发带来的复杂性。下一章我们会深入任务调度的具体实现，看看如何用代码把今天讲的理论落地。