4. 软硬件接口：MMIO与DMA的原理与延迟对比、中断与轮询的取舍

好，咱们今天聊点实在的。软硬件怎么握手？数据怎么从芯片A搬到芯片B？CPU到底要不要亲自下场？这些问题，说白了就是接口设计的问题。

我做了这么多年芯片，见过太多团队在接口上栽跟头。要么延迟高得离谱，要么CPU被中断淹死。今天咱们就把MMIO、DMA、中断、轮询这四样东西掰开揉碎，讲清楚。

4.1 MMIO：最直接的沟通方式

MMIO，全称Memory-Mapped I/O。名字挺唬人，其实很简单——就是把外设的寄存器映射到CPU的地址空间里。

你想想看，CPU访问内存是什么感觉？一条load指令，数据就来了。MMIO就是让CPU用同样的方式去访问硬件寄存器。写一个控制位，硬件就动起来；读一个状态位，就知道硬件干完活了没有。

我在项目中遇到过一个问题：某个网卡芯片的MMIO读操作，竟然要等1微秒。为什么？因为硬件设计时没考虑读操作的返回路径，数据得绕一大圈才能回到CPU。嗯，这就是典型的「设计时很爽，调时时想哭」的案例。

4.2 DMA：让CPU喘口气

DMA，Direct Memory Access。说白了就是给CPU找了个帮手，专门负责搬数据。

CPU的强项是计算和决策，不是当搬运工。你让CPU一个一个字节地拷贝数据，那它就别干别的了。DMA控制器就是干这个的——它自己就能把数据从外设搬到内存，或者从内存搬到外设。

我习惯把DMA分成两类：

• 简单DMA：一次触发，搬一块数据。适合小数据量。
• 链式DMA：用描述符链表管理多个传输任务。适合大数据量、连续传输。

延迟对比？我直接给你个表格，一目了然：

操作方式	典型延迟	CPU占用	适用场景
MMIO单次读写	50-200 ns	高（CPU全程参与）	控制寄存器、小数据量
DMA单次传输（4KB）	1-10 μs（启动+传输）	低（仅启动和完成时）	大数据块、流式数据
链式DMA（多块）	启动延迟+传输延迟	极低（一次配置多次传输）	视频帧、网络包批量处理

注意看，DMA的延迟大头其实在启动阶段。配置描述符、启动DMA、等待完成——这些步骤省不了。但一旦跑起来，传输效率是CPU手动拷贝的几十倍。

4.3 中断 vs 轮询：两种等待哲学

数据到了，CPU怎么知道？两种方式：要么主动问（轮询），要么等通知（中断）。

轮询，就是CPU每隔一段时间去查一下状态寄存器。就像你每隔5分钟看一次手机有没有新消息。

中断，就是硬件主动告诉CPU：「嘿，数据来了！」。就像手机响了，你才去看。

哪个好？别急着下结论。我见过有人无脑推崇中断，也见过有人死守轮询。其实各有各的命门。

轮询的适用场景

• 数据到达间隔很短：比如几百纳秒就来一次。中断的上下文切换开销反而更大。
• CPU闲着也是闲着：比如在某个专用处理器上，没有别的任务要跑。
• 延迟要求极高：中断有响应延迟（从硬件触发到CPU开始处理），轮询可以做到微秒级响应。

我曾经在一个40Gbps的网卡驱动里，把中断改成了轮询。为什么？因为中断来得太频繁了——每秒几百万次，CPU光处理中断就占了60%的算力。改成轮询后，CPU占用降到10%，吞吐量反而上去了。

中断的适用场景

• 事件稀疏：数据几毫秒甚至更久才来一次。轮询就是浪费电。
• CPU很忙：有多个任务要调度。中断能让CPU只在必要时响应。
• 功耗敏感：轮询让CPU一直醒着，中断可以让CPU休眠。

4.4 核心逻辑：一张图说清楚

下面这张SVG图，是我自己梳理的软硬件接口决策流程。你照着这个走，基本不会跑偏。

这张图的逻辑其实很简单：先看数据量，决定用MMIO还是DMA；再看事件频率，决定用轮询还是中断。两个维度一交叉，答案就出来了。

4.5 避坑指南

最后，我把自己踩过的坑总结一下，你遇到了能少走弯路：

• MMIO的Cache问题：我曾经忘了把MMIO区域配置为non-cacheable，结果读到的寄存器值永远是旧的。CPU的Cache把硬件状态给「缓存」了。嗯，调了三天才发现。
• DMA的地址对齐：有些DMA控制器要求源地址和目的地址按4字节或8字节对齐。不对齐的话，要么报错，要么性能暴跌。我习惯在驱动里加一个对齐检查。
• 中断的优先级反转：低优先级中断处理时间太长，把高优先级中断堵住了。解决办法是：中断处理函数里只做最必要的事，重活儿交给tasklet或工作队列。
• 轮询的功耗陷阱：无脑轮询会让CPU温度飙升。我见过一个嵌入式设备，轮询间隔设成1微秒，结果芯片烫得能煎鸡蛋。加一个自适应轮询间隔，问题解决。

好了，这一章就到这儿。记住我说的：接口设计没有绝对的对错，只有合不合适的场景。你下次做方案时，拿这张决策图出来对照一下，基本不会出大错。