1. 中断驱动串口通信的工程本质与设计权衡
在嵌入式系统开发中，串口通信看似简单，但其底层实现方式直接决定了系统的实时性、资源占用率和可维护性。轮询（Polling）与中断（Interrupt）是两种根本不同的软件架构范式，而非简单的代码写法差异。轮询法将串口状态检查嵌入主循环，CPU必须周期性地主动查询USARTx_SR寄存器中的RXNE（Read Data Register Not Empty）标志位，这本质上是一种“推”模型——软件主动向硬件索取数据。而中断法则构建了一个“拉”模型：硬件在数据就绪时主动向CPU发出信号，CPU暂停当前任务，跳转至预设的中断服务程序（ISR）处理数据。这种范式转换带来了三个核心工程影响：第一，CPU利用率显著提升，在无数据到达时可执行其他任务或进入低功耗模式；第二，数据响应延迟从轮询周期缩短至中断响应时间（通常为数微秒），对实时性要求高的场景至关重要；第三，引入了上下文切换开销与临界区管理复杂度。
在STM32F103平台的实际项目中，是否采用中断需基于明确的系统约束进行决策。视频中提到“尽量少用中断”的建议，其工程依据在于：F103系列MCU的NVIC（Nested Vectored Interrupt Controller）虽支持多级优先级，但当中断源数量增加时，中断嵌套、抢占与响应延迟的管理难度呈非线性增长。一个仅处理串口接收的单中断系统，其复杂度远低于同时启用TIMx更新中断、ADC转换完成中断、EXTI外部中断的多中断系统。更关键的是，F103的Cortex-M3内核在中断进出时需自动压栈/弹栈8个寄存器（R0-R3, R12, LR, PC, xPSR），若ISR执行时间过长，会严重挤压主循环的执行窗口。因此，中断法并非万能解药，其适用边界在于：数据流具
