做嵌入式或者折腾过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倒是没什么问题只是如果你想把它用作精确的时序验证工具我不太推荐——它的定位是低成本编程器/调试器不是精密测量设备。三种方案的对比我整理成一张表方便直观决策方案速率范围驱动复杂度成本适用场景FT232H可编程几十kHz到MHz级需要D2XX/FT_Prog较高产测、时序验证、高速I2CCP2112最高400kHzHID免驱SDK简单中等快速工具、便携上位机CH341/USB-UARTMCU依实现而定100kHz可用COM口或专用库低低成本调试、临时搭建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_max0.4V、I_OL_max3mA为例算出来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周期T_SCL约10微秒对应100kHz允许微小偏差高电平时间t_HIGH5微秒左右大于等于4.0微秒低电平时间t_LOW4.8微秒左右大于等于4.7微秒上升时间t_r越小越好小于等于1000纳秒下降时间t_f越小越好小于等于300纳秒START建立时间t_SU;STA不小于6微秒大于等于4.7微秒STOP建立时间t_SU;STO不小于5微秒大于等于4.0微秒这张表的执行判断要把握一个原则不要只看周期。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或96008N1格式具体以你手里的模块说明为准。芯片识别这一步有个排查技巧把适配器插到电脑上打开设备管理器先看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, frequency100_000) found [] for addr in range(0x08, 0x78): # 尝试读一个字节目的是探测从机应答 try: ctrl.get_port(addr).read(0, startFalse) found.append(addr) print(fFound I2C device at 0x{addr:02X}) except Exception: pass ctrl.close() print(fScan done, total {len(found)} device(s))这段代码里的read(0)是“只探测不读取有效数据”尽量不干扰从机工作状态。如果你手头不是FT232H而是带COM口的串口转I2C模块也可以直接用串口发送“地址探测”指令逻辑类似。关键是扫描范围、频率设置和结果输出这三件事要清晰。脚本跑完把found列表输出成CSV其实就已经具备了“扫描Excel”的数据链。如果希望更自动化可以在脚本里直接调用csv模块把扫描结果、扫描时间、适配器参数都写进CSVExcel再一键导入。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列。先加辅助列判断是否为上升沿当C20且C31时认为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计算后得到了下表。参数实测值标准模式要求判定SCL周期10.03微秒对应100kHz约10微秒PASS高电平时间5.21微秒大于等于4.0微秒PASS低电平时间4.82微秒大于等于4.7微秒PASS上升时间412纳秒小于等于1000纳秒PASS下降时间167纳秒小于等于300纳秒PASSSTART建立时间5.9微秒大于等于4.7微秒PASSSTOP建立时间4.8微秒大于等于4.0微秒PASS这组数据标志着总线上在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总线测试就把这套流程搭起来的原因一次性投入后面的项目都能吃老本。