中断是嵌入式开发绕不开的话题，而EXTI（外部中断）几乎是每个写单片机程序的人入门第一课。按钮按一下、引脚跳个沿，就触发一次中断，去执行一段处理逻辑，这个模型简单到让人觉得“不需要动脑子”。但当我真正把项目复杂度堆上去，尤其是要同时处理多个中断源、做低功耗唤醒、还要保证响应实时性的时候，传统的中断回调写法开始变得别扭——而这也是我转向异步Rust嵌入式框架Embassy的契机。这篇博文不打算泛泛讲Embassy的“生态优势”，我只想用EXTI这一条线，把Embassy底层的异步中断模型拆开揉碎，从寄存器动作、中断唤醒、任务调度一路看到应用层的await，顺便把实操中踩过的坑和排查经验都交代清楚。

1. 传统EXTI实现，到底痛苦在哪

1.1 标准外设库与HAL库的两种典型写法

先回到老路上看一眼。用传统的C语言写EXTI，最经典的套路有两种。一种是标准外设库风格，代码长但直接；一种是HAL库风格，代码短但回调满天飞。以STM32F103为例，标准外设库的写法大致是：

EXTI_InitTypeDef EXTI_InitStructure; GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0); EXTI_InitStructure.EXTI_Line = EXTI_Line0; EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt; EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising; EXTI_InitStructure.EXTI_LineCmd = ENABLE; EXTI_Init(&EXTI_InitStructure); NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = EXTI0_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure);

然后你还要在stm32f10x_it.c里写中断服务函数：

void EXTI0_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line0) != RESET) { EXTI_ClearITPendingBit(EXTI_Line0); flag = 1; // 置个标志位，主循环去处理 } }

HAL库的写法更“现代”一点，中断服务函数被封装好了，你只需要实现回调：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == GPIO_PIN_0) { // 处理按键事件 } }

这两种写法在简单项目里都没问题，跑得很顺。但注意，它们有一个共同的预设：中断处理函数是一个事件点，你在这个点里做一小段事，然后回到主循环。这个预设决定了后续所有复杂度都堆在“如何分配这个事件点的处理逻辑”上。

1.2 回调式中断处理的三个死穴

第一，中断上下文不允许做耗时操作。你可以在中断里置标志位、清中断标志，但你要是敢在中断里跑延时、打日志、做复杂计算，轻则系统响应变慢，重则直接卡死其他中断。原因是中断服务函数运行时，同优先级或更低优先级的中断全被屏蔽了。我见过有人在EXTI回调里直接调HAL_Delay(10)做按键消抖，结果系统时钟直接被拖垮，其他任务全部乱套。

第二，共享状态的管理全靠开发者自觉。回调里置一个全局变量，主循环轮询这个变量。变量加了volatile了吗？有没有竞争？要不要临界区？你项目小的时候无所谓，项目大了——比如三路EXTI各自置标志位，加上定时器中断置的位，加上DMA传输完成的标志——你就开始在“标志位地狱”里打转了。每个标志都要检查、都要清楚说明“谁写谁读”，写错一次就是一个隐蔽的时序bug。

第三，回调与业务逻辑的映射是割裂的。从业务视角看，我的需求是“等待按键按下，然后执行三秒倒计时”。从传统中断视角看，我要拆成“中断回调里置位”“主循环里看到标志位后倒计时”两个片段。读代码的人需要自己在脑子里把这两个片段拼起来，才知道业务是什么。这个心智负担随着系统复杂度线性上升，而且极难测试。

2. Embassy异步EXTI的架构拆解

2.1 从ExtiInput到Handler：一次边沿触发的完整旅程

Embassy不是把中断回调改个名字就完事，它把“中断”包装成了异步世界里的一个可等待事件。你拿到一个ExtiInput，然后写出这样的代码：

let mut button = ExtiInput::new(channel, pin, Pull::Up, LowPolarity::Falling); button.wait_for_falling_edge().await; // 按键按下了，处理逻辑在这里写

这一行await背后发生的事情，是理解Embassy的关键。我从底层往外说。

先看芯片侧。GPIO引脚产生一个边沿信号，经过EXTI外设的边沿检测电路（上升沿/下降沿/双边沿），置起对应的挂起寄存器位，然后向NVIC发出中断请求。NVIC根据优先级的设定，跳转到对应的中断向量——在STM32上，根据引脚编号映射到EXTI0_IRQn、EXTI1_IRQn这些中断向量上。

再看Embassy的封装。不同的芯片支持类库（embassy-stm32、embassy-nrf、embassy-rp等）在exti模块里都实现了同一套接口。以stm32为例，ExtiInput::new内部干了三件事：把引脚映射到对应的EXTI线，配置GPIO的输入模式和上下拉，然后注册一个中断处理函数。这个注册不是简单地把用户代码塞进IRQHandler，而是把中断处理函数本身换成了Embassy内部的唤醒逻辑。

2.2 中断服务函数为什么只剩“唤醒”这一步

看下面这个简化后的实际处理过程。当EXTI0_IRQn触发时，芯片进入中断服务函数，Embassy在中断上下文里做的事情极少：

• 读取EXTI挂起位，判断这次是哪个引脚/哪条线触发；
• 清除挂起位；
• 找出所有正在等待该事件的异步任务（等待者），调用它们注册的唤醒器（Waker）的wake()方法；
• 退出中断。

仅此而已。你的业务逻辑——按键消抖、倒计时、LED闪烁、状态切换——全部不在这里执行，而是被放在异步任务里，由Embassy的执行器（Executor）在“合适的上下文”里继续运行。这个“合适的上下文”是什么？就是async任务被await挂起的那一刻，协程的恢复点。

这么设计的直接收益就是：中断服务函数永远只做最小必要操作，时间复杂度是O(等待者数量)，在绝大多数场景下是常数级。你永远不会在中断里跑业务逻辑，也就永远不会遇到中断里延时、中断里打日志卡死系统的问题。这是架构层面的解决，而不是靠“开发者自律”。

有人可能会问：那中断发生到业务逻辑真正执行的延迟，不是变大了吗？对，延迟确实比“直接在中断里执行”多了一次任务调度的开销。但这里有个重要的权衡：传统方案里中断延迟低，但你已经无法在中断里做复杂业务了；Embassy方案牺牲了微秒级的唤醒延迟，换来了业务逻辑可以写得像顺序代码一样清晰，而且不会被其他中断打断。对于极少数需要硬实时响应的场景（比如电机控制的电流环），你还是可以不通过Embassy，直接写一个紧急中断服务函数；但对于绝大多数外设事件处理，这个权衡是划算的。

2.3 异步机制和RTOS线程的本质区别

很多人第一次接触Embassy，会觉得它和FreeRTOS线程/队列的思路差不多：中断里发个信号量，任务里等信号量。表面看确实像，但底层差别很大。

RTOS的信号量唤醒，本质上是“线程上下文切换”。一个线程在等信号量时，它的栈还在，CPU寄存器组要保存/恢复，任务调度器需要遍历就绪链表、决定下一个执行谁。虽然现代RTOS已经把上下文切换优化得很快了，但每次切换仍然有固定的周期开销，而且每个线程都要独立分配栈空间——你不敢给太少，怕溢出，给多了RAM又不够。

Embassy的异步任务用的是Rust的Future机制。一个async fn被编译成一个状态机，挂起时只需要保存“这个Future执行到哪个状态”以及相关的局部变量，这些数据存贮在状态机结构体里，大小在编译期就确定了。任务切换不需要独立的线程栈，不需要保存/恢复全部通用寄存器，开销远小于RTOS线程切换。Rust的async/await在里面做的事情，通俗讲就是：把“保存现场”这件事从“保存整个调用栈”降级为“保存当前协程的局部状态”。

这个差别直接映射到硬件资源上：同样的RAM，跑RTOS可能只能开三五个线程，栈一给就是一两KB；Embassy可以开几十个异步任务，每个任务的状态可能只有几十到几百字节。我在一个Cortex-M0+的板子上，跑着一个主任务加两个异步外设任务，RAM占用都不到2KB，这用RTOS很难做到。

3. 实操过程：从零搭一个EXTI异步项目

3.1 环境准备和工程骨架

理论说完了，直接上手。我用的板子是手头一块CH32V307，原因有两个：一是它最近在Rust嵌入式圈的讨论热度很高，用Rust开发国产MCU的案例越来越多；二是它的EXTI映射和STM32差异不大，代码逻辑可以很方便移植到其他Cortex-M芯片上。如果你用的是STM32、nRF52、RP2040，流程完全一样，只是embassy-executor的feature要按芯片选。

第一步装Rust环境。我已经假设你装了rustup，接下来要做的是添加嵌入式目标：

rustup install nightly rustup default nightly rustup target add thumbv7em-none-eabihf

为什么必须用nightly版本？这是刚开始最容易踩的坑。Embassy的底层实现依赖Rust的async_fn_in_trait（AFIT）特性——就是允许trait里的方法返回impl Future——这个特性在撰写本文时还没有在stable版本中稳定。所以要么全链路用nightly工具链，要么用cargo +nightly指定命令。不用想着绕开，直接切nightly最省事。

VS Code这边我建议装好rust-analyzer扩展，它会自动读取工程里的rust-toolchain配置，帮你完成代码补全和语法检查。有一点提一下：如果国内拉取crates.io依赖慢，可以在~/.cargo/config.toml里配置镜像源，把source.crates-io替换成注册表镜像地址，能省非常多时间。这个属于环境优化技巧，常规情况下很好用。

3.2 Cargo.toml与依赖配置

新建一个工程：

cargo new ch32-embassy-exti --bin

然后编辑Cargo.toml。以CH32V307为例，依赖大概长这样：

[package] name = "ch32-embassy-exti" version = "0.1.0" edition = "2021" [dependencies] embassy-executor = { version = "0.6", features = ["arch-cortex-m", "executor-thread", "defmt"] } embassy-time = { version = "0.3", features = ["tick-hz-32_000"] } embassy-ch32 = { version = "0.1", features = ["ch32v307", "defmt", "time-driver"] } embedded-hal = "1.0" cortex-m = { version = "0.7", features = ["inline-asm"] } cortex-m-rt = "0.7" panic-halt = "0.2" defmt = "0.3" defmt-rtt = "0.4"

几点解释。

embassy-executor的feature里有executor-thread，表示用线程模式跑执行器——适合简单应用。还有executor-interrupt，可以在中断模式里跑更高优先级的异步任务，如果你的系统里有一个“必须最快响应”的EXTI业务，可以给那个任务单独开一个中断专用执行器，优先级设到最高。这是比较进阶的玩法，入门先不用碰。

embassy-time的tick-hz-32_000表示时间驱动器的时基是32kHz。这个值要和芯片的定时器配置对齐。有的芯片用32.768kHz的RTC晶体，有的用系统定时器分频，具体看芯片librar实现。

embassy-ch32目前还处于比较早期阶段，个别外设的API有变动，建议锁定版本，不要直接用git分支，不然接口改了还要跟着改代码。

3.3 编写第一版异步EXTI代码

看核心代码。我要实现的功能很简单：PA0接一个按键，按下去（下降沿触发）点亮PB0上的LED，再按一次熄灭。但注意，我只写一个异步任务，按键事件用await等待。

#![no_std] #![no_main] #![feature(type_alias_impl_trait)] use ch32_hal::exti::ExtiInput; use ch32_hal::gpio::{Input, Pull, Output, PushPull, Speed}; use ch32_hal::peripherals; use cortex_m_rt::entry; use embassy_executor::Executor; use embassy_time::{Duration, Timer}; use panic_halt as _; #[embassy_executor::task] async fn button_task( mut button: ExtiInput<'static, peripherals::PA0, Input>, mut led: Output<'static, peripherals::PB0>, ) { loop { // 等待下降沿（按键按下） button.wait_for_falling_edge().await; // 简单防抖：先等10ms再确认一次电平 Timer::after(Duration::from_millis(10)).await; if button.is_low() { led.toggle(); // 等待释放，避免按住时反复触发 button.wait_for_rising_edge().await; Timer::after(Duration::from_millis(10)).await; } } } #[entry] fn main() -> ! { let p = peripherals::Peripherals::take().unwrap(); let mut button = ExtiInput::new(p.PA0, Pull::Up, LowPolarity::Falling); let mut led = Output::new(p.PB0, PushPull, Speed::High); // 初始化执行器并派发异步任务 static EXECUTOR: Executor = Executor::new(); EXECUTOR.run(|spawner| { spawner.spawn(button_task(button, led)).unwrap(); }) }

这段代码信息量很大，我逐块解释。

ExtiInput::new的第一个参数是引脚，第二个是上下拉，第三个是触发极性。我用Pull::Up加LowPolarity::Falling，意思就是：按键一端接地，一端接PA0，默认高电平，按下瞬间产生下降沿，触发一次wait_for_falling_edge返回。这个配置比HAL库里的GPIO_MODE_IT_FALLING更直白，极性直接写在类型上，不容易混。

wait_for_falling_edge().await这行是核心。当请求被挂起时，Embassy的ExtiInput内部已经把所有需要的信息注册到了EXTI线的中断处理函数里。这里有个细节：同一个EXTI线上只能有一个活跃的等待者。因为某个EXTI线上一次只能被一个ExtiInput占用，如果你试图创建两个绑定同一根引脚的ExtiInput，编译期不一定报错，运行时就会panic。这个约束和芯片硬件一致——每个EXTI线同一时刻确实只能服务一个“事件”。

防抖逻辑我用了“等10ms再确认电平”的写法。这里其实有个传统单片机里很难受的问题：在中断回调里做延时会卡死系统，所以一般要靠定时器状态机或者HAL_Delay硬扛。在Embassy里没有这个问题，Timer::after(...).await挂起当前异步任务，不阻塞其他任何任务，系统可以继续跑别的异步逻辑。你可以在等待消抖的同时用另一个任务去刷新屏幕、读取传感器，互不影响。等你做完10ms的延时回来，确认电平还是低，说明这次触发是真实的，不是抖动。

3.4 编译、烧录与运行

写完后编译：

cargo build --release

build出来的文件是target/thumbv7em-none-eabihf/release/ch32-embassy-exti，十六进制或二进制文件配合烧录工具使用。CH32V系列有一个特殊点，它默认使用自研的WCH-Link调试器，烧录协议和标准CMSIS-DAP不完全一样。Rust生态里用probe-rs已经能通过WCH-Link烧录CH32V系列，配置方式如下：

在工程根目录建一个Embed.toml：

[default.probe] chip = "CH32V307VCT6" [default.flashing] format = "bin"

然后执行：

cargo embed --release

这样就能完成烧录和调试。如果你手头用的是STM32，步骤更简单：cargo embed直接能识别ST-Link，probe-rs对ST生态的支持已经非常成熟了。

运行后，打开defmt-rtt的日志输出，你会看到这样的节奏：第一次按下，button_task从await点被唤醒，进入防抖延时；第二次按下，又唤醒，执行翻转。整条链路里没有一次“忙等”，CPU在没事做的时候会进入低功耗的wfi等待状态。这一点在测量功耗时尤其明显——用传统轮询方式，哪怕你主循环里啥都不干，CPU也在跑；Embassy的任务挂起后，可以真正闲下来。

4. 常见问题与排查技巧实录

4.1 中断始终不触发的检查清单

这个问题最多，我按经验总结了排查顺序。

第一，先查EXTI线映射是否冲突。在STM32和CH32上，同一组EXTI线（比如EXTI0线的PA0/PB0/PC0）你只能用其中一个。如果你把PA0配置成EXTI输入，同时又想让PB0也做EXTI输入，后者就配不上，因为PB0映射的也是EXTI0线。硬件上不同GPIO端口的同编号引脚共享同一根EXTI线。检查你的工程里有没有这种“撞线”情况。

第二，查GPIO的上下拉和极性是否匹配。如果你设了Pull::Down却在等待Culing下降沿，按键按下只会让电平从低变低（没有边沿），永远等不到。反过来，上下拉为Pull::Up时等待上升沿也等不到。看起来是小问题，但真的很常见。建议在代码里先打印button.get_level()的初始电平，确认静态电平符合预期。

第三，查中断服务函数是否真的注册了。Embassy的注册逻辑发生在Executor.run之前还是之后，决定了中断能不能被正确唤醒。有一种经典错误：你在初始化EXTI之后马上要注册NVIC使能，NVIC没开，中断永远不会进来。Embassy的ExtiInput::new内部通常会做这一步，但如果某个芯片库封装不完整，你就得手动来。遇到不触发时，先在芯片库源码里搜NVIC::unmask，确认初始化流程有没有执行到。

第四，查低功耗模式。如果你在标准例程里加了wfi指令或者进入了睡眠模式，EXTI必须配置成事件中断唤醒源才能把CPU从睡眠中踢醒。Ch32的Executor有run和run_with_irq的区别，如果用wfi等待，要确保EXTI的Event和Interrupt模式都有配置。我在裸机Rust里就踩过这个坑：任务挂起后CPU睡了，按键中断来了却醒不过来，最后发现是NVIC没有使能对应中断线的EXTI事件。

4.2 抖动与实际项目中的防抖方案

机械按键的抖动，对异步模型来说其实是个“甜蜜的烦恼”——因为Embassy处理防抖太简单了，你很容易过度防抖。

我的最低建议是10ms延时加电平确认。代码里那段：

button.wait_for_falling_edge().await; Timer::after(Duration::from_millis(10)).await; if button.is_low() { ... }

这个组合能挡住绝大多数机械抖动。如果按键手感很差，或者板子走线长了有毛刺，可以把延时增加到30ms，但我不建议超过50ms——用户会觉得按键“变肉了”。

除了延时防抖，还有一种思路是利用上升沿同步。按住按键不放手，边沿只会触发一次，但如果你等待下降沿后立即在任务里做长时间阻塞，用户重复按会积压事件吗？答案是不会。因为wait_for_falling_edge().await只处理“边沿发生”这一个时点，不会排队。你处理完当前事件再回到wait，中间错过的边沿就丢了。这在某些场景是缺点，但很多场景反而是优点——自动防了重复触发。

如果确实需要“按住不放连续生效”（比如调音量按钮），写法就变成：等待下降沿后，进入一个周期性循环，每200ms toggle一次LED，直到检测到上升沿退出循环。这又是异步任务状态机的优势，在传统回调模型里，“持续按住”和“按下一次”是两个状态，得用标志位区分；在Embassy里就是控制流的自然延展。

4.3 与低功耗唤醒组合时的坑

低功耗唤醒是EXTI的经典使用场景，Embassy在这块也有特殊坑。

第一，唤醒后任务要重新初始化吗？不需要。Embassy的异步任务在await点恢复，状态都在，唤醒后继续往下走就行。传统中断模型里，你从低功耗醒来后要手动恢复外设时钟、重新配置GPIO，在Embassy里大部分芯片库都帮你处理了，但极端情况（比如深度停止模式连备份域都断电），外设寄存器会被重置，此时建议在任务恢复后重新new一次外设句柄。代码结构上，我会把外设初始化封装成一个init_peripherals()返回Result，这样每个恢复路径都能统一调用。

第二，小心EXTI的“存留挂起位”。芯片从低功耗醒来后，如果EXTI挂起寄存器里还残留着上次事件的状态，第一次wait_for_falling_edge().await可能立即返回——看起来像“按键幽灵触发”。排查方法很简单，在初始化EXTI之后、进入循环等待之前，主动读一下挂起位并清除一遍。

第三，中断优先级和Executor的模式联动。如果你用executor-interrupt模式跑高优先级异步任务，EXTI的中断优先级不能设得比执行器所在的中断优先级低，否则事件到了，执行器也被抢占掉了。我的经验是：EXTI用最高抢占优先级，Executor用次高优先级。这样既保证事件被立刻捕获，又能让高优先级异步任务尽快被调度。

5. 性能感知与我在实际项目里的取舍

5.1 一组直观的对比数据

我不喜欢只讲“感觉”，贴一份我在CH32V307上实测的大致数据（Cortex-M4F @144MHz，release优化）：

从表里能看到，异步方案在中断到业务的延迟上确实比“直接在中断里执行”慢了几微秒，但换来的是中断服务函数的耗时恒定、RAM开销大幅下降、业务代码可读性提升。90%以上的嵌入式外设事件处理，这个延迟完全不是瓶颈。电机电流环那种纳秒级响应的场景，请不要用通用框架的异步路径，另写紧耦合中断服务函数是更好的选择。

5.2 我在迁移旧项目时的一条经验

如果你有个老项目用传统中断回调已经稳定跑了两三年，不用急着全部重写。我的做法是：把中断服务函数里“置标志位”的逻辑原样保留，但把标志位的消费逻辑换成异步任务——新建一个Embassy任务，循环等待一个“自定义异步事件”，事件由旧的中断服务函数通过Waker触发。这个渐进迁移方案，让我可以先把最复杂、最难维护的一路EXTI业务迁到异步模型，跑顺了再继续迁其他外设，不用一步到位。几个月下来，稳定性不但没下降，代码反而好维护多了。

这个内容的下一步，我会继续把Executor内部的任务调度细节和Waker的生命周期管理单独写一篇，那里才是Embassy真正让人拍案叫绝的地方——但那是另一个故事了。最后说一句个人体会：能让你在中断服务函数里安心写业务逻辑的框架，是对嵌入式开发体验的一次重要重塑，而这也恰恰是异步Rust带给这个领域最有价值的东西之一。