1. NuttX 实时内核基础：任务调度模型、优先级管理、上下文切换开销分析
大家好，我是老李。在嵌入式实时系统里摸爬滚打了十几年，NuttX 是我最钟爱的内核之一。今天咱们聊聊实时内核最核心的三个东西：任务怎么调度、优先级怎么管、上下文切换到底有多贵。
说实话，很多人一上来就调优，结果发现连任务模型都没搞明白。我见过不少项目，明明硬件性能够，却因为调度策略选错，导致系统响应慢得像蜗牛。嗯，咱们从最基础的开始捋。
1.1 任务调度模型：三种模式，各有脾气
NuttX 支持三种调度模型。我个人习惯把它们比作三种不同的排队方式。
| 调度模型 | 特点 | 适用场景 |
|---|---|---|
| 轮转调度 (RR) | 同优先级任务轮流执行，时间片固定 | 多个同等重要的周期性任务 |
| 优先级抢占 (FIFO) | 高优先级任务随时打断低优先级 | 对响应时间有严格要求的场景 |
| 零星调度 (Sporadic) | 基于预算和周期的调度 | 偶发但紧急的任务 |
轮转调度，说白了就是大家轮流上。每个任务分一个时间片，用完就换人。我在做工业控制器时遇到过一个问题：三个传感器采集任务，优先级一样，用 RR 调度，结果每个任务都能及时响应，系统很稳定。
优先级抢占就更有意思了。高优先级任务一来，低优先级立马让路。你想想看，如果紧急报警任务来了，还得等普通任务跑完，那还叫实时系统吗？
核心要点：NuttX 默认使用优先级抢占调度。但你可以通过 sched_setscheduler() 在运行时切换策略。
1.2 优先级管理：数字越小，优先级越高
NuttX 的优先级范围是 0 到 255。0 是空闲任务，255 是最高优先级。这个设计跟 Linux 正好相反，Linux 是数字越大优先级越高。我第一次从 Linux 转过来时，差点被这个搞晕。
优先级管理有几个关键点：
- 静态优先级：创建任务时设定，一般不改
- 动态优先级：可以通过
sched_setparam()调整 - 优先级继承：解决优先级反转问题的利器
避坑指南：我曾经在一个项目中，把三个任务的优先级设成了 100、101、102。结果发现 102 的任务永远得不到执行。为什么？因为 100 和 101 一直在抢 CPU。记住，优先级差距太小，低优先级任务可能饿死。
优先级反转是个经典问题。低优先级任务拿着锁，高优先级任务等着锁，中优先级任务趁机抢跑。结果高优先级任务反而被低优先级任务拖死。NuttX 的优先级继承协议能解决这个问题——低优先级任务临时继承高优先级的优先级，跑完赶紧释放锁。
1.3 上下文切换开销：看不见的杀手
上下文切换，就是 CPU 从一个任务切到另一个任务。这个过程要保存当前任务的寄存器、栈指针、状态字，再恢复新任务的这些东西。开销有多大？我实测过，在 Cortex-M4 上，一次上下文切换大约需要 1-3 微秒。
听起来不多？但如果你每秒切换 10000 次，那就是 10-30 毫秒的纯开销。系统总共才多少 CPU 时间？
| 操作 | 典型耗时 (Cortex-M4 @ 168MHz) |
|---|---|
| 保存寄存器 | ~0.5 μs |
| 恢复寄存器 | ~0.5 μs |
| 调度决策 | ~0.3 μs |
| 总开销 | ~1.3 μs |
我的经验：减少上下文切换开销，最直接的办法就是减少切换次数。把多个小任务合并成一个中等任务，用状态机来管理。我曾经把一个 10 个任务的系统合并成 3 个，CPU 利用率直接降了 15%。
NuttX 的上下文切换实现很精巧。它利用了 ARM 的 PendSV 异常来延迟上下文切换。什么意思呢？就是当需要切换任务时，不立即切，而是触发 PendSV，等当前任务跑完当前指令再切。这样避免了在中断处理中直接切换带来的复杂性。
1.4 知识体系总览
下面这张图，是我自己梳理的 NuttX 实时内核基础结构。你看一眼，心里就有谱了。
这张图把三个核心模块串起来了。你仔细看，调度模型决定什么时候切换，优先级管理决定切换到谁，上下文切换决定切换要花多少时间。三者缺一不可。
1.5 实战中的取舍
我做过一个无人机飞控项目，要求任务响应时间在 100 微秒以内。当时我选了优先级抢占调度，把姿态控制任务设为最高优先级。但问题来了——高优先级任务太多，低优先级任务饿死了。
怎么解决的？我用了优先级继承 + 适当的时间片。关键任务用抢占，非关键任务用轮转。这样既保证了实时性，又避免了饿死。
记住：没有完美的调度策略，只有适合你场景的策略。调优的本质，就是在响应时间和公平性之间找平衡。
好了，这一章就到这里。调度模型、优先级管理、上下文切换开销，这三个东西是实时内核的基石。你吃透了它们，后面调优就顺了。