第2章 高频面试问题与回答框架（一）：基础技术

是否理解中断从触发→响应→服务→返回的全链路硬件行为；是否清楚中断优先级与嵌套的底层实现条件；能否区分不同MCU架构（如ARM Cortex-M）的差异。

1. 触发条件：电平/边沿触发，标志位硬件置位
2. 硬件响应：关中断、压栈（断点+关键寄存器）、查向量表
3. 软件执行：跳转ISR，执行中断服务程序
4. 中断返回：RETI指令，出栈恢复现场，开中断
5. 嵌套条件：仅高优可打断低优，同优/低优不可打断

中断是CPU暂停当前任务转处理紧急事件的机制。触发后硬件自动关中断、保存断点PC和关键寄存器到堆栈，根据向量号跳转ISR。若开启嵌套，高优中断可打断低优ISR；否则等待当前ISR执行完毕。返回时执行RETI指令，恢复现场并开中断。在Cortex-M中，硬件自动压栈xPSR/PC/LR/R12等，且中断优先级由NVIC管理。

中断响应延迟如何计算？哪些因素影响延迟？如何优化？（提示：从硬件优先级判断、压栈时间、跳转指令周期等维度拆解。）

不要只背流程，要结合具体MCU（如STM32 NVIC配置）说明实现细节。注意区分“中断”与“异常”在ARM Cortex-M中的处理差异；中断嵌套不是无条件的，必须确认硬件是否支持且优先级配置正确。

是否从协议架构层面理解本质区别（而非仅管脚数量）；是否具备根据场景约束进行工程选型的判断力；是否了解速率限制的根本原因。

1. 协议架构：I2C半双工/地址寻址 vs SPI全双工/片选寻址
2. 硬件资源：I2C两线/开漏上拉 vs SPI四线/推挽输出
3. 速率对比：I2C 100k~3.4Mbps vs SPI可达50Mbps+
4. 选型依据：从机数量、速度要求、管脚预算、抗干扰需求

I2C两线半双工，通过地址寻址，支持多主机仲裁，适合管脚受限、多从机场景，典型速率100k~400kbps，受开漏上拉RC延迟限制。SPI四线全双工，片选寻址，速率可达Mbps级，适合高速大数据量传输，但管脚多且无内置应答。选型时根据从机数量、速率、管脚预算综合决定，IO充足且要求高速优先选SPI。

I2C仲裁机制如何工作？SPI四种模式（CPOL/CPHA）如何配置？I2C速率上不去的原因是什么？（提示：开漏驱动+上拉电阻形成的RC延时是根本瓶颈。）

不要简单说“I2C慢、SPI快”，要讲清楚根本原因（开漏上拉 vs 推挽输出）。I2C速率限制是物理层决定的，SPI的四种模式要结合时序图说明。选型时要考虑线缆长度和抗干扰，I2C在长线场景更脆弱。

是否理解看门狗作为系统最后一道防线的设计哲学；是否踩过喂狗时机不当的坑；能否区分不同看门狗类型及其适用场景。

1. 基本原理：独立硬件计数器，超时触发系统复位
2. 类型区分：IWDG（独立RC振荡器） vs WWDG（窗口限制）
3. 喂狗策略：主循环统一喂狗，禁止在中断中喂狗
4. 调试技巧：调试模式下可配置为仅中断不复位

看门狗是独立硬件计数器，超时未重置则复位系统。IWDG由独立RC振荡器驱动，最可靠；WWDG需在特定时间窗口内喂狗，能检测程序跑飞。喂狗应在主循环或任务调度中统一管理，避免在中断中喂狗导致掩盖异常。调试阶段可配置为中断模式而非复位模式，便于定位问题。

多任务系统中如何设计喂狗策略？窗口看门狗为什么比独立看门狗更能检测程序异常？看门狗在低功耗模式下如何工作？

不要只说“定期喂狗”，要区分IWDG和WWDG的本质差异。强调“在中断中喂狗是反模式”——这会掩盖主循环卡死的故障。另外注意看门狗在低功耗模式下的处理：部分MCU在休眠时会停止WDT计数，需根据芯片手册确认。