Rust RTIC嵌入式并发工程 - 第4节

4. RTIC核心架构

各位同学，咱们今天聊聊 RTIC。说实话，我第一次接触这个框架的时候，心里是有点抵触的——「又一个嵌入式框架？我直接用裸机轮询不香吗？」但后来在一个电机控制项目里被中断嵌套搞到头大，才真正体会到 RTIC 的价值。

RTIC，全称 Real-Time Interrupt-driven Concurrency，翻译过来就是「实时中断驱动并发框架」。它专门为 ARM Cortex-M 系列微控制器设计，用 Rust 语言实现。你想想看，嵌入式系统里最头疼的是什么？是多个任务同时抢 CPU，是中断优先级搞混导致系统崩溃，是共享数据被意外修改。RTIC 就是来解决这些问题的。

设计哲学：让并发变得安全且可预测

RTIC 的设计哲学，说白了就三个词：安全、零成本、确定性。

• 安全：所有资源共享都在编译期检查，运行时不会出现数据竞争。我在一个四轴飞行器项目里用过裸机加临界区的方式，调试到凌晨三点才发现是共享变量被两个中断同时改了。换成 RTIC 后，这种问题再没出现过。
• 零成本：RTIC 的调度和同步机制全部在编译期完成，运行时没有额外的锁开销。它不像 FreeRTOS 那样需要维护任务控制块链表，也不像裸机那样需要手动开关中断。
• 确定性：任务的响应时间是可计算的。RTIC 基于优先级抢占调度，高优先级任务永远先执行。这一点在工业控制里特别重要——你总不希望电机控制任务被一个串口中断打断吧？

任务模型：硬件任务、软件任务、空闲任务

RTIC 把任务分成三类。我刚开始学的时候觉得分类有点多，但用久了才发现，每种任务都有它最适合的场景。

任务类型	触发方式	优先级	典型用途
硬件任务	硬件中断事件	由硬件中断优先级决定	传感器数据采集、PWM 控制、紧急停止
软件任务	由其他任务或定时器触发	由软件指定（1~N）	数据处理、状态机更新、通信协议解析
空闲任务	CPU 空闲时自动运行	最低（优先级 0）	低功耗模式、系统监控、看门狗喂狗

硬件任务：响应最快的「特种兵」

硬件任务直接绑定到 NVIC（嵌套向量中断控制器）的中断向量表。它的优先级由硬件决定，0 最高，N 最低。一旦触发，CPU 会立即响应——哪怕你正在执行其他任务。

我记得在一个激光测距项目里，需要以 1μs 的精度捕获回波信号。用软件轮询根本做不到，只能用硬件任务直接挂到定时器捕获中断上。RTIC 让我可以这样写：

#[task(binds = TIM2, priority = 1)]
fn tim2_capture(ctx: tim2_capture::Context) {
    // 直接读取捕获寄存器
    let value = ctx.device.TIM2.ccr1.read().bits();
    // 处理回波时间
    process_echo(value);
}

注意这里的 binds = TIM2，它告诉 RTIC 这个任务绑定到 TIM2 的中断。优先级 1 意味着它是最高优先级的任务之一。嗯，这里要注意：硬件任务的优先级不能超过硬件支持的范围，Cortex-M3/M4 一般是 0~15。

软件任务：灵活调度的「常规部队」

软件任务不直接绑定硬件中断，而是由其他任务或定时器通过 spawn 机制触发。它的优先级由软件指定，RTIC 会在编译期生成一个优先级位图，运行时通过位操作快速找到最高优先级的就绪任务。

我习惯把数据处理、协议解析这类对实时性要求不那么苛刻的工作放在软件任务里。比如：

#[task(priority = 3)]
fn process_data(ctx: process_data::Context, data: u32) {
    // 处理采集到的数据
    let result = complex_calculation(data);
    // 触发下一个任务
    ctx.shared.send_result.spawn(result).ok();
}

你可能会问：为什么不直接用硬件任务？因为硬件任务会阻塞其他中断。如果你把所有工作都塞进硬件任务，系统响应反而会变差。软件任务的好处是，它可以在不阻塞高优先级中断的情况下执行。

空闲任务：CPU 的「休息时间」

空闲任务在所有其他任务都执行完毕后运行。它的优先级是 0，最低。RTIC 默认会在空闲任务里执行 WFI（Wait For Interrupt）指令，让 CPU 进入低功耗模式。

但你可以覆盖这个行为。我在一个电池供电的传感器节点里，就在空闲任务里做了深度睡眠前的准备工作：

#[idle]
fn idle(ctx: idle::Context) -> ! {
    loop {
        // 进入低功耗模式
        ctx.device.SCB.set_sleepdeep();
        // 等待中断唤醒
        unsafe { core::arch::asm!("wfi") };
        // 唤醒后检查是否需要继续睡眠
        if !has_pending_work() {
            continue;
        }
    }
}

注意空闲任务的返回类型是 !，表示它永远不会返回。实际上，空闲任务就是一个无限循环。

资源管理与锁机制

资源共享是并发编程里最麻烦的事。RTIC 用了一套非常巧妙的方法——编译期资源分析。说白了，就是让编译器在编译时就搞清楚：哪个任务能访问哪些资源，会不会产生冲突。

共享资源 vs 本地资源

RTIC 把资源分成两类：

• 共享资源：可以被多个任务访问，需要加锁保护。
• 本地资源：只能被一个任务访问，不需要加锁。

声明方式也很直观：

#[resources]
struct Resources {
    // 共享资源：多个任务可以访问
    #[shared]
    counter: u32,

    // 本地资源：只能被指定任务访问
    #[local]
    buffer: [u8; 128],
}

这里有个细节：本地资源虽然不需要加锁，但它只能被一个任务使用。如果你试图在另一个任务里访问 buffer，编译器会直接报错。这就是 Rust 的所有权系统在发挥作用。

锁机制：Ceiling 协议

RTIC 没有用传统的互斥锁或信号量，而是用了 优先级天花板协议（Priority Ceiling Protocol）。这个协议的核心思想是：当一个任务持有锁时，把它的优先级临时提升到所有可能竞争这个资源的任务中的最高优先级。

为什么要这么做？我举个例子。假设有三个任务：A（优先级 1）、B（优先级 2）、C（优先级 3）。A 和 C 共享一个资源。如果 A 先拿到锁，然后 B 抢占 A，但 B 不需要这个资源，那么 B 执行完后 C 才能执行。但如果 C 也需要这个资源，而 A 还没释放锁，C 就会被阻塞。这就是优先级反转。

Ceiling 协议解决了这个问题：当 A 拿到锁时，它的优先级被提升到 3（C 的优先级）。这样 B 就无法抢占 A，A 能尽快释放锁，C 就能及时执行。

锁的使用方式

在 RTIC 里，访问共享资源必须通过 lock 方法：

#[task(priority = 2, shared = [counter])]
fn increment(ctx: increment::Context) {
    ctx.shared.counter.lock(|c| {
        *c += 1;
    });
}

这个 lock 方法会做两件事：

1. 提升当前任务的优先级到资源的 ceiling 值。
2. 在闭包执行完毕后恢复原来的优先级。

注意，闭包里的代码要尽量短。我在一个项目里看到有人把整个数据处理流程都放在 lock 里，结果高优先级任务被阻塞，系统响应变慢。记住：锁只保护共享数据的访问，不要在里面做耗时操作。

知识结构总览

下面这张图总结了 RTIC 的核心概念和它们之间的关系：

从这张图可以看出，RTIC 的三个核心支柱——设计哲学、任务模型、资源管理——是相互支撑的。设计哲学决定了任务模型的实现方式，任务模型又决定了资源管理的策略。