深入浅出ARM7异常处理：快速理解FIQ与IRQ区别

深入理解ARM7中断机制：为什么FIQ比IRQ快？

在嵌入式系统的世界里，时间就是一切。一条指令的延迟，可能就决定了你的电机控制是否失步、音频采样是否丢帧、通信协议能否对齐时序。

而在这其中，中断处理的效率，往往是决定系统实时性的关键瓶颈。

今天我们就来聊一个经典话题——ARM7架构中的FIQ与IRQ。这不仅是学习早期ARM处理器绕不开的一课，更是理解“硬件如何为软件提速”这一设计理念的绝佳范例。

从一个问题开始：为什么需要两种中断？

设想你正在设计一块工业控制器，上面挂着多个外设：

一个高速ADC每10μs触发一次采样完成中断；
一个UART以9600bps接收配置命令；
一个定时器负责调度任务节拍；
还有一个紧急停机按钮，必须在1μs内响应。

这些中断的需求完全不同：有的要极致速度，有的可以稍等片刻，有的则要求稳定可预测。

如果所有中断都走同一条路径，那最慢的那个就会拖垮整个系统的响应能力。

于是，ARM7给出了一个聪明的答案：双中断线设计 —— FIQ 和 IRQ。

它们不是简单的优先级高低之分，而是从寄存器资源、响应流程到编程模型都做了差异化优化。尤其是FIQ，它本质上是一次面向性能的硬件特化。

FIQ：为速度而生的“快速通道”

它到底快在哪？

我们常说“FIQ比IRQ快”，但具体快在哪里？不是一句“优先级高”就能打发的。真正的差异藏在细节里。

✅ 独立寄存器组：省去压栈开销

这是FIQ最大的杀手锏。

在ARM7中，R8–R14 这7个寄存器是FIQ模式专属的。当你进入FIQ异常时，可以直接使用这些寄存器，无需像IRQ那样先把现场保存到栈上。

这意味着什么？

; 典型IRQ处理开头（需压栈） STMFD SP!, {R0-R3, R12, LR} ; 而FIQ可以直接干活： MOV R8, R0 ; 暂存数据 ADD R9, R1, #1 ; 计算偏移

光这一条，就能节省5~8个时钟周期—— 在主频仅为几十MHz的老式MCU上，这已经是质的飞跃。

✅ 最高优先级 + 固定向量地址

FIQ的异常向量位于0x0000001C，仅次于复位和未定义指令，优先级高于IRQ、预取中止等几乎所有其他异常。

更重要的是，FIQ只有一个入口。不像IRQ需要通过中断控制器查源，FIQ通常直连关键外设（如DMA完成、ADC EOC），跳过轮询环节，实现“一触即发”。

✅ 返回更高效

FIQ返回时只需一条指令：

SUBS PC, LR, #4

这条指令不仅跳转回原程序位置，还会自动将SPSR恢复到CPSR，完成状态还原。没有额外函数调用开销，也没有复杂的上下文重建过程。

实战案例：用FIQ拯救丢包的ADC采集

曾经有个项目，客户要用LPC2148做每秒10万次的ADC采样（即每10μs一次中断）。最初用的是IRQ，结果发现缓存区总有数据丢失。

排查下来，问题出在中断延迟上：

步骤	耗时估算
中断检测 & 切换模式	~2 cycles
压栈 R0-R3,R12,LR	~6 cycles
查VIC确定中断源	~10 cycles
调用服务函数	~3 cycles
总计	>20 cycles

假设主频为60MHz，每个cycle约16.7ns，总延迟接近350ns~500ns。听起来不多？但别忘了，你还得加上外设中断信号传播、总线等待、Cache缺失等因素，实际平均响应时间轻松突破2~3μs。

对于10μs周期的任务来说，这种不确定性足以导致后续中断被覆盖或错过。

解决方案很简单：改用FIQ，并将ADC完成信号接到nFIQ引脚。

修改后代码如下：

FIQ_Handler ; 直接使用R8-R12，不压栈 LDR R8, =adc_buffer LDR R9, [R8], #4 ; 获取当前指针并后移 LDR R10, =ADC_DATA_REG LDR R11, [R10] ; 读取采样值 STR R11, [R9], #4 ; 存入缓冲区 LDR R12, =ADC_CLEAR_REG STR R12, [R12] ; 清除中断标志 ; 更新全局变量（若必要） STR R9, [R8] SUBS PC, LR, #4 ; 快速返回

实测结果显示：中断响应稳定在3μs以内，抖动小于200ns，完全满足高速采集需求。

这就是FIQ的价值：它让原本不可能的任务变得可行。

IRQ：通用型选手的稳重选择

如果说FIQ是特种部队，那IRQ就是常规军。它虽然不够快，但胜在灵活、通用、易于管理。

共享资源带来的代价

IRQ没有专用寄存器。进入中断前，必须手动保存可能被破坏的寄存器：

IRQ_Handler SUB LR, LR, #4 STMFD SP!, {R0-R3, R12, LR} ; 保护现场 BL C_ISR_Function LDMFD SP!, {R0-R3, R12, PC}^ ; 恢复并返回

仅压栈和出栈就多花了10+ cycles，还不包括中断源识别的时间。

但在大多数场景下，这是完全可以接受的。比如：

定时器中断（ms级周期）
UART接收一帧数据（几百μs级别）
I²C状态轮询

这些任务本就不追求纳秒级精度，反而更看重代码可维护性和多中断共存能力。

多中断聚合靠VIC

ARM7芯片通常配备向量中断控制器（VIC），它可以将多个外设中断汇聚到单一IRQ线上。

工作方式如下：

void IRQ_Service_Routine(void) { uint32_t status = VIC_Status; if (status & TIMER0_INT) { handle_timer0(); VIC_Clear = TIMER0_INT; } else if (status & UART1_RX_INT) { uart1_rx_isr(); VIC_Clear = UART1_RX_INT; } // ... }

虽然增加了几条判断语句，但由于中断频率不高，整体影响可控。而且这种方式极大节省了GPIO中断引脚数量，适合外设众多的复杂系统。

如何选择？一张表说清FIQ vs IRQ

特性	FIQ	IRQ
优先级	最高	中等（低于FIQ）
向量地址	`0x1C`	`0x18`
专用寄存器	R8–R14（7个）	仅SP、LR独立
上下文保存	可免压栈	必须显式压栈
典型延迟	< 1μs（可达300ns）	1~5μs（依赖VIC查询）
适用场景	高速数据流、硬实时任务	一般外设、低频中断
是否支持嵌套	可软件使能	同样可软件控制
编程复杂度	较高（常需汇编）	较低（C语言友好）

📌经验法则：
- 关键路径、高频中断 → 用FIQ
- 普通功能、调试方便 → 用IRQ
- 不确定？先用IRQ，性能不够再迁移到FIQ

常见坑点与调试秘籍

❌ 坑1：忘记清除中断标志

无论FIQ还是IRQ，必须在外设或VIC中明确清除中断标志，否则会反复触发同一中断，导致系统卡死在ISR中。

// 错误示例：没清标志 void Timer_ISR() { do_something(); // 忘了写 VIC_Clear = TIMER_FLAG; }

后果：CPU刚退出中断，又立刻被重新打断，最终堆栈溢出重启。

❌ 坑2：在FIQ中调用复杂C函数

虽然可以用C写FIQ handler，但如果函数内部使用了R8-R12，编译器可能会误认为这些是普通寄存器而进行覆盖。

建议做法：

将FIQ处理精简为“读数据 + 写缓冲 + 清标志”
复杂逻辑交给主循环或任务处理
或者用__attribute__((interrupt("FIQ")))告知编译器上下文保护策略

✅ 秘籍：用内联汇编最小化路径

对于极限性能要求，可以在C中嵌入关键汇编段：

void __attribute__((interrupt("FIQ"))) FastCapture(void) { __asm volatile ( "ldr r0, =buffer_ptr\n" "ldr r1, [r0]\n" "ldr r2, =ADC_DAT\n" "ldr r3, [r2]\n" "str r3, [r1], #4\n" "str r1, [r0]\n" "subs pc, lr, #4" ); }

这样既能享受C环境的便利，又能精确控制执行流。