一、模组联调概述

1.1 什么是模组联调

模组联调，说白了就是让各个独立的硬件模块「开口说话」。

你写好了驱动，画好了原理图，单板也打样回来了。每个模块单独测都没问题——Wi-Fi 能连上，蓝牙能搜到设备，传感器能读数。但把它们放在一起，系统就崩了。

为什么会这样？

因为模块之间会打架。I²C 总线冲突、中断优先级抢资源、电源纹波互相干扰……这些问题单模块测试根本发现不了。联调就是把这些模块拼在一起，让它们协同工作。

我个人的定义是：模组联调是在硬件集成之后、系统测试之前，验证多个模块之间接口、协议、时序、资源分配是否正确的过程。

1.2 联调在项目中的位置

先看一张图，你就明白了。

从这张图你能看到，联调处在「单模块测试」和「系统测试」之间。它不是可选项，而是必经之路。

我记得有一次项目赶进度，团队想跳过联调直接上系统测试。结果呢？Wi-Fi 和蓝牙抢天线资源，系统跑 10 分钟就死机。最后花了三天定位问题，还不如一开始老老实实做联调。

1.3 联调的核心目标

联调到底要达成什么？我总结了四个目标：

目标	说明	验收标准
接口对通	物理层信号正常，电气特性符合规格	示波器测量波形合格，无毛刺/过冲
协议握手	模块间通信协议能正常建立连接	抓包工具看到完整握手流程
数据正确	传输的数据内容无错码、丢包、乱序	CRC 校验通过，端到端数据一致
资源协调	中断、DMA、总线、电源等共享资源不冲突	长时间压力测试无死锁、无异常复位

你想想看，这四个目标其实是层层递进的。接口对通是基础，协议握手是前提，数据正确是保障，资源协调是最终考验。

我在一个智能家居项目中遇到过这样的情况：Wi-Fi 模组和蓝牙模组各自的数据收发都正常，但一旦同时工作，蓝牙就频繁断连。最后定位发现是它们共用了同一个 SPI 总线，DMA 通道冲突了。这就是典型的「资源协调」问题，单模块测试根本发现不了。

1.4 联调的核心价值

联调的价值，我用一句话概括：用最小的成本，暴露最多的问题。

具体来说，有这几点：

• 降低返工成本——联调阶段发现问题，改驱动或改配置就能解决。拖到系统测试，可能要改硬件。
• 缩短项目周期——联调把问题提前暴露，避免后期「拆东墙补西墙」式的救火。
• 积累调试经验——每次联调都是一次实战。你遇到的奇葩问题越多，下次就越有底。
• 提升系统可靠性——联调过的系统，稳定性明显更高。量产后的返修率能降一个数量级。

1.5 联调失败的常见原因

说点实在的。联调失败，通常逃不出这几个坑：

1. 文档不全——接口定义模糊，协议细节缺失。联调时全靠猜。
2. 时序不匹配——两个模块的时钟源不同，导致采样点偏移。
3. 电平不兼容——1.8V 和 3.3V 的模块直接对接，烧了 IO 口。
4. 中断风暴——一个模块频繁触发中断，导致另一个模块饿死。
5. 电源纹波——大功率模块启动时拉低电压，导致其他模块复位。

我曾经遇到过一个最离谱的案例：两个模块用 UART 通信，波特率都设成了 115200，但就是收不到正确数据。折腾了两天，最后发现一个模块的晶振是 16MHz，另一个是 16.384MHz，波特率误差累积到 3% 以上。嗯，从那以后我联调第一件事就是测时钟频率。

1.6 本章小结

模组联调不是什么高深的技术，但它是一门「经验活」。你踩过的坑越多，联调就越顺。

记住这几点：

• 联调测的是「连接」，不是「功能」
• 联调在单模块测试之后、系统测试之前
• 四个目标：接口对通、协议握手、数据正确、资源协调
• 核心价值：用最小成本暴露最多问题
• 常见失败原因：文档、时序、电平、中断、电源