企业官网建设流程全解析

调试I2C设备最烦的一件事是什么？问十个老工程师，八个会回答：查地址。尤其是现在很多模组把好几个I2C器件挂在同一条总线上，上电后发现中途有个器件不响应，你根本不知道是地址写错了、焊接虚了，还是器件压根没起来。我这次做的USB转I2C总线扫描工具，就是为了在400KHz快速模式下把整条总线“过一遍”，快速找出哪些地址有设备响应，再把扫描结果直接整理成Excel报告存档。项目名字很朴素：USB TO I2C_(Excel)_Scan ---- 400KHz总线速率测试_A，其中_A代表第一版验证样机。这篇文章把这套工具从原理到实测的完整过程记录下来，给打算自己搭I2C调试环境的朋友做个参考。

1. 为什么非要自己做一个USB转I2C扫描工具

1.1 现货工具为什么不够用

可能有人会说，市面上几十块钱的USB转I2C模块不是一大把吗，还有逻辑分析仪、I2C调试器，为什么还要自己做？我一开始也是这么想的，但实际用下来发现几个绕不开的问题。

第一，市售模块往往自带一套上位机，功能看着齐全，但扫描逻辑是写死的。比如部分模块只能按固定顺序发送地址，不能跳过保留地址段，也不能自定义扫描重试次数。遇到总线上挂着地址0x50的EEPROM和地址0x48的传感器倒还好，可一旦遇到10位地址器件、或者需要在指定速率下反复扫同一地址区间做稳定性测试，这些工具就开始力不从心。

第二，数据导出是个大问题。很多上位机只有波形显示或者简单的十六进制读写窗口，想把扫描结果、时序参数、每轮测试的ACK情况批量导出成Excel，基本要手动整理。这对产线测试或者长时间跑老化测试的场景来说简直是噩梦。我在之前的项目里就吃过这种亏，一个晚上跑了八个小时的老化测试，第二天早上发现软件只能把结果显示在屏幕上，重启电脑全丢了，后来花了一上午从截图里一个个抄地址。

第三，速率问题。很多廉价的USB转I2C模块内部是软件模拟I2C，最高速率只有100KHz标准模式，或者号称支持400KHz但实际波形保持时间、上升沿时间根本不达标。我在示波器和逻辑分析仪上测过几款，标准模式下还能看，切到快速模式后SCL的高电平时长明显缩水，挂上多个设备后总线电容上来，有些模块直接通信失败。

1.2 这台工具的目标定位

所以这次的项目我给自己定了几个明确指标，这也是标题里“400KHz总线速率测试”的由来：

• 硬件链路必须原生支持400KHz快速模式，最好是硬件产生I2C时序，不做软件bit-banging。
• 扫描功能要可控：能自定义起始地址、结束地址、重试次数、是否跳过保留地址，能区分7位地址和10位地址器件。
• 扫描结果要落盘，直接生成Excel报告，包含每次扫描的时间戳、地址、ACK/NAK状态、读取到的设备ID（如果支持）。
• 整个工具要能脱离PC独立运行，上位机只是配置和数据查看的窗口，不能搞成上位机和硬件强绑定的封闭系统。

看清楚需求之后，选型就变得顺利了。没有哪个现成模块能完全覆盖这四个要求，所以自己做是有必要的。做之前我画过一张简单的需求对照表，把市售模块和自己DIY的差异列出来，做一个清晰的定位。

2. 硬件链路拆解：从USB命令到I2C引脚上的400KHz波形

2.1 为什么选FT2232H而不是FT231X

很多朋友看到“USB转I2C”第一反应是用USB转串口芯片加单片机做一个协议转换。确实，我一开始也考虑过用FT231X（USB转UART）加一颗STM32，STM32用硬件I2C外设去产生400KHz时序。这个方法理论上可行，但实际用下来有几个问题：

• STM32的硬件I2C虽然标称支持400KHz，但实际使用中要处理总线错误恢复、时钟延展（clock stretching）和各种标志位。如果不在中断里处理干净，很容易被其他任务打断导致时序抖动。
• 上位机和MCU之间要自己定义一套命令协议，比如“扫描地址0x03到0x77”要封装成帧，解析起来不复杂，但全是重复劳动，而且调协议比调I2C本身还耗时。
• 一旦要把逻辑分析仪抓到的时序和PC端时间对应起来，还得额外做时间同步，非常麻烦。

后来我把目光放到了FTDI的MPSSE引擎上。FT2232H、FT4232H、FT232H这几颗芯片里都内置了MPSSE（Multi-Protocol Synchronous Serial Engine），它可以在硬件层面生成兼容I2C的时序，USB命令进来之后，芯片内部的移位寄存器直接决定SCL/SDA的电平变化，不需要外部MCU参与。其中FT2232H的A通道和B通道都能独立配置为I2C模式，跑400KHz快速模式绰绰有余。

从实际接线来看，FT2232H的AD0是SCL、AD1是SDA（这是I2C模式下的固定映射），板上需要加上拉电阻，把SCL和SDA分别拉到VCC。这里有个细节容易被忽略：FT2232H的I2C模式内部虽然有弱上拉，但绝对不够驱动实际总线，必须在外部加。我初期测试直接用模块自带的2.2K上拉，后面在2.3节会详细讲这个值在不同负载下的表现。之所以不选FT231X方案，核心原因是“我在I2C协议上需要的是确定性时序，不是能用就行的近似时序”。FT2232H的MPSSE在发送时钟边沿、保持时间上都是硬件参数，天然比GPIO模拟稳定。

2.2 MPSSE发送一帧I2C数据到底发生了什么

MPSSE和普通UART最大的区别在于：UART只负责字节的收发，而MPSSE可以根据命令字在引脚上逐位输出时钟和数据。以FT2232H的I2C模式为例，上位机通过USB发送一个命令序列，FT2232H内部会完成下面这些动作：

• 命令0x0B（I2C控制命令）配合0x01参数，让SCL和SDA输出空闲高电平。
• 发送START条件命令，芯片把SDA从高拉到低，同时SCL保持高，这个边沿就构成START。
• 发送数据命令（0x11表示最低位先出的8位数据），MPSSE将这8位数据按顺序移位到SDA上，每移一位，SCL就产生一个时钟脉冲。
• 发送第9个时钟的读位命令，此时SDA切换为输入方向，芯片采样SDA电平，得到ACK位。
• 如果要结束，发送STOP条件命令，SDA在SCL为高时从低拉回高。

这几条命令组合起来就是一次完整的I2C写传输。MCU方案里要靠中断和延时来精准控制每个边沿，而MPSSE把这些全部固化在硬件状态机里，400KHz下时序抖动非常小。我们在逻辑分析仪上反复抓过，SCL高电平时间和低电平时间的偏差基本在几十纳秒以内，这个稳定性是我后来坚持用它的直接原因。

2.3 上拉电阻的取值不是拍脑袋

I2C是开漏结构，SCL和SDA只能主动拉低，不能主动拉高，高电平全靠上拉电阻把总线拉到VCC。上拉电阻的取值直接影响上升时间，而上升时间在快速模式下是硬指标。I2C规范里对于400KHz模式，上升时间最大不能超过300ns。

上升时间和总线电容、上拉电阻的关系近似为：tr ≈ 0.8473 × Rup × Cbus。也就是说，总线上每挂一个器件，引脚电容和PCB走线电容都会累加到Cbus上。我实测过一块挂了6个I2C器件的板子，总线电容大约在150pF到200pF之间。用2.2K上拉算一下：

• Cbus=100pF，tr≈0.8473×2200×100e-12≈186ns，满足300ns要求。
• Cbus=200pF，tr≈373ns，已经超标。
• 换1K上拉，Cbus=200pF时，tr≈169ns，满足要求。

所以做工具的时候，我特意把上拉电阻做成可选焊盘，默认焊1K，如果只接一个器件也可以换2.2K降低静态功耗。还有一个容易踩的点：如果总线上从设备本身就带着上拉，和外面的上拉并联之后等效阻值变小，上升时间会变快，但低电平时灌入的电流也会变大。FT2232H的I2C引脚灌电流能力有限，我不建议上拉小于1K，否则在某些异常状态下芯片可能过热甚至损坏。

3. 扫描机制与地址枚举的工程实现

3.1 I2C地址扫描的基本原理

扫描说穿了就是重复做一件事：在总线上发起一个读或写地址帧，然后看有没有设备回应ACK。I2C的7位地址帧由8个位组成，前7位是地址，最后1位是方向位。主机发送完这8位后，释放SDA并产生第9个时钟，如果总线某个从设备认领了这个地址，它会把SDA拉低作为ACK响应；如果没人认领，SDA保持高电平就是NAK。

因此扫描程序的核心循环可以写成这样：

for addr in range(start_addr, stop_addr + 1): if addr in reserved_addrs: continue ack = i2c_probe_address(addr) # 发起一次写地址帧，返回True表示ACK if ack: devices.append(addr)

这个逻辑本身不复杂，但在400KHz下要处理好几层细节。首先是保留地址段。I2C规范规定了一些特殊地址，比如0x00是广播呼叫地址、0x01是起始字节、0x02到0x03是PROTOCOL地址、0x04到0x07是保留等。这些地址不能拿来探测设备，否则要么引起总线上多个设备同时响应，要么触发特殊模式导致混乱。我通常从0x08开始扫描，一直扫到0x77，跳过0x00到0x07和0x78到0x7F。

其次是速度预算。理论上400KHz下，每个地址帧加START和STOP，总共约为9.5位时间。每一位周期是2.5us，所以探测一个地址大约23.75us。实际上MPSSE每发一条命令还有USB传输延迟，40到100us不等。我在实际测试中测过，扫完0x08到0x77这112个地址，大约耗时10到20毫秒，取决于上位机发送命令的批处理方式。最好把多条MPSSE命令拼成一个USB包传输，而不是一个地址发一次USB请求，否则速度会慢一个数量级。

3.2 10位地址器件与重试策略

扫描时不能只考虑7位地址。I2C也支持10位地址模式，这类设备在收到第一个地址帧时也会发ACK，但后续还有第二个地址字节。如果只是做一次7位地址扫描，10位地址器件会落在0x70到0x77这几个高地址段附近，容易被误认为是普通7位设备。更麻烦的是，0x70到0x77在7位地址扫描时去探测，有些10位设备会响应，有些不会，取决于它是否在等待第二个地址字节。

我在程序里做了一个双阶段扫描：第一阶段先扫0x08到0x77；第二阶段针对第一阶段命中的0x70到0x77地址，再发完整的10位地址序列去确认。10位地址的格式是11110XX开头，和7位地址空间有重叠，确认方式相对繁琐。不过在这个项目里实际遇到10位设备的机会很少，这个功能主要出于完备性考虑。

重试策略反而是更实际的问题。总线上如果挂了一些上电慢的传感器，比如某些电源管理芯片需要几十毫秒才能完成内部初始化，扫描太快可能错过它的ACK。我在程序里增加了可配置的重试次数和重试延时，默认每个地址最多探测3次，每次间隔5ms。这个设置对产线检测很有用，做过老化实验的朋友应该知道，有些器件在高温下会出现瞬时无响应，多扫几次能有效排除偶发故障。

3.3 地址冲突检测与多轮扫描比对

还有一种情况是同一个地址上有多个设备，虽然I2C规范不允许，但实际硬件设计失误时真会出现。两个设备共用地址时，一个拉低SDA、另一个也拉低SDA，从波形上看ACK还是正常的，程序会认为“这个地址有设备”。要发现这种问题，光靠扫描是不够的，必须在扫描之后对命中的地址做一次读ID操作。

我的工具在扫描结束后，会对每个命中的地址尝试读取设备ID寄存器（如果能读的话）。不同厂家的寄存器地址不一定相同，但很多器件在0x00寄存器里能读出厂商ID或设备ID。比如某些温度传感器，读0x00能得到一个固定的ID值。如果同一个地址读出的ID在两次扫描之间发生了变化，那基本可以断定总线上存在地址冲突。当然很多简单I2C器件（比如EEPROM）没有ID寄存器，这个时候就只能靠多轮扫描比对ACK的时间戳稳定性来做初步判断。

4. 400KHz速率实测：波形、时序与信号完整性

4.1 逻辑分析仪怎么抓400KHz的I2C

做I2C调试，逻辑分析仪是必备工具。但抓400KHz和抓100KHz相比，对采样率的要求完全不同。要准确还原波形，采样率至少要高于信号最高频率的4倍，实际推荐10倍以上。400KHz的SCL频率意味着一个时钟周期2.5us，加上上升沿、下降沿都在300ns以内，如果采样率只有1MHz，一个周期只能采2到3个点，根本看不出边沿形状。

我用的逻辑分析仪支持200MHz采样率，实测时我把采样率设在25MHz，也就是每个时钟周期能采到60多个点，足以看清上升沿和下降沿。抓取的时候要注意通道接法：SCL接通道0，SDA接通道1，并且要在软件里正确设置I2C协议解码器，把SCL、SDA通道映射对。很多朋友一上来就抓，抓了半天发现解码出来全是乱码，多半是通道映射或者电平极性设置错了。

抓完波形之后，先在逻辑分析仪里确认几个关键时序是否符合400KHz快速模式要求。下面这几个参数是我每次必查的：

从上表可以看到，低电平时间实测1.25us，已经略微逼近规范下限1.3us，这是因为我用的MPSSE配置把时钟占空比设置成了45%。如果继续往下压，可能不稳定。这个发现让我意识到，在这种频率下不能只看“能不能通”，还要关注具体的时序裕量。

4.2 波形上的异常：振铃、过冲与远端设备

400KHz速率下，信号完整性开始变得重要。第一次在带载情况下抓波形时，我发现SDA的上升沿有明显的振铃，过冲接近1V。原因很简单：测试用的杜邦线太长了，加上示波器探头的寄生电容，总线上等效电容远超估算值。

解决方法是把杜邦线换成双绞线或PCB走线，并在靠近FT2232H侧并联了一个100pF的电容来抑制高频振铃。并联电容会增大总线电容，所以不能随便加。我实测加100pF后，上升时间从110ns增加到150ns，仍然满足300ns要求，但振铃明显减小。如果总线电容已经很大，再利用外部电容来滤波就得不偿失了。

另外我发现一个规律：当总线上挂着多个设备，而且远端设备离适配器比较远时，波形畸变主要出现在SDA线上，SCL往往还好。这是因为SDA会在地址字节传输过程中频繁翻转，而且还要在不同设备驱动下拉之间切换。在扫描多个地址时，SDA的负载情况比SCL更复杂。所以对扫描这类高频次翻转的场景，我建议优先保证SDA的信号质量。

4.3 带载实测：扫描一块六器件主板

为了验证工具的实际能力，我在一块同时挂着6个I2C器件的板子上做了完整测试。板上的器件包括：一个温度传感器（地址0x48）、一个EEPROM（地址0x50）、一个数字电位器（地址0x2C）、一个RTC（地址0x68）、一个电源管理芯片（地址0x38）、还有一个加速度计（地址0x19）。

扫描配置为：起始地址0x08，结束地址0x77，400KHz速率，每个地址重试3次，重试间隔5ms。扫描结果如下：

• 地址0x19、0x2C、0x38、0x48、0x50、0x68：全部返回ACK。
• 除这6个地址外，其余地址均为NAK。
• 没有发现10位地址器件的间接响应。
• 多轮扫描结果完全一致，ACK的位置没有漂移。

这个结果和预期完全一致，说明扫描逻辑和硬件时序都正常工作。随后我故意把一个器件的地址引脚焊接错位，让它地址变成0x49，再次扫描后发现0x48消失、0x49出现。这验证了工具确实能用于排查实际焊接问题。

5. Excel报告生成与数据结构设计

5.1 为什么最终选了Excel而不是CSV或数据库

扫描结果最原始的形态是一串地址和时间戳。很多人会想，直接存CSV不就行了吗？CSV确实通用，但有几个问题：一是CSV没有格式，地址是十六进制还是十进制，不同人看会有歧义；二是产线或老化测试需要汇总多轮结果，CSV没法天然表达“扫描N轮”这种二维结构；三是最终要给人看，Excel里可以加条件格式、画图表、做筛选，CSV要再做一步转换。

这个项目的Excel报告我分成了三个Sheet：

• Summary：汇总扫描配置、总扫描轮次、发现设备数量、每轮扫描的时间。
• Device List：列出每轮扫描的完整地址列表，每个地址一行，标记ACK/NAK，并附带该地址读ID的结果。
• Timeline：以轮次为横轴、地址为纵轴，用颜色标记ACK状态，方便一眼看出某地址在某轮的响应情况。

为了兼容老旧的Excel环境，我直接用了xlsx格式，没有用xls。生成方式优先选择Python的openpyxl库，因为它可以方便地设置单元格格式、条件格式和图表。如果你更习惯C#，用EPPlus也可以达到同样的效果，只是处理大数据量时内存占用略高。

5.2 数据结构与导出示例

每次扫描的原始数据，程序里用一个字典保存：

scan_data = { "timestamp": "2025-01-12 14:33:22.451", "rate": 400, "start_addr": 0x08, "stop_addr": 0x77, "retries": 3, "results": { 0x19: {"ack": True, "id": 0xE1}, 0x2C: {"ack": True, "id": None}, # ... 0x6A: {"ack": False, "id": None} } }

写入Excel时，地址统一用“0x”前缀的十六进制，这是为了避免十进制和十六进制在地址识别上的混乱。我见过不止一个同事把I2C地址0x50直接当成十进制的50去查数据手册，结果半天找不到器件。在这个报告里，设备地址全部用两个字符的十六进制补零显示，例如0x50写成0x50，0x0A写成0x0A。

生成Excel的简化代码如下：

from openpyxl import Workbook from openpyxl.styles import PatternFill wb = Workbook() ws = wb.active ws.title = "Device List" # 表头 ws.append(["Address", "ACK", "Device ID", "Scan Round"]) # 遍历结果 for addr, info in device_map.items(): ws.append([ f"0x{addr:02X}", "ACK" if info["ack"] else "NAK", f"0x{info['id']:02X}" if info["id"] is not None else "-", info["round"] ]) # 条件格式：ACK为绿色，NAK为红色 green_fill = PatternFill(start_color="C6EFCE", end_color="C6EFCE", fill_type="solid") red_fill = PatternFill(start_color="FFC7CE", end_color="FFC7CE", fill_type="solid") for row in ws.iter_rows(min_row=2, min_col=2, max_col=2): for cell in row: if cell.value == "ACK": cell.fill = green_fill elif cell.value == "NAK": cell.fill = red_fill wb.save("i2c_scan_report.xlsx")

如果你只需要在命令行快速验证，也可以先输出CSV再让Excel打开转换。但自动化产线场景里，直接生成带格式的xlsx文件会专业很多。

5.3 从波形数据到Excel：原始数据还能怎么用

除了扫描结果，我还会把逻辑分析仪导出的时序数据做二次处理，生成一份“时序参数报告”附在Excel里。逻辑分析仪软件（比如Saleae）支持导出CSV，里面每一行是一个采样的时间戳和电平状态。用Python读取这个CSV后，可以自动计算SCL的高电平时长、低电平时长、上升时间、下降时间等参数。

这个功能对排查调试很有用。有一次我发现某个器件在400KHz下偶尔读取错误，但手工看波形看不出问题。后来用脚本批量分析了一万多个时钟周期，发现其中有个别周期的低电平时长比规范值短了将近200ns。这种偶发性时序劣化靠肉眼根本抓不到，只有靠自动化统计才能发现。

Excel报告里我放了一个时序统计Sheet，对每个抓取的I2C事务，统计SCL高电平/低电平时间的最大值、最小值、平均值和标准差。如果标准差超过50ns，我就会警惕这条总线的稳定性。这个做法挽救了我不少调试时间，强烈建议在做I2C工具时把这个功能加上。

6. 实测中踩过的坑与排查思路

6.1 扫描引发从设备状态异常

第一次做全地址扫描时，扫完之后发现总线上某个EEPROM里的数据被改了。排查了很久才意识到问题出在扫描这个动作本身。我扫的地址范围是0x08到0x77，其中0x50正是那块EEPROM的地址。扫描程序发送的是“写地址帧”加STOP，按理说只是探测地址，不应该触发写入操作。

但问题是，部分EEPROM对地址帧之后的第一个数据字节比较敏感。如果扫描程序在发送地址帧后继续多发了一个字节（比如某些MPSSE库自动补发的数据），EEPROM会把它当作第一个要写入的字节地址，进而进入写状态。之后如果再补一个数据字节，就可能真的把数据写进去。

这个坑让我学会了两个教训：第一，扫描探测帧必须严格控制在“START + 地址字节 + ACK位 + STOP”，一个多余的位都不要发；第二，扫描地址范围要能配置，对已知有写副作用的器件地址，要支持在配置里排除。我在程序的扫描配置里增加了一个“黑名单地址”字段，默认排除0x50到0x57这段（常见EEPROM区间），除非用户显式开启。

6.2 上电时序导致的首次扫描误报

还有一次在检测一块新板子时，扫描结果显示地址0x20、0x21、0x22同时都有设备，但硬件设计图上只画了一个I2C器件。反复检查原理图也没发现三路I2C扩展，后来重新看扫描时间戳才发现，这三个地址的ACK出现在同一轮扫描中，而且是在上电后极短的时间内。破案的关键是：板上的那颗FPGA还在配置阶段，I2C引脚处于高阻态，外部上拉让SDA在采样窗口偶然表现为低电平，于是软件误判为ACK。

这个问题的本质是总线上存在“假ACK”。在高阻态或上电不稳定阶段，SDA既没被拉低也没被拉高，逻辑分析仪采到时可能是低电平。解决办法有两个：一是扫描前延时等待，等板上所有器件完成上电初始化后再开始；二是对每个命中的地址做二次确认，第一次ACK后隔几毫秒再探测一次，只有连续两次都是ACK才当作真设备。我的工具里两种方案都实现了，默认是“上电延时500ms + 每个地址两次确认”。

6.3 地址格式和大小端引发的Excel混乱

代码写完之后，我在测试阶段发现一个很尴尬的问题：同样一张板子，同事用我的XLS报告是6个地址，他自己手动统计也是6个地址，但把报告拿给供应商看时，供应商说少了一个。最后发现是大小端和数据格式的问题——同一个RTC芯片在数据手册里写的是“地址0x68（7位格式）”，但供应商的测试报告里写的是“0xD0（8位含读方向的格式）”。

7位地址0x68左移一位变成0xD0，加上读方向位就是0xD1。不同厂家数据手册的习惯不一样，有的写7位地址，有的写8位地址，还有的写“读地址0x51写地址0x50”。这导致Excel报告在跨团队协作时非常容易引起误解。我最终的方案是在Excel报告的Device List里同时输出三列：7位地址、8位写地址、8位读地址。这样不管对方习惯哪种写法，都能直接对上。

这个细节虽然不涉及技术难点，但在实际协作中特别容易被忽略。如果你做类似工具，我建议从一开始就把地址格式设计全面，不要等到被供应商打回来再改。

6.4 电气意外：SDA被锁死的恢复机制

400KHz扫描过程中还会遇到一个比较头疼的问题：SDA被总线上的某个从设备拉低，导致整个总线卡住。这通常发生在对地址的探测与某些设备内部状态机冲突时，尤其是带写保护的EEPROM、电源管理芯片这类需要特定初始化序列的器件。一旦SDA被拉死，再不处理，MCU或MPSSE发什么命令都无效。

解决这类卡死问题，业界常用办法是“9个时钟脉冲恢复法”：在SCL上连续产生9个时钟脉冲，同时让SDA处于释放状态。大多数从设备在接收到9个SCL脉冲后会释放SDA。我在上位机软件里内置了一个紧急恢复按钮，点击后自动发送9个时钟脉冲，然后再发STOP。实测下来，90%以上的SDA锁死能靠这个恢复。剩下10%的情况只能把设备断电重启，这个硬件上也设计了电源控制引脚，方便远程断电。

这个机制在调试阶段不起眼，但量产阶段非常有用。我在测试中发现，只有在对某个特定地址序列连续扫描多轮时，才会很小概率触发SDA锁死。如果不做自动恢复，产线测试就会频繁卡住。加上恢复机制后，即使偶尔卡住也能自动恢复，不影响长时间运行。

6.5 同类问题举一反三：扫描之外的I2C调试提醒

走过这一轮之后，我发现很多I2C调试的坑都源于“以为地址对了就万事大吉”。实际上，I2C的高频调试涉及电气特性、时序裕量、器件上电状态、地址格式，任何一个环节出问题都可能导致通信失败。强烈建议在做I2C工具或调试I2C设备时，至少备齐三样东西：

• 支持200MHz以上采样率的逻辑分析仪，这是看时序细节的底线。
• 可配置扫描范围的上位机工具，能让你自由控制探测逻辑。
• 总线空闲时的存储示波器或慢扫描模式，用来捕获瞬时性的异常。

单纯靠一块万用表测通断，在低速I2C场景里还能勉强对付，到400KHz这种速率下基本是盲人摸象。工具本身的成本不高，但省下的调试时间绝对值得。

我个人的体会是，这套USB转I2C扫描工具做完之后，最大的收获不是“能扫地址”这个功能本身，而是它逼着我把I2C的时序参数、上拉电阻计算、地址格式规范、异常恢复机制从头到尾捋了一遍。后来再遇到设备不响应或者数据错乱的问题，我基本能快速定位到具体环节：先看波形确认时序，再看地址格式，最后查上电顺序，一查一个准。

如果你也打算做一个类似的工具，我的建议是先把方案定下来：硬件上用MPSSE方案的芯片打底，上位机用Python或者C#写都行，关键是扫描逻辑里要提前考虑保留地址、重试机制和SDA锁死恢复。这几个功能一开始不做进去，后面加会非常痛苦。最后别忘了，总线上拉电阻一定要根据实际总线电容计算，别照搬参考设计。