4. I2C / SPI 驱动测试 — 项目案例
本章以真实量产项目为蓝本，拆解I2C/SPI驱动测试的面试核心。先通过STAR图快速定位项目表达结构，再展示完整项目模板，最后用3个高频问答卡巩固关键考点。
📌 真实项目模板
| 项目名称 | 智能穿戴设备I2C/SPI传感器驱动测试 |
| 业务背景 | 穿戴设备集成加速度计、陀螺仪、心率传感器，通过I2C和SPI总线与主控（ARM Cortex-M）通信，量产50k+。 |
| 规模指标 | 测试用例500+，自动化覆盖率85%，测试周期4周 |
| 技术栈 | Linux I2C/SPI子系统、设备树（Device Tree）、示波器、逻辑分析仪、Python pytest |
| 核心难点 | ① 时序协议兼容性（Clock Stretching / SPI Mode）② 多从设备总线冲突 ③ 中断响应延迟 ④ 低功耗下的唤醒时序 |
| 面试高频追问 | ▸ 如何处理I2C时钟延展？ ▸ SPI多从设备CS管理如何测试？ ▸ 高速SPI信号完整性怎么验证？ ▸ 遇到传感器无响应如何排查？ |
| 可迁移话术 | “我从系统角度出发，结合逻辑分析仪抓波形、构造边界压力、并覆盖异常恢复路径，确保驱动在量产环境下的可靠性。” |
🎯 高频面试问答
Q1：请描述I2C和SPI协议的主要差异，在驱动测试中如何验证？
考察点：协议基础理解 + 测试方法论
回答框架：先对比差异（同步/异步、主从数量、引脚、速度）➜ 再讲验证手段（波形分析、数据完整性、异常场景）
示例回答：I2C使用SCL/SDA两线支持多主多从，速度较慢；SPI用四线全双工，速度高。测试时我用逻辑分析仪抓取I2C起始/停止条件、ACK/NACK；对SPI则验证CS片选时序及CPOL/CPHA配置。同时构造总线冲突和超时场景验证驱动容错。
可能追问：I2C 10位地址如何测试？SPI Mode0/1/2/3的差异如何验证？
Q2：你在项目中如何测试I2C的时钟延展（Clock Stretching）？
考察点：I2C高级特性理解 + 异常测试能力
回答框架：解释机制（从设备拉低SCL）➜ 测试方法（构造慢速从设备、配置超时参数、波形捕获）
示例回答：我修改从设备固件使其在ACK后延时释放SCL，主机侧设置i2c-scl-timeout。用逻辑分析仪捕获SCL低电平持续时间，验证驱动进入等待重试或超时报错。边界测试包括延展周期刚好等于超时阈值的场景。
可能追问：从设备一直拉低SCL主控如何处理？如何避免系统死锁？
Q3：SPI多从设备共享总线时，如何保证片选信号不冲突？测试覆盖哪些场景？
考察点：硬件设计理解 + 总线竞争测试
回答框架：片选GPIO互斥（设备树cs-gpios + mutex）➜ 测试场景（毛刺、切换延迟、高频切换互斥）
示例回答：我们在设备树中定义每个从设备的cs-gpios，驱动用mutex保护CS操作。测试时用双通道示波器同时监控两个CS，编写脚本每500μs切换从设备，检查CS下降沿之间是否有重叠或毛刺。发现一次因GPIO配置错误导致CS毛刺，后增加去抖延迟解决。
可能追问：CS信号毛刺怎么产生的？如何通过测试复现？