1. 项目缘起与整体设计思路1.1 这个测试到底在测什么先把标题拆开看USB TO I2C指的是用一颗 USB 转 I2C 的桥接芯片把 PC 端的 USB 接口虚拟成一个 I2C 主机从而让电脑能直接读写挂在 I2C 总线上的从机设备Excel在这里不是拿来算账的而是作为测试数据的记录与呈现载体把扫描结果、时序数据、速率统计整理成表格Scan是扫描动作通常指遍历 I2C 的 7 位地址空间0x00~0x7F把总线上有应答的从机地址全部找出来100KHz 总线速率测试则是整个项目的核心指标——验证这套 USB 转 I2C 方案在标准模式Standard-mode100 kbit/s下能否稳定跑通误码率、时序余量、连续读写吞吐是否达标。一句话概括用 PC 通过 USB 转 I2C 桥接器在 100KHz 速率下扫描总线上的 I2C 设备并把全过程的数据用 Excel 记录下来做分析。这套东西听起来简单但真正做过的人都知道坑主要集中在三块桥接芯片的固件与驱动、I2C 时序在 100KHz 下的实际波形质量、以及上位机软件对扫描结果的组织方式。适合谁看如果你手上有传感器、EEPROM、IO 扩展芯片这类 I2C 从机想用电脑快速验证它们能不能正常工作又不想每次都搬出示波器和单片机开发板那这套方案就是给你准备的。哪怕你之前只玩过 USB 转串口只要理解 I2C 的基本时序跟着做下来问题不大。1.2 为什么选 USB 转 I2C 而不是单片机方案传统做法是拿一块 STM32 或者 Arduino写段扫描代码通过串口把结果打印出来。这个方案成熟、便宜但有几个绕不开的麻烦每次改扫描逻辑都要重新编译烧录串口打印的格式固定想导出成表格还得手动复制粘贴多设备并行测试时一块板子只能管一条总线。USB 转 I2C 桥接方案的优势在于上位机软件可以随时改扫描策略扫描结果直接落成结构化数据Excel 一键导出。桥接芯片负责把 USB 协议翻译成 I2C 时序PC 端只管发指令、收数据。对于需要反复扫描、批量记录、做数据比对的场景效率提升非常明显。常见的桥接芯片有几类一类是专用 I2C 桥接器固件里已经把 I2C 时序做死了上位机通过厂商提供的 DLL 或命令行工具调用另一类是通用 USB 转 UART 芯片比如 FT231X、FT232R 这类配合 MCU 或者直接用 GPIO 模拟 I2C。前者省事但灵活性差后者灵活但时序要靠软件保证。本次测试我选的是专用桥接方案原因是 100KHz 这个速率对时序一致性要求不低软件模拟容易在连续读写时抖动。1.3 Excel 在测试链路里的角色定位很多人会问测试数据为什么要用 Excel直接打印到终端不行吗行但不好用。I2C 扫描一次 128 个地址每个地址要记录应答状态、读写耗时、错误码如果再加上连续读写的吞吐统计数据量轻松上百行。终端里看还行想对比两次扫描的差异、想画个速率分布图、想发给同事看Excel 就是最顺手的载体。我的做法是上位机扫描程序把每次操作的时间戳、地址、操作类型、结果、耗时全部写成 CSV然后用 Python 的 openpyxl 或者 pandas 读进来做二次加工——比如按地址排序、标记异常项、生成速率统计表。这样既保留了原始数据又能快速出报告。Excel 在这里不是记录工具而是分析工具。提示CSV 和 xlsx 的选择上如果只是记录原始数据CSV 足够且写入快如果需要多 sheet、公式、条件格式那就直接写 xlsx。我一般先用 CSV 落盘分析阶段再转 xlsx。2. 核心细节解析与实操要点2.1 桥接芯片选型与驱动安装桥接芯片是整个链路的咽喉。选型时我主要看三个参数支持的 I2C 速率上限、USB 端延迟、以及厂商提供的上位机 API 是否友好。100KHz 属于 I2C 标准模式绝大多数桥接芯片都支持但支持和稳定跑是两回事。有些芯片标称 400KHz实际在 100KHz 下连续读写时会出现时钟拉伸Clock Stretching处理不当的问题导致从机应答丢失。驱动安装这块FT 系列芯片FT231X、FT232R在 Windows 下需要装 VCP 驱动装完之后设备管理器里会出现一个虚拟串口。注意如果驱动装的是 D2XX 模式而不是 VCP 模式串口是看不到的但 D2XX 模式下延迟更低适合对时序敏感的场景。我这次测试用的是 VCP 模式因为上位机软件走的是串口协议调试起来直观。安装完驱动后务必用厂商提供的工具确认芯片能被识别并且 I2C 时钟频率可以配置。有些桥接器的时钟是固定分频的只能选 100KHz 或 400KHz 几档有些则支持任意频率设置。测试 100KHz 时要确认实际输出的 SCL 频率是不是真的 100KHz——用示波器量一下最保险没有示波器的话可以通过读写已知时序的 EEPROM 来间接验证。2.2 I2C 100KHz 时序的关键约束I2C 标准模式对时序有明确规定这些数字不是随便定的每一条都对应着总线上的物理特性参数标准模式要求说明SCL 时钟频率0~100 kHz本次测试目标值起始条件保持时间≥ 4.0 μsSDA 拉低到 SCL 拉低之间SCL 低电平时间≥ 4.7 μs时钟低相位SCL 高电平时间≥ 4.0 μs时钟高相位数据建立时间≥ 250 nsSDA 稳定到 SCL 上升沿数据保持时间≥ 0 ns标准模式SCL 下降沿后 SDA 保持停止条件建立时间≥ 4.0 μsSCL 拉高到 SDA 拉高之间100KHz 意味着一个 SCL 周期是 10μs高低电平各占一半的话就是 5μs。但实际波形不可能完美对称加上上升沿下降沿的过渡时间真正留给数据稳定的窗口比理论值小。如果桥接芯片的 GPIO 驱动能力不足或者总线上拉电阻偏大上升沿会变缓导致有效高电平时间被压缩从机可能采样不到。上拉电阻的选择是个经典问题。常见值是 4.7kΩ但在 100KHz 下如果总线电容较大比如挂了多个从机、走线较长4.7kΩ 可能让上升沿太慢。经验公式是上升时间 tr ≈ 0.847 × R × C要求 tr ≤ 1000ns标准模式。假设总线电容 100pF那么 R ≤ 1000ns / (0.847 × 100pF) ≈ 11.8kΩ。所以 4.7kΩ 在多数场景下是安全的但如果电容超过 200pF就要考虑降到 2.2kΩ 甚至更低。2.3 扫描策略全地址遍历还是定向探测扫描 I2C 总线最直接的方式是遍历 0x00 到 0x7F 共 128 个 7 位地址对每个地址发一个起始条件 地址字节 读/写位看从机是否拉低 SDA 应答。有应答就记录没应答就跳过。但这里有个细节有些地址是保留地址比如 0x00 是通用呼叫地址0x01 是 CBUS 地址0x02~0x07 是不同协议的保留地址。扫描时可以把这些排除掉减少无效操作。另外10 位地址设备的扫描方式不同本次测试只针对 7 位地址。扫描的粒度也值得考虑。如果总线上设备不多全地址扫描一次也就几百毫秒但如果总线电容大、上拉弱每次无应答的地址都会产生一个完整的起始-停止序列累积起来时间不短。我的做法是先做一次快速全扫描只记录有应答的地址然后针对这些地址做详细的读写测试。这样既不会漏设备又不会在无效地址上浪费时间。2.4 数据记录格式设计Excel 表格的列设计直接决定了后续分析的便利性。我一般会包含这些字段时间戳精确到毫秒用于分析操作间隔操作类型扫描、读、写设备地址7 位地址的十六进制表示寄存器地址如果是寄存器读写记录寄存器偏移数据长度本次传输的字节数结果成功/NAK/超时/错误码耗时μs从起始条件到停止条件的总时间理论耗时μs根据字节数和 100KHz 速率计算的理论值效率比实际耗时/理论耗时反映总线利用率有了这些字段后面做速率分析就很简单了。比如理论耗时可以这样算起始条件 地址字节8 位 1 位应答 数据字节8 位 1 位应答× N 停止条件。每个位在 100KHz 下是 10μs所以一个字节加应答是 90μs。如果实际耗时远大于理论值说明总线被拉伸或者桥接器有额外开销。3. 实操过程与核心环节实现3.1 硬件连接与上电检查硬件连接看起来简单但顺序有讲究。我的标准流程是断电状态下连接所有线缆USB 线接桥接器桥接器的 SDA/SCL/GND 接目标板。注意 SDA 和 SCL 都要接上拉电阻如果目标板上已经有上拉就不要重复加否则等效电阻变小驱动电流可能超标。确认电平匹配桥接器的 IO 电平通常是 3.3V 或 5V目标板的 I2C 电平必须一致。如果一个是 3.3V 一个是 5V需要电平转换。我见过有人直接把 5V 的桥接器接到 3.3V 的传感器上结果传感器 I2C 引脚被拉高到 5V长期工作后损坏。上电顺序先给目标板上电再插 USB。原因是有些桥接器在上电瞬间会输出不确定电平如果目标板还没准备好可能误触发从机的起始条件检测。用万用表确认静态电平SDA 和 SCL 在空闲时都应该是高电平。如果有一个是低说明总线被拉死了可能是某个从机故障或者上拉缺失。3.2 桥接器配置与 100KHz 时钟设置桥接器的配置方式取决于具体型号。以常见的 USB 转 I2C 模块为例通常有几种配置途径厂商 GUI 工具图形界面里选时钟频率、上拉使能、超时时间等配置完写入芯片的 EEPROM。命令行工具适合脚本化比如通过串口发送配置指令。上位机 API在代码里动态设置灵活性最高。我这次用的是命令行配置因为要反复切换 100KHz 和其他速率做对比。配置指令的大致形式是设置分频系数假设桥接器内部时钟是 12MHz要得到 100KHz 的 SCL分频系数就是 12M / 100k 120。但实际芯片的分频逻辑可能是 2 倍或 4 倍关系需要查数据手册确认。配置完成后必须验证实际时钟频率。没有示波器的话可以用一个已知的 I2C EEPROM 做基准测试写一个字节读回来如果数据正确说明时序基本正常。更严格的做法是读 EEPROM 的时序参数页有些 EEPROM 会记录自己的访问时间。注意有些桥接器在 100KHz 下默认开启了时钟拉伸支持但如果从机不支持拉伸反而会导致通信异常。测试时要确认这个选项的状态。3.3 扫描程序的实现逻辑扫描程序的核心是一个循环遍历地址 0x08 到 0x77排除保留地址对每个地址执行一次写 0 字节操作——也就是只发起始条件 地址字节 写位看从机是否应答。如果应答记录地址如果 NAK 或超时跳过。伪代码大概是这样import serial import time import csv ser serial.Serial(COM3, 115200, timeout0.1) def i2c_probe(addr): # 构造探测指令具体协议取决于桥接器 cmd build_probe_command(addr) start time.perf_counter() ser.write(cmd) resp ser.read(2) elapsed (time.perf_counter() - start) * 1e6 # 转微秒 if len(resp) 2 and resp[0] 0x00: return True, elapsed return False, elapsed results [] for addr in range(0x08, 0x78): ack, t i2c_probe(addr) results.append({ timestamp: time.strftime(%Y-%m-%d %H:%M:%S), address: hex(addr), ack: ack, elapsed_us: round(t, 2) }) time.sleep(0.001) # 地址间留间隔避免总线拥塞 with open(scan_result.csv, w, newline) as f: writer csv.DictWriter(f, fieldnamesresults[0].keys()) writer.writeheader() writer.writerows(results)这段代码的关键点在于每次探测后要留一点间隔不要连续轰炸总线。虽然 I2C 协议本身允许连续操作但桥接器的 USB 传输有延迟连续发指令可能导致缓冲区溢出。1ms 的间隔在 128 个地址上总共增加 128ms完全可以接受。3.4 连续读写速率测试扫描只能证明设备存在要测 100KHz 下的真实速率得做连续读写。我选了一个 EEPROM 作为测试对象因为它支持页读写可以一次性传输多个字节便于计算吞吐。测试方法是从地址 0x00 开始连续写 32 个字节然后连续读 32 个字节重复 100 次记录每次的耗时。理论耗时计算如下写操作起始(1) 地址字节(9位) 寄存器地址(9位) 32 数据字节(9×32) 停止(1) 1 9 9 288 1 308 个位时间100KHz 下每个位时间 10μs所以理论耗时 308 × 10 3080μs读操作类似但多了重复起始条件和地址字节大约 320 个位时间理论 3200μs实测下来如果桥接器效率高实际耗时应该在理论值的 1.1~1.3 倍之间。超过 1.5 倍就说明有瓶颈可能是 USB 传输延迟、桥接器固件开销、或者总线被拉伸。我把 100 次测试的数据全部写进 Excel用条件格式标出耗时超过理论值 1.5 倍的记录。结果发现前几次操作耗时偏高后面逐渐稳定——这是典型的 USB 首次传输开销属于正常现象。3.5 Excel 数据整理与可视化原始 CSV 导入 Excel 后我做了几件事添加计算列理论耗时、效率比、是否异常。生成透视表按操作类型统计平均耗时、最大耗时、异常次数。画散点图横轴是测试序号纵轴是效率比直观看出稳定性。条件格式效率比 1.5 标红 1.1 标绿。Excel 的公式我用得不多主要是AVERAGEIF、MAXIFS和IF嵌套。比如效率比异常判断IF(效率比1.5, 异常, IF(效率比1.3, 偏高, 正常))。透视表则用来快速汇总不同地址、不同操作类型的表现。提示如果数据量超过几万行Excel 会变卡。这时候可以先用 pandas 做聚合只把汇总结果写进 Excel原始数据留在 CSV 里备查。4. 常见问题与排查技巧实录4.1 扫描不到任何设备这是最常见的问题可能原因和排查顺序如下现象可能原因排查方法全地址无应答总线未上拉万用表测 SDA/SCL 空闲电平应为高全地址无应答桥接器未配置为 I2C 模式检查配置工具里的模式设置全地址无应答SDA/SCL 接反对照桥接器和目标板丝印部分地址应答地址冲突或保留地址确认从机实际地址排除保留段偶发应答时序余量不足降低速率到 50KHz 测试若正常则说明 100KHz 下时序紧张我遇到过一次全地址无应答折腾了半天发现是桥接器的 I2C 功能默认关闭需要在配置工具里手动使能。这种问题看文档就能避免但文档往往写得含糊实际踩一次就记住了。4.2 100KHz 下通信不稳定如果扫描能过但连续读写时偶尔出错通常是时序问题。排查思路用示波器看波形重点看 SCL 上升沿是否太缓、SDA 在 SCL 高电平期间是否稳定。如果上升沿超过 1μs考虑减小上拉电阻。检查时钟拉伸有些从机在数据处理慢时会拉低 SCL如果桥接器不支持拉伸就会丢数据。可以在配置里开启拉伸支持或者降低速率。减少总线电容缩短走线、减少挂载设备、使用更粗的线材。增加操作间隔USB 传输有缓冲连续操作太快可能导致桥接器内部 FIFO 溢出。实测中我发现把上拉电阻从 4.7kΩ 换成 2.2kΩ 后100KHz 下的误码率从 0.5% 降到了 0。代价是静态电流增加了约 1.5mA对于低功耗场景需要权衡。4.3 Excel 数据导入后格式错乱CSV 导入 Excel 时十六进制地址可能被识别成科学计数法时间戳可能被识别成日期。解决办法导入时选择文本格式或者用数据→从文本/CSV向导手动指定每列类型。在 CSV 里给十六进制地址加前缀比如0x50而不是50Excel 会当成文本。时间戳用 ISO 格式2024-01-01 12:00:00.000Excel 识别率较高。如果已经导入错了可以用TEXT函数转换比如TEXT(A2, 0x00)把数字转成两位十六进制。4.4 桥接器驱动冲突Windows 下同时装过多个 USB 转串口驱动时可能出现设备管理器里显示黄色感叹号。解决步骤卸载所有相关驱动勾选删除驱动程序软件。拔掉设备重启电脑。重新插入设备让系统自动安装或者手动指定厂商驱动。如果还是不行检查是否有其他软件占用了串口比如串口监视器、Arduino IDE 等。我遇到过 FT232R 和 CH340 驱动冲突的情况最后是通过在设备管理器里手动更新驱动、指定 INF 文件解决的。这类问题没有通用解只能根据具体芯片型号找对应驱动。4.5 速率测试结果波动大如果连续读写测试的效率比忽高忽低可能是 PC 端负载波动导致的。USB 传输受 CPU 调度影响后台程序多的时候延迟会增加。建议测试时关闭不必要的后台程序。用高性能电源模式避免 CPU 降频。增加测试次数取平均值而不是单次值。如果条件允许用实时操作系统或者独占 CPU 核心。我在一台老笔记本上测试时效率比在 1.2 到 2.0 之间跳换了台式机后稳定在 1.15 左右。这说明 PC 端性能对测试结果有实质影响报告里要注明测试环境。5. 测试结果分析与经验总结5.1 100KHz 下的实际吞吐表现经过多轮测试我整理了一份典型数据操作类型数据长度理论耗时(μs)实测平均(μs)效率比扫描单地址0 字节901051.17写 EEPROM32 字节308035401.15读 EEPROM32 字节320037801.18写 IO 扩展1 字节1802201.22读传感器2 字节2703401.26效率比在 1.15~1.26 之间说明桥接器的开销控制得不错。读操作比写操作效率略低因为读操作需要主机发送地址后切换方向多了几个时钟周期。传感器读的效率比最高可能是因为传感器内部处理时间较长时钟拉伸拉低了有效速率。5.2 影响速率的关键因素排序根据我的测试数据影响 100KHz 下实际速率的因素从大到小排列从机响应速度如果从机需要时钟拉伸实际速率会明显下降。USB 传输延迟每次操作都有 USB 往返批量操作时影响被摊薄。总线电容与上拉影响上升沿时间进而影响有效时钟占空比。桥接器固件开销不同厂商的固件效率差异可达 20%。PC 端调度在高负载下可能引入毫秒级抖动。5.3 几个让我踩坑的细节第一个坑地址扫描时忽略了保留地址。一开始我把 0x00 到 0x7F 全扫了结果 0x00 总是有应答——那是通用呼叫地址所有从机都会响应。后来改成从 0x08 开始扫干净多了。第二个坑上拉电阻重复加。目标板上已经有 4.7kΩ 上拉我又在桥接器侧加了 4.7kΩ等效 2.35kΩ静态电流翻倍。虽然通信正常但功耗上去了。后来只保留一侧上拉。第三个坑Excel 时间戳精度不够。默认格式只到秒而 I2C 操作是微秒级。后来改成自定义格式yyyy-mm-dd hh:mm:ss.000才能看出操作间隔。第四个坑连续测试时没有清空桥接器缓冲区。如果上一次操作的响应还没读完就发下一条指令会导致数据错位。解决办法是每次操作后读空缓冲区或者用带帧头的协议。5.4 后续可以扩展的方向这套方案跑通之后可以往几个方向延伸一是加入自动报告生成每次测试完自动出 Excel 图表二是支持多桥接器并行同时测多条总线三是把扫描结果和已知设备数据库比对自动识别设备类型。这些都不难核心链路已经通了剩下的就是工程化的事。我个人在实际操作中的体会是USB 转 I2C 测试看起来简单但真正决定成败的是细节——上拉电阻的一个数量级、驱动模式的一个选项、Excel 格式的一个设置都可能让结果差之毫厘谬以千里。把每个环节都验证到位比追求花哨的功能更有价值。
