3. 中断管理优化：让CPU在正确的时间做正确的事

中断管理，说白了就是电梯控制系统的「应急响应机制」。你想想看，电梯在运行中，平层信号来了、门区传感器触发了、安全回路断开了——这些事件都必须立刻处理，晚一毫秒都可能出问题。我在多个电梯项目中踩过坑，今天就把中断优化的核心经验分享给你。

3.1 中断优先级设置：谁更重要，谁先响应

中断优先级不是随便设的。我见过不少新手工程师，把所有中断优先级设成一样，结果系统跑起来就乱套了。

核心原则：实时性要求越高的事件，优先级越高。

中断源	推荐优先级	理由
安全回路中断	最高（0级）	涉及人身安全，必须立即响应
平层传感器中断	高（1级）	影响停靠精度，延迟会导致冲层
门区信号中断	中（2级）	门控逻辑的关键触发点
通信接收中断	低（3级）	可以缓冲处理，容忍一定延迟
定时器中断	最低（4级）	周期性任务，可被其他中断抢占

3.2 中断嵌套处理：别让嵌套变成灾难

中断嵌套，说白了就是一个中断正在处理，另一个更高优先级的中断来了，CPU先跑去处理新的。这个机制用好了是利器，用不好就是灾难。

我的经验：在电梯控制系统中，我一般只允许2-3级嵌套。为什么？因为嵌套太深，栈空间会爆炸。我记得有一次调试，发现系统偶尔死机，查了三天才发现是中断嵌套太深，栈溢出了。

嵌套处理的关键点：

• 保存现场要完整：每个中断进入时，必须保存所有可能被修改的寄存器。我习惯用汇编代码手动保存，比编译器自动处理更可控。
• 关中断时间要短：在临界区操作时，关中断的时间不要超过10微秒。你想想看，如果关中断太久，高优先级事件就响应不了了。
• 嵌套深度要限制：建议在RTOS中设置最大嵌套深度，超过则直接报错。我一般设3级，够用又安全。

3.3 ISR设计原则：短小精悍，别在中断里磨叽

中断服务程序（ISR）的设计，核心就一句话：能少做就少做，能不做就不做。

我见过最离谱的代码，有人在ISR里调用了printf打印日志，结果电梯一运行就卡死。为什么？printf是阻塞的，而且执行时间不确定，在中断里用就是找死。

ISR设计五原则：

1. 只做最必要的事：比如读取硬件寄存器、清除中断标志、发送信号量。复杂逻辑放到任务里做。
2. 禁止阻塞调用：不能在ISR里等待信号量、等待消息队列、调用延时函数。这些都会导致系统死锁。
3. 禁止浮点运算：浮点运算耗时且不可预测。我习惯把所有浮点计算都放到任务里，ISR只传整数。
4. 保持执行时间恒定：ISR的执行时间应该是确定的，不能有循环等待、条件分支等不确定因素。
5. 使用RTOS提供的ISR专用API：比如FreeRTOS的xHigherPriorityTaskWoken机制，可以在ISR中安全地唤醒任务。

3.4 中断延迟优化技巧：把延迟压到微秒级

中断延迟，就是从事件发生到CPU开始执行ISR的时间。在电梯控制中，这个时间必须控制在微秒级。我实测过，如果中断延迟超过50微秒，平层精度就会受影响。

优化技巧清单：

• 关中断区域最小化：只在真正需要保护共享数据的代码段关中断，其他时候保持中断开启。我习惯用临界区API代替直接关中断，粒度更细。
• 中断向量表放RAM：把中断向量表放在RAM中，而不是Flash。RAM访问速度比Flash快一个数量级，能减少几十纳秒的延迟。
• 使用快速中断（FIQ）：如果CPU支持FIQ，把最高优先级的中断映射到FIQ。FIQ有独立的寄存器组，不需要保存恢复现场，延迟更低。
• 避免中断共享：多个外设共享一个中断线，会导致ISR里需要判断中断源，增加延迟。我尽量给每个关键外设分配独立的中断线。
• 预取指令优化：把ISR的代码放在紧挨着中断向量表的位置，利用CPU的指令预取机制，减少跳转延迟。

3.5 实战案例：一个中断优化引发的血案

最后分享一个真实案例。有一次，我负责的电梯在调试中频繁出现「平层超差」故障。排查了机械、传感器、算法都没问题，最后用逻辑分析仪抓了中断响应波形。

结果发现：通信中断的优先级设得太高，而且ISR里做了大量数据处理。每次通信中断进来，都会抢占平层传感器中断，导致平层信号延迟了200多微秒。

解决方案很简单：

1. 把通信中断优先级降到最低
2. 把通信ISR里的数据处理移到任务中
3. ISR只做数据接收和信号量发送

改完之后，问题立刻消失。你想想看，一个优先级设置的问题，折腾了我整整一周。所以我说，中断管理看似简单，但细节决定成败。