企业官网建设流程全解析

做嵌入式或者折腾过I2C总线的朋友，大概率有过这种经历：代码明明检查了好几遍，从机就是不应答，你盯着SDA和SCL两个引脚干瞪眼，最后只能拿一根飞线把总线短接强制复位。这类问题碰多了以后，我养成了一个习惯——凡是板子上涉及I2C，第一步就是拿USB转I2C适配器把整条总线扫一遍，看哪些地址有应答、哪些地址被占用，同时用逻辑分析仪抓一下SCL波形，核实现总线速率到底是不是标称的100kHz。扫描结果和时序参数汇总到Excel里做一份报告，板上挂了几颗料、每颗料在哪个地址、时序余量还剩多少，一眼就能看明白。

这篇要聊的项目，标题写得很直白：USB TO I2C_(Excel)_Scan，加一个100KHz总线速率测试。拆开讲，就是用USB转I2C适配器充当主机，通过上位机完成I2C设备地址扫描，再用Excel做结果汇总和时序数据分析，最终确认总线速率是否满足100kHz标准模式的要求。整套流程对刚接触I2C的新手友好，对要批量验证板卡设备的硬件工程师同样实用。下面我把方案选型、扫描细节、速率测量方法以及实际踩过的坑都展开说一下。

1. 先把这件事拆开看：题目里的三个关键词到底指什么

1.1 USB转I2C不是串口，别拿它当“USB转TTL”用

很多人看到“USB转I2C”这几个字，下意识觉得跟USB转串口差不多，插上就有个COM口，然后按串口协议发数据。这是最容易产生误解的地方。USB转I2C适配器的本质，是把PC的USB口虚拟成一个I2C主机，它输出的不是UART电平，而是I2C的开漏总线信号，包括起始条件、停止条件、地址帧、数据帧和应答位。上位机软件发过来的不是“字符串”，而是一条条完整的I2C总线事务。

市面上常见的实现方案有三类。第一类是专用桥接芯片，比如FTDI的FT232H，内部有MPSSE引擎，可以直接硬件生成I2C时序，时钟频率可编程，从几十kHz到1MHz以上都能配；第二类是Silicon Labs的CP2112，走HID接口，免驱特性好，官方提供DLL库，适合快速做小工具；第三类是基于USB转UART芯片加一颗MCU，比如FT231X或CH340转串口再接STM32等单片机，由单片机软件模拟I2C时序。这类方案你看到的就是一个COM口，需要按它自定义的指令格式收发数据，本质上是“串口协议转I2C”，跟真正的I2C桥接芯片不同。

选哪种，取决于项目需求。要做产测、要精确控制时序、要跑100kHz甚至更高频率，建议直接上FT232H这类硬件I2C方案的适配器；如果只是手头有现成的USB转串口模块和单片机开发板，写个软模拟固件也可以，但要注意软模拟的时钟稳定性普遍不如硬件方案。项目标题里明确写了“100KHz总线速率测试”，这其实就暗示了选型方向——速率是硬指标，硬件方案优先。

1.2 Excel在这里不是办公软件，是数据分析和报告终端

题目里出现“Excel”一开始可能让人有点意外，但实际干活的人都知道，I2C扫描之后最麻烦的不是扫描本身，而是怎么把扫描结果变成一张能看的表。逻辑分析仪导出的CSV文件动辄几十万行，地址扫描日志也是一大串十六进制字符串，总要有人去整理、统计、生成结论。Excel恰好是大多数人最顺手的数据处理终端，地址清单可以用表格透视，波形数据可以导入后算周期，最后还能直接生成测试报告模板。

能实现的方式不止一种。可以用Power Query把逻辑分析仪导出的CSV拉进Excel，然后用公式做边沿检测和时间差计算；也可以让上位机把扫描结果输出成文本，再通过Excel的“数据分列”功能拆成结构化表格；更进阶的做法是用VBA写一个串口读取宏，让扫描到的地址直接填进单元格，地址应答状态自动标成“OK/NAK”。我在实际操作中倾向后者，虽然VBA调试费点功夫，但产线工人只需要点击一个按钮就能出报告，不需要教他们怎么折腾CSV。

这里有个重要的经验：Excel本身不适合处理海量原始波形。如果逻辑分析仪导出了上百万行采样数据，直接导入会让Excel卡到怀疑人生。正确做法是先做一次降采样或者只提取边沿信息，比如在Python或脚本里把每个上升沿/下降沿对应的时间点、电平值提出来，生成一个只有几百行的摘要表格，再交给Excel去算周期和速率。这样Excel只负责它擅长的统计和报表，数据吞吐的压力交给前端脚本，两边都不遭罪。

1.3 100kHz不是随便给的数字，它是I2C标准模式的硬门槛

I2C总线速率有一套完整的规范体系。我们常说的100kHz，对应的是I2C Standard Mode，也就是标准模式；再往上还有Fast Mode的400kHz和Fast Mode Plus的1MHz。标准模式之所以经典，是因为它横跨几乎所有老器件和新器件，从EEPROM、温度传感器到各种管理芯片，绝大多数都保证在100kHz下正常工作。

“总线速率100kHz”这句话，严谨地说指的是SCL时钟频率为100kHz，也就是SCL信号的周期约为10微秒。但只测周期够了不够？不够。I2C规范里对每个时序参数都有明确要求：高电平时间必须大于等于4.0微秒，低电平时间必须大于等于4.7微秒，上升沿时间不能超过1微秒，下降沿不能超过0.3微秒，起始条件建立时间要大于等于4.7微秒。也就是说，即使SCL周期刚好是10微秒，如果高电平时间只有2微秒，或者上升沿在长走线上拉出2微秒的斜坡，从机照样可能误判数据。

标题里的“100KHz总线速率测试”之所以值得单独拿出来说，就是因为很多工程师习惯性先入为主地认为“我主机设了100kHz，总线就是100kHz”，到头来在产线上出现误码，才想起来用示波器看真实波形。真正常见的坑是：主机配置没问题，但从机板上的上拉电阻选大了，总线电容一大，上升沿直接拉成一条陡坡，0到1的翻转时间接近甚至超过规范上限。这时候SCL周期可能还是10微秒，可时序已经不满足产品规格了。

2. 方案选型：桥接芯片、电平匹配、上拉电阻都不能含糊

2.1 主控桥接芯片怎么选

我以FT232H为主思路展开，因为它算出厂时间最早、生态最成熟、资料最多的方案之一。FT232H是FTDI出的USB 2.0高速转多功能接口芯片，内部带MPSSE引擎，可以配置成I2C主模式、SPI主模式或者UART模式。用在I2C上，它的优势是时钟源稳定，内部时钟可以精确分频，能配出很干净的100kHz时钟；缺点是价格比CH341之类贵不少，而且初上手要理解D2XX驱动和FT_Prog配置工具，有一定的学习成本。

如果项目追求快速落地、不想装复杂驱动，CP2112是另一个不错的方向。它本身是HID设备，Windows系统识别后基本免驱，官方SDK里直接有I2C读写函数，写上位机软件非常顺手。缺点是最高速率一般只到400kHz，而且HID轮询机制导致传输的实时性不如D2XX那么可控。

至于CH341或者FT231X加MCU的方案，成本最低，但性能上限也低。CH341的I2C功能主要通过软件模拟实现，速率稳定性完全取决于驱动和库的实现，跑400kHz容易捉襟见肘，跑100kHz倒是没什么问题，只是如果你想把它用作精确的时序验证工具，我不太推荐——它的定位是低成本编程器/调试器，不是精密测量设备。

三种方案的对比，我整理成一张表方便直观决策：

2.2 电平域匹配和上拉电阻计算

I2C是开漏结构，SDA和SCL引脚本身只负责拉低，拉高完全靠外部上拉电阻。这就带来两个绕不开的问题：总线的电平域是多少，以及上拉电阻选多大。

先看电平域。USB转I2C适配器的主流电平是3.3V，但现在很多从机是5V系统的，比如老的EEPROM、温度芯片等。如果直接用3.3V的主机去拉5V总线，SDA和SCL的高电平会被从机的上拉电阻拉到5V，而主机引脚如果耐压不够，可能直接损坏。反过来，如果用5V主机去驱动3.3V从机，从机的I/O口可能不承受5V电平。所以搞清被测板子的供电电压是第一优先级。处理办法是选择带电平转换功能的适配器，或者外接I2C电平转换芯片，比如常见的PCA9306、TXS0102等。没有电平转换的情况下，至少先确认主机的SDA/SCL引脚是否标注了“5V tolerant”。

再看上拉电阻。上拉电阻选取有两个边界约束。一个是最小值，由主从机引脚能承受的灌电流决定。公式是Rmin=(VCC - VOL_max)/I_OL_max，以3.3V总线、VOL_max=0.4V、I_OL_max=3mA为例，算出来Rmin约等于967欧姆，所以一般不建议用小于1k的上拉电阻。另一个是最大值，由上升沿时间指标和总线寄生电容决定，公式是Rmax≈tr/(0.8473×Cb)，标准模式要求tr≤1微秒，如果总线电容Cb是200pF，那么Rmax约等于5.9k。所以典型范围落在2.2k到4.7k之间，这也符合大多数开发板默认配置。

实际中一个容易被忽略的点是“多板上拉并联”。如果USB适配器内部带了上拉电阻，被测板子上也有上拉电阻，两条总线等效上拉值就是两个电阻的并联。比如两个4.7k并联是2.35k，两个2.2k并联是1.1k，问题不大；但如果两边的上拉都选得很小，并联值跌破1k，低电平就拉不下去，SDA被卡在中间电位，扫描结果就全是通信失败。我遇到过一个案例，适配器2.2k、板子2.2k，并联1.1k，配上总线电容，还能工作；后面换了个适配器也是2.2k，板子改成1k，并联只有680欧左右，波形低电平直接抬到0.9V，彻底通信断开。所以在排查I2C问题时，先把两边上拉电阻都确认一遍。

2.3 硬件连接的基本规则和禁忌

I2C连接的硬性规则其实不多，但每条都直接决定能不能出活。第一，共地。USB适配器通过USB取电，电源地跟被测板往往是隔离的，必须用杜邦线把两边的GND连在一起，否则逻辑电平根本没有参考基准。第二，SDA和SCL不要接反。听起来是废话，但实测中接反的概率非常高，尤其是那种没有丝印的裸模块。第三，不要带电拔插。I2C器件一般没有热插拔设计，带电插拔容易在引脚上打出毛刺，轻则干扰总线、重则损伤芯片。第四，接线尽量短。测试100kHz这个频率，长杜邦线不会导致信号完全失效，但会增加总线电容和环路电感，影响上升沿，进而让时序测量出现偏差。

如果你想做一个比较规范的测试环境，建议把杜邦线控制在10厘米以内，甚至直接用短飞线焊接。示波器探头可以接到SCL和SDA上，地线夹尽量靠近被测芯片的地引脚。这部分准备做好了，后面的扫描和速率测试才有意义。

3. 核心细节：I2C地址扫描的正确姿势

3.1 7位地址扫描的原理

I2C寻址最常用的是7位地址。总线事务中，SDA上的地址字节是“7位地址左移1位，最后一位是读写方向”。比如一个器件地址是0x50，在写操作时，主机发出的地址字节是0xA0；在读操作时，地址字节是0xA1。扫描程序要做的就是遍历可能的7位地址，对每个地址发送起始条件加地址字节，然后等待从机的应答位。

判断方法很简单：如果总线上有对应地址的从机存在，从机会在第9个时钟的低电平期间把SDA拉低，产生ACK回答；如果没有设备，SDA保持高电平，主机收到NACK。扫描逻辑一遍轮询，就能得到一张“哪些地址有应答”的清单。

这里要特别提醒地址表示的约定问题。不同的上位机软件对地址的显示方式不一样。有些工具显示7位地址，比如0x50；有些工具显示8位地址（含读写位），比如写地址显示0xA0。如果你拿扫描结果去对数据手册，发现明明EEPROM地址是0x50，工具却显示0xA0，很可能是工具把读写位也算进去了。我习惯在表格里同时标注“7位地址”和“8位写地址/读地址”，避免沟通时混淆。这也是为什么把扫描结果放到Excel里整理这么有用的原因——可以在表头里明确约定格式，还能加批注。

3.2 别漏掉只读器件，也别用“暴力扫描”误伤设备

扫描时只发一次“地址+写位”是不够的。很多器件对读写地址的应答情况不一样，典型的是某些只读传感器，它们可能只在读方向应答。所以稳妥的做法是每个地址都做两遍探测：一遍发送写地址，一遍发送读地址，分别记录应答结果。如果其中任意一个方向有ACK，就能判定该地址存在设备。

另一个更重要的点是扫描时的“动作要轻”。有些工具把扫描做成了“写0字节”，意思是发出地址后不附带任何数据就直接发停止条件。这本来是安全的，因为大多数从机收到起始条件和地址，但没有后续数据和停止条件时，不会执行任何写操作。但个别器件对地址的响应比较激进，比如某些EEPROM在写地址匹配后即使没有数据，也会改变内部状态或触发一次状态机跳转，甚至有概率把内部配置擦掉。更稳妥的做法是用“仅地址探测”，也就是发送起始条件+地址字节后，不等数据就发停止条件，或者直接使用只读寄存器0字节检测（read(0)方式）。我在做EEPROM扫描时，从来不用“写0字节”的方式，宁可麻烦一点，扫描前也先备份好器件配置寄存器。这种谨慎在产线上尤为重要，因为一块板子上的配置是通过I2C写进去的，一旦被扫描程序误改，问题排查成本远高于单纯扫描。

扫描范围也不是越全越好。从0x00到0x7F确实覆盖了所有7位地址，但有些地址是I2C规范保留的。0x00是广播/通用呼叫地址，0x01到0x07保留给CBUS等用途，0x78到0x7B和0x7C到0x7F等也是保留段。正规的扫描工具会把范围自动限制在0x08到0x77附近，如果你用自写脚本扫描，也建议只扫这个有效区间，避免把保留地址误报成设备。

3.3 100kHz时序规格的执行判断

速率测试也有自己的“验收标准”。下面这张表是I2C标准模式（100kHz）在常见场景下要重点核对的一组时序参数，我实际做报告时基本就是照这张表逐项打勾。

这张表的执行判断要把握一个原则：不要只看周期。SCL周期是10微秒不代表所有时序参数都合格。比如上拉电阻偏大导致上升沿特别长，虽然周期不变，但高电平时间减少、建立预算被吃掉。严格的做法是用示波器或者高采样率逻辑分析仪抓波形，通过游标测量每个时间参数，跟表里的下限值做比较。上升时间这类纳秒级参数，普通逻辑分析仪的等效采样率如果只有几百kHz，测出来的数据没有参考价值，最好用示波器直接量。

4. 实操过程：从驱动安装到Excel出报告

4.1 驱动安装与设备识别

驱动这一步看着不起眼，但第一次用FT232H时我卡了快一个小时。FT232H默认走的是D2XX驱动，在Windows设备管理器里显示为“USB Serial Converter”或类似“MPSSE设备”，而不是一个COM口。很多朋友装完驱动后习惯性打开设备管理器找COM口，找不到就以为安装失败。实际如果你需要通过虚拟串口方式访问FT232H，需要在FT_Prog等配置工具里把它的端口模式改成VCP（虚拟COM端口）模式，重新枚举后才能看见COM口。如果直接用D2XX库，就不用改模式，直接用FT_Open、FT_Write、FT_Read这一套API操作。

如果你用的是FT231X加单片机中转方案，驱动就简单多了，FT231X本质是USB转UART芯片，装好官方的VCP驱动后会出现一个标准COM口。这时上位机不需要理解I2C时序，只要按模块固件定义的指令格式通过串口发送命令就行，比如发“SCAN\r\n”让模块扫描地址，模块再通过串口回传结果。这个方案的上位机调试重点是串口参数，常见的是115200或9600，8N1格式，具体以你手里的模块说明为准。

芯片识别这一步有个排查技巧：把适配器插到电脑上，打开设备管理器，先看USB控制器部分有没有无法识别的设备。如果没有异常，再确认驱动版本和属性里的“硬件ID”是不是对应你的芯片型号。比如FT232H的硬件ID以“VID:0403 PID:6014”为主，FT231X以“VID:0403 PID:6015”为主，CH341常见“VID:1A86 PID:5523”。看到这些ID基本就能锁定芯片，接下来选驱动和上位机软件的方向就对了。

4.2 用Python脚本完成I2C扫描

基于FT232H方案，我习惯用pyftdi库写扫描脚本，因为它直接支持FT232H的MPSSE配置，代码量小，也方便把结果输出成CSV导入Excel。先安装依赖，然后在脚本里指定适配器频率为100kHz，轮询0x08到0x77范围。基本流程是：对每个地址尝试一次“零字节读”，收到ACK就记录为存在设备。

下面是一个可以直接跑的简化版本：

from pyftdi.i2c import I2cController ctrl = I2cController() # 根据设备管理器里的实际描述修改URL ctrl.configure('ftdi://ftdi:232h/1', frequency=100_000) found = [] for addr in range(0x08, 0x78): # 尝试读一个字节，目的是探测从机应答 try: ctrl.get_port(addr).read(0, start=False) found.append(addr) print(f"Found I2C device at 0x{addr:02X}") except Exception: pass ctrl.close() print(f"Scan done, total {len(found)} device(s)")

这段代码里的read(0)是“只探测不读取有效数据”，尽量不干扰从机工作状态。如果你手头不是FT232H，而是带COM口的串口转I2C模块，也可以直接用串口发送“地址探测”指令，逻辑类似。关键是扫描范围、频率设置和结果输出这三件事要清晰。

脚本跑完，把found列表输出成CSV，其实就已经具备了“扫描+Excel”的数据链。如果希望更自动化，可以在脚本里直接调用csv模块，把扫描结果、扫描时间、适配器参数都写进CSV，Excel再一键导入。

4.3 用逻辑分析仪抓波形，导出CSV

地址扫描只能回答“有没有设备”，速率测试要回答“时序合不合格”。这一步需要抓SCL波形。

最简单的做法是用逻辑分析仪，通道0接SCL，通道1接SDA，设置采样率为2MHz以上。理论上测100kHz信号，2MHz每周期能采20个点，足够看高低电平和大概的边沿趋势；但如果要较真上升沿时间，采样率至少要10MHz以上，或者直接上示波器。我自己常用的是5MHz到10MHz档位，既兼顾文件体积，也能基本分辨边沿是否过缓。

Logic软件抓到波形后，直接导出CSV，通常包含“Time”和各个通道的电平值。比如Saleae的CSV格式是：Time[s], channels..., 每一行是某一个采样时刻。文件可能非常大，实测一次1秒抓取、10MHz采样率，导出的CSV就是上百万行。所以前面讲的预处理在这儿就派上用场了。我的做法是在Python里读入CSV，把SCL通道的每一段高电平、低电平的起止时间提取出来，得到一段连续的时序摘要：

import csv rows = [] with open('saleae_export.csv') as f: reader = csv.DictReader(f) for r in reader: rows.append((float(r['Time[s]']), int(r['SCL']))) # 记录高/低电平的起止时间 segments = [] last_level = None start = 0.0 for t, level in rows: if last_level is None: last_level = level start = t elif level != last_level: segments.append((start, t, last_level)) start = t last_level = level segments.append((start, rows[-1][0], last_level)) with open('segments.csv', 'w', newline='') as f: w = csv.writer(f) w.writerow(['start_s', 'end_s', 'level']) w.writerows(segments)

这一步跑完，得到的segments.csv大约只有几千行，记录的是SCL线上每一段高/低电平的起止时间点。把它导入Excel，后续计算就非常轻松。

4.4 在Excel里计算实际速率和关键时序参数

CSV导入Excel后，我习惯这样设计工作表。Sheet1放“地址扫描结果”，表头建议是：7位地址、写方向ACK、读方向ACK、设备判定、备注。Sheet2放“时序测量”，表头是：高电平起始(s)、高电平结束(s)、高电平时长us、低电平起始(s)、低电平结束(s)、低电平时长us、周期us、当前速率kHz。

周期可以直接用相邻的上升沿时间差来计算。假设原始摘要表中，每一段的起始时间放在A列，结束时间放在B列，电平放在C列。先加辅助列，判断是否为上升沿：当C2=0且C3=1时，认为A列对应时间是一个上升沿。然后把所有上升沿时间筛选出来，放到一个新的辅助列里，比如E列。相邻两个上升沿的时间差，用=(E3-E2)*1000000得到微秒，速率用=1000000/(E3-E2)得到Hz，再除以1000变成kHz。

占空比和时序检查也有现成公式。高电平时长，用“高电平段结束减开始”再乘1e6；低电平同理。算出来后，跟标准模式对比：高电平大于4.0微秒、低电平大于4.7微秒、周期在9到11微秒之间，基本可以判定为100kHz总线速率合格。如果有任意一项超限，那就要回查硬件，优先怀疑上拉电阻和总线电容。

为了让报告更直观，我还会在Excel里插入一个SCL波形的散点图，X轴是时间、Y轴是电平，虽然只是一个方波的形状，但能直观看出占空比和边沿粗细。再配合一张“时序参数对比表”，就是一份很有说服力的速率测试报告了。

4.5 一份可供参考的实测样例

为了说清楚“什么叫做合格”，我给出一次实测的典型数据。测试条件是FT232H适配器、3.3V总线、外部上拉电阻3.3k、逻辑分析仪采样率10MHz，被测对象是一颗I2C EEPROM，速率设定为100kHz。采集结果导入Excel计算后，得到了下表。

这组数据标志着总线上在100kHz档位的时序是完全OK的。如果出现某一项标红，处理方法就得跟着变。比如上升时间超了，第一反应是降上拉电阻；低电平时间不够，要怀疑占空比配置或主机的分频设置有误；周期偏大，看看适配器是否把内部时钟分频算错档了。

5. 常见问题与排查技巧实录

5.1 扫描结果完全空白，从哪里查起

扫描一次什么都没有，这是最常见的开局。我的排查顺序固定不变：先量电压和地线，再查上拉，再降速，最后查地址格式。

具体来说，先用万用表确认被测板的VCC和GND是否正常，确认适配器与板子共地，确认SDA和SCL上有没有上拉电阻。如果手头没有原理图而板上又有未知的总线，可以直接用万用表量SDA对地电压，空载时应该接近VCC电平，如果量到0V，很可能是总线被某个器件拽住了，或者上拉没接、线上断线。如果电压正常，再把适配器速率从100kHz降到10kHz重新扫一遍，排除长线或大电容导致的时序问题。最后确认扫描工具显示的地址是7位还是8位，别把0x50看成了0xA0。

还有一个常见原因是扫描工具和被测系统“抢总线”。如果被测板上还有一颗主控MCU同时连着总线，或者被测板上的I2C设备处于休眠状态，需要先使能待测器件，否则总线冲突或者器件不应答是正常的。产线上遇到扫描空白，我通常会让板卡进入一个“待机但不占用总线”的状态再扫。

5.2 速率测出来偏差比较大，原因往往在三点

第一，主机分频计算问题。FT232H这类芯片的时钟分频受内部时钟源和相关寄存器控制，如果你设置的是100kHz，但某个寄存器值写错，实际生成的SCL可能就是92kHz或者108kHz。用示波器实测SCL周期，如果稳定在偏差值上，去查适配器的分频配置，看是不是用了错误的预分频档位。第二，上拉电阻过大。上拉电阻大，上升沿就会拉长，理论上周期不变，但测量仪器的阈值点会让人误判高低电平中点，导致测出的高电平和低电平时间不准确，进而影响对周期的判断。第三，采样率不够。逻辑分析仪采样率只有1MS/s时，测100kHz信号一个周期只有10个点，计算出的边沿时间误差会到10%甚至更多，所以测时序要用高采样率。

另外很多人在Excel里算速率时，忽略了一个细节：周期应该是“相邻上升沿之间的时间差”，而不是“相邻上升沿与下降沿之间的时间差”。如果把高低电平各算一段，再把两段相加，结果也能得到周期，但前提是同一周期的边界要对齐。我见过有同事直接把每段高电平+紧接着的低电平当周期，结果因为噪声干扰或者边沿抖动，速率忽高忽低。用上升沿到上升沿的时间差稳定性更好。

5.3 关于扫描和速率测试的老实话

最后说几句实际操作中的体会。第一，扫描EEPROM这类可写器件时，务必使用“仅地址探测”模式，不发送任何后续数据和字节。如果上位机不支持这种模式，就先断开有写保护需求的设备，或者先备份配置寄存器。我遇到过扫描程序把板子的设备地址误写的案例，原因就是它发送的探测序列里附带了一个“空写”命令，而那颗芯片恰好在启动阶段对空写有响应，直接改了内部状态。从这次以后，扫描工具的探测模式成了我选型的硬指标。

第二，Excel报告里的数据要留原始痕迹。不管是扫描清单还是时序参数，都应该保留“抓取时间、适配器型号、环境温度、测试板卡编号”这几个列。产测报告如果只有设备和速率，后期出了质量问题根本追溯不到是哪一批板子、哪一台机器、哪个时间段抓的。把这些元信息写进Excel的第一个Sheet，虽然麻烦，但真的能救命。

第三，100kHz只是起点，不是终点。能在这个速率下把扫描和时序验证跑顺了，后续要扩到400kHz甚至1MHz，只是改参数和换适配器的事。但时序测量方法、Excel分析框架、排查流程全部可以复用。这也是为什么我建议第一次做I2C总线测试就把这套流程搭起来的原因，一次性投入，后面的项目都能吃老本。