第3章车载ECU中断设计原则

3、车载ECU中断设计原则：中断频率控制、中断服务时间预算、中断与DMA协同

好，咱们进入第三章。这一章我打算聊聊中断设计里最核心的三个问题：频率怎么控、时间怎么算、DMA怎么搭。这三个点要是没想清楚，你的ECU跑起来大概率会出幺蛾子。

我在做AUTOSAR平台适配那几年，见过太多因为中断设计不合理导致的系统崩溃。有的是中断来得太频繁，CPU被活活拖死；有的是ISR里干了太多活，把任务调度全打乱了。嗯，咱们一个一个说。

中断的本质是什么？说白了就是外设在敲门。你想想看，如果门每1微秒就被敲一次，你还能专心干活吗？CPU也一样。

中断频率控制的核心原则：

能不中断就别中断：能用轮询解决的，别用中断。比如一些状态查询类的信号，1ms查一次就够了，没必要每10μs触发一次中断。
能合并就合并：多个事件可以共用一个中断源。比如CAN控制器通常支持多个报文共用一条中断线，别每个报文都单独申请一个中断。
频率上限要算清楚：我个人习惯，中断频率不要超过CPU主频的千分之一。举个例子，200MHz的MCU，中断频率最好别超过200kHz。超过这个数，上下文切换的开销就开始反噬了。

避坑指南：

我曾经在一个项目中，把ADC采样中断设成了1MHz。结果CPU有30%的时间都在做中断进出栈操作，任务调度完全乱套。后来我把采样率降到100kHz，配合DMA搬运数据，CPU占用率直接降到5%。

中断频率的典型参考值：

这个原则我每次培训都会强调：ISR里只做最紧急、最轻量的事。为什么？因为中断是抢占式的，它会把所有任务都挂起。你在ISR里待得越久，系统的实时性就越差。

ISR时间预算的黄金法则：

ISR执行时间 ≤ 中断周期的10%。比如中断周期是100μs，那ISR里最多干10μs的活。超过这个数，下一个中断来了你还没处理完，就会发生中断嵌套甚至丢失。
ISR里只做三件事：读硬件状态、清中断标志、发信号给任务。其他所有处理都扔给任务去做。
别在ISR里调用printf、malloc、semTake。这些函数要么太慢，要么可能引起死锁。我见过一个同事在ISR里调了printf，结果系统直接卡死——因为printf内部用了互斥锁。

我的个人经验：

我习惯在ISR里用一个“极简队列”来传递数据。比如一个环形缓冲区，ISR只负责往里面写数据，任务在空闲时从里面读。这样ISR的执行时间可以控制在几微秒以内。

ISR时间预算检查清单：

DMA是什么？说白了就是一个专门负责搬数据的小工。你告诉它“从A搬到B，搬完通知我”，它就能自己干完，不占用CPU时间。

中断与DMA的典型协同模式：

我推荐的中断+DMA设计流程：

注意：

DMA虽然好，但不是万能的。如果数据量很小（比如几个字节），DMA的配置开销反而比CPU直接搬运还大。我一般以32字节为界：小于32字节用CPU搬，大于32字节用DMA。

一个实际案例：

我在做车载以太网驱动时，需要处理大量网络包。每个包大约1500字节，中断频率约10kHz。如果每个包都用CPU搬，CPU占用率会超过40%。后来我改用DMA+双缓冲模式：DMA把数据搬到一个缓冲区，同时CPU处理另一个缓冲区。中断频率降到1kHz（每批处理10个包），CPU占用率降到5%以下。

嗯，这就是中断与DMA协同的魅力。你想想看，让硬件干它擅长的事，CPU干它擅长的事，系统才能跑得又快又稳。

总结一下本章核心：

下一章我会讲中断优先级配置和嵌套处理，那也是个容易踩坑的地方。咱们到时候接着聊。