1. 标题信息量拆解这份扫描Excel背后藏着什么条件像USB TO I2C_(Excel)_Scan ---- 1000KHz总线速率测试_A这种文件名我每次在项目文件夹里看到都会多看两眼。它不像随手保存的scan1.xlsx而是把硬件方案、动作、输出格式、总线速率、测试维度全塞进了名字里。这意味着这个文件不是临时看看用的而是要留档、要追溯、要和别人对齐的测试记录。拆开看USB TO I2C 说的是链路形态上位机通过 USB 口接一个转接工具工具再把指令转成 I2C 总线上的电平时序。PC 本身没有原生 I2C 控制器所以这层桥必须存在。Excel Scan 说明这次扫描动作不仅要找设备还要把结果结构化导出方便后续筛选、排序、对比。1000KHz 是整个文件名里最敏感的参数——这是 I2C 规范里的 Fast Mode Plus 档1MHz不是默认 100kHz也不是常见的 400kHz。最后那个 _A 可以理解成通道 A、板卡 A、或者第 A 轮测试无论哪一种它都提醒我这套记录不止一个维度单靠一句话文件名还不够Excel 里的字段设计也得跟上。1.1 USB TO I2C意味着什么方案I2C 总线本身只有两根线SCL 和 SDA再加上地线。但如果想用电脑直接操作必须有一个桥接设备把它枚举成 USB 设备再由上位机软件通过 USB 发指令。市面上的 USB 转 I2C 工具芯片方案就那么几种FTDI 的 FT232H/FT2232H 走 MPSSE 引擎CH341A 走厂商私有指令CP2112 走 HID 免驱协议还有用 STM32 自建固件、通过 USB 虚拟串口下发指令的 DIY 方案。文件标题里不写具体芯片只写 USB TO I2C说明写文件名的人更关心链路抽象而不是某颗芯片。但等到真正测 1MHz芯片区别就大了。FT232H 的 MPSSE 引擎可以靠分频产生接近 1MHz 的时钟CH341A 常规驱动下一般到不了这个速度CP2112 的 HID 协议本身也有事务开销跑满 1MHz 非常困难。所以这个文件名如果对应的是实测有效数据那硬件方案大概率是 FT232H 一类的高速桥接芯片或者是一套精心调过的 STM32 主控方案。拿到文件先看硬件这步不亏后面测不出来也好定位是哪一层的问题。1.2 Excel Scan与“1000KHz总线速率测试”的组合含义我一直认为 I2C 扫描是个看起来简单、做起来要命的活。简单在于只需发送 start 条件、把 7 位地址和读/写位拼成一个字节发出去然后看第 9 个时钟的 SDA 是否被拉低被拉低就是 ACK代表这个地址上有设备应答。要命在于保留地址、总线电容、时钟拉伸、速率极限这些因素叠在一起低速下没问题一上 1MHz 全暴露。很多工程师做扫描习惯性用 100kHz慢慢扫谁都扫得出来但这只能回答有没有设备而标题里 1000KHz总线速率测试 想回答的则是设备在 1MHz 下还能不能稳定应答。这两件事难度差一个量级。Excel Scan 则说明扫描不是一次性动作而是反复跑、多轮记录、然后汇总分析的流程。比如同一块板子在不同温度下扫一遍或者同一根总线上不同通道各扫一遍最终都要落进同一张表里做交集、差集对比。这也解释了为什么文件名要强调 Excel——它是个交付物不是一个调试期随手产物。2. 硬件准备USB转I2C适配器选型与1MHz总线搭建跑 1MHz 的 I2C 扫描第一步不是打开软件而是确认硬件撑得住。有人拿 400kHz 正常工作的同一套杜邦线直接改 1MHz结果什么都扫不到然后怀疑软件坏了。这大概率不是软件的问题是总线根本没在时序上达标。2.1 三种主流的USB转I2C方案对比我自己常用的方案是 FT232H也就是手头有一块基于该芯片的小板配合 pyftdi 或者厂商的 MPSSE 库使用。FT2232H 和 FT232H 的 MPSSE 引擎一样都可以通过内部时钟分频实现接近 1MHz 的 I2C 时序FT2232H 还多一路通道适合同时挂两条总线对比测试。CH341A 便宜、驱动好装但 I2C 速率档位有限实际使用中跑到 400kHz 已经比较吃力更别说 1MHz所以它更适合低速扫描或者 SPI 场景。CP2112 走 HID 协议免驱是优点但 HID 事务有开销连续快速扫描时吞吐率上不去实测稳定性也不如 FTDI 方案。还有个经常被提到的路线STM32 用 USB 虚拟串口和上位机通信固件里用硬件 I2C 外设或 GPIO 模拟 I2C 主控。这套方案优点是灵活缺点也明显——USB 帧调度是 1ms 粒度如果上位机每发一条指令都要等一个 USB 帧事务间隔会有明显毛刺固件里再夹杂中断处理高速下时序容易飘。所以真要做 1MHz 扫描我首选还是 FT232H省心。注意一个特别容易踩的坑FT231X 是 USB 转 UART 芯片不是 I2C 桥接芯片。有些人看到 FT231X USB UART 驱动 觉得都是 FTDI 的、应该能用结果装上发现只能收发串口数据根本发不出 I2C 时序。选型时看清型号结尾是 H 还是 X。2.2 上拉电阻计算1MHz下为什么不能随便用4.7kI2C 是开漏结构SCL 和 SDA 的上升沿完全靠上拉电阻把线拉向高电平。上拉电阻太小灌入电流太大会让从机的 VOL 超标上拉电阻太大上升沿太慢高速下建立不了有效高电平。1MHz 下这个窗口非常窄。按 Fast Mode Plus 规格1MHz 下上升时间 tr 要求不超过 120ns。计算上拉上限有个常用公式tr ≈ 0.8473 × Rp × Cb其中 Cb 是总线上所有设备引脚电容加走线分布的等效电容。假设总线 Cb 约 100pF十来个器件、几厘米走线是合理估计要满足 120ns 上升沿Rp 最大约为 1.4kΩ。再看最小上拉值VCC3.3V、VOL(max)0.3V、IOL3mA 时Rp(min)(3.3-0.3)/0.0031kΩ。所以理论窗口只有 1kΩ 到 1.4kΩ非常紧张。很多人习惯在 400kHz 下用 4.7kΩ 上拉那是因为 400kHz 允许 300ns 上升时间按公式算 Rp 最大可以到 3.5kΩ4.7k 勉强还能跑但 1MHz 直接翻车。实测中我发现总线电容往往比理论值大因为还叠加了保护器件、连接器、杜邦线的寄生电容Cb 可能到 200pF。这时 1kΩ 上拉的上升沿也有约 170ns照样超了 120ns 的限值。所以到了 1MHz 这个档位别把希望全压在一颗电阻上线缆长度和连接方式一样重要。2.3 接线长度与地线的隐藏作用跑 1MHz 时我对接线长度的容忍度会明显降低。杜邦线裸露部分尽量控制在 10cm 以内而且 SDA、SCL、GND 要一起走单拉两根信号线不接地高速下地回路噪声会很吓人波形上的毛刺会直接导致从机误判地址。如果必须要跨越比较远的距离比如超过 0.5m那原生的开漏 I2C 已经不适合了应该考虑隔离 buffer 或者 I2C 集线器而不是硬拉长线。另外测量时探头也要讲究。我用示波器探头测这个级别的波形时会切到 x10 档用探头地面弹簧接地尽量靠近被测点不要用那个长地线夹子。长地线夹在高速下会引入额外电感看到示波器上多出来的一堆振铃未必是总线自身的问题很可能是测量方式的问题。这属于先把自己手头的工作做好再去怀疑从机。3. 1MHz速率下跑通扫描的逻辑与时序硬件搭完下一步是理解 1MHz 下 I2C 到底发生了什么变化。很多人以为 I2C 协议层和数据格式都一样只是把时钟调快一点实际上时序裕量的变化才是导致各种偶发失败的根源。3.1 Fast Mode Plus说人话1MHz和400kHz差在哪I2C 规范里有很多档位100kHz 标准模式、400kHz 快速模式、1MHz 快速模式加强Fast Mode Plus。单看 SCL 频率数字1MHz 只是 400kHz 的 2.5 倍但时序参数的变化却非常剧烈。400kHz 下允许的上升时间是 300ns1MHz 下直接砍到 120ns400kHz 的 SCL 高电平最小需要 0.6µs1MHz 只需要 0.26µs但此时整个周期只剩 1µs高低电平名义上各占 500ns而上升沿就吃掉 120ns。留给信号到达阈值、从机采样、释放 SDA 的时间窗口越来越窄。我一开始跑 1MHz 扫描时总觉得既然地址一样、协议一样应该没区别。后来用示波器看波形才发现低速时那种边缘圆润的上升沿在 1MHz 下根本没位置容纳——边沿还没爬上去下一个下降沿已经来了。所以 1MHz 不是把频率调高而是整条总线的物理特性都必须跟着升级更短走线、更低电容、更强的上拉驱动、更干净的电源。还要注意一个现象时钟拉伸。有些从机在内部处理数据时会主动把 SCL 拉低要求主机等待。低速下这种等待无所谓但 1MHz 下如果某个从机每访问一次都要拉伸几十微秒整条总线的平均吞吐就崩了。扫描程序必须有超时机制不能对着一个已经掉线的地址无限等下去否则 USB 链路都可能被拖死。3.2 上位机频率设置与扫描探询的代码骨架大多数 USB 转 I2C 工具都提供两种使用方式厂商图形软件和可编程库。做自动化扫描时我基本都会走上位机代码路线。FT232H 方案下pyftdi 是比较好用的库配置 URL 时可以直接指定频率。下面给一个扫描骨架注意这是伪代码具体 API 以你手头库的版本为准# 伪代码基于pyftdi的1MHz地址扫描骨架 from pyftdi.i2c import I2cController ctrl I2cController() ctrl.configure(ftdi://ftdi:232h/1, frequency1_000_000) scan_results [] for addr in range(0x03, 0x78): # 扫描常用7位地址区 ack_w ctrl.probe(addr, readFalse) ack_r False if ack_w: # 只对写方向有ACK的地址再试读方向减少总线打扰 ack_r ctrl.probe(addr, readTrue) scan_results.append({ addr: addr, ack_w: ack_w, ack_r: ack_r, }) print(f0x{addr:02X}: write_ack{ack_w} read_ack{ack_r})用 CH341A 时方式一般是加载厂商 DLL然后通过 ioctl 设置分频参数频率档位不那么自由。用 STM32 自建方案时频率由固件定时器决定天然适合做成指令下发模式但高速下稳定性的瓶颈在上位机和 USB 帧调度不在单片机本身。所以我建议优先选用有成熟库支持的方案这样扫描代码可以集中在业务逻辑上不需要每家芯片都重写一套。3.3 用示波器判断波形是否达标写代码扫描之前我强烈建议先花五分钟用示波器看波形别直接盲扫。重点看三样东西SCL 上升时间是否在 120ns 以内、SDA 在 SCL 高电平期间是否稳定、start/stop 条件是否干净。如果 SCL 上升沿明显缓慢比如已经超过 200ns那不用怀疑——优化上拉电阻、剪短接线重测吧。如果 SDA 在 SCL 高电平期间还在抖动那通常是从机释放 SDA 太慢或者负载电容太大再测下去也是偶发失败。如果 start/stop 条件都有毛刺先查信号线和地线的连接再查适配器本身。有一次我扫描一个挂了 8 颗从机的板子1MHz 下地址 0x48 时而应答、时而不应答。截波形发现 0x48 这颗芯片的 SDA 释放时间比其它设备都慢SCL 高电平采样时 SDA 还没完全到高主控已经采到低电平误判成 ACK 断连。这种问题靠软件循环重试没有意义得从设备物理特性和时序裕量入手。4. 扫描数据的组织从原始ACK到Excel结果表扫描做完只是第一步真正让结果能用的是把原始 ACK 状态整理成结构化的表格。这一步看起来简单但字段设计不合理后面做多轮对比和自动化分析时就会非常痛苦。4.1 地址范围该怎么选保留地址怎么避7 位 I2C 地址从 0x00 到 0x7F其中 0x00-0x07 和 0x78-0x7F 是保留地址段用于广播、10 位地址扩展、系统管理总线等用途普通扫描不应该把这段算进去。我常用的扫描范围是 0x03 到 0x77还会跳过一些已知的广播地址如 0x00。探询方向也值得设计一下。大多数从机在写方向会 ACK读方向不一定反之也有特殊情况。我习惯先发写方向得到 ACK 再发读方向。如果写方向没有 ACK读方向探询失败的绝大多数情况是这个地址真的没有设备不必强行去试。但有些只读器件或者探询灵敏度特殊的器件会在读方向才应答所以最终表里 ack_w 和 ack_r 都保留方便后面判断。还有一点10 位地址的从机不走普通 7 位扫描逻辑它要在地址前段出现特殊头1111 0XX传统扫描软件基本不会把它们列出来。如果你的系统确定挂了 10 位地址从机最好直接用已知地址去读别指望扫描能找到。4.2 Excel字段设计与Python生成表格Excel 表格的字段设计直接决定这文件以后能不能用。我最基本的列设计是时间、通道、SCL 设置速率、7 位地址十六进制、7 位地址二进制、写方向 ACK、读方向 ACK、备注。如果你扫描的目标里有多个板卡或者多个通道通道列必须要有不然同名地址多行出现的时候根本分不清。用 Python 生成 Excel 很成熟openpyxl 就够用。下面是一个示例from openpyxl import Workbook wb Workbook() ws wb.active ws.title scan_results ws.append([ time, channel, scl_khz, addr_hex, addr_bin, ack_w, ack_r, note ]) scan_results [...] # 上一步收集的结果 for row in scan_results: ws.append(row) # 给无ACK的行加条件格式便于肉眼快速定位 ws.auto_filter.ref ws.dimensions wb.save(USB2I2C_SCAN_1000KHz_CHA.xlsx)这张表顺手加了自动筛选后续可以直接在 Excel 里按某一列排序或者筛掉全空的行。如果现场不方便装 Python也可以先把扫描结果存成 CSV再手动导入 Excel效果差不多的。但既然标题里明确写了(Excel)_Scan说明工作流里已经预期要用脚本生成表格了那不如一次性把脚本写好。注意列名里千万别偷懒把 7 位地址直接写成一个字符串十六进制和二进制两列都有用——十六进制方便人读二进制方便看地址位冲突比如 A0/A1/A2 引脚状态。4.3 扫描结果的判读同地址多设备与类型猜测扫描出来后第一眼很容易被哪个地址有几个 ACK带走但我更关心的是哪些地址出现了多次代表总线上有疑似冲突。I2C 一个地址只能对应一个从机如果同样一个地址在多块板子上都出现了 ACK那不是板子一样就是你有一类器件没有把地址引脚区分开。比如 EEPROM 常见 0x50-0x57IO 扩展芯片常见 0x20-0x27RTC 常见 0x68ADC 常见 0x48-0x4F。看到这些地址时我会对照原理图确认有没有把 A0/A1/A2 引脚接到正确电平。需要注意的是扫描结果只能证明这个地址上有设备应答不能证明这个设备正常工作。ACK 之后还要继续读寄存器、回读校验数据才能真正判断设备状态。所以 Excel 表的 note 字段很适合记录后续动作比如0x50 ACK读 ID 正常速度 1MHz 可用这样表格就不仅是扫出来什么还记录了验证到什么程度。5. 排除链路1MHz扫描失败的三类典型场景扫不出来的时候人的第一反应是反复重试扫描但很多时候重试只是在同样的错误里浪费时间。下面三个场景是我在 1MHz 扫描项目里遇到最多的每条都配一条排查链路照着走比碰运气强得多。5.1 全盘无应答从接反到漏上拉的排查顺序如果从 0x03 到 0x77 一个 ACK 都没有先不要怀疑所有从机都坏了。这个现象最常见的原因其实就三个SDA 和 SCL 接反、上拉电阻没接或者没接对、适配器没有真正开始工作。我一般按这个顺序排查第一步用万用表量 SDA、SCL 的静态电平确认两个引脚都在高电平如果有任意一根是低电平说明总线被卡住常见原因是设备地址冲突导致其中一颗芯片把 SDA 拉死了第二步对照适配器原理图和板子丝印确认 SDA 没接成 SCL——两线接反在 1MHz 下尤其隐蔽低速时还有一点信号完整性的侥幸高速直接全挂第三步用示波器看 start 条件有没有真的发出来SCL 高电平期间 SDA 下降沿清晰可见才算 start如果看波形发现压根没有 start说明是适配器或软件配置的问题不是总线问题第四步把总线上所有从机摘掉只留适配器和上拉电阻看能不能量到干净波形能就从机侧问题不能就从适配器侧问题。5.2 400kHz正常、1MHz掉设备速率余量问题比全盘无应答更折磨人的是低速全好、高速时有时无。我做过一个板子400kHz 下所有设备都稳稳应答改到 1MHz 后地址 0x20 和 0x50 开始间歇性消失而且不是每次都消失偶尔扫到了下次又没了。这种问题的根源几乎都是时序余量不足。第一个嫌疑就是上拉电阻太大我在前面已经算过1MHz 下 4.7kΩ 基本不可能达标。第二个嫌疑是线缆太长或者测量环境引入的电容太大。第三个嫌疑才轮到从机本身——有些从机的手册明确写最高支持 400kHz那它在这个项目里本来就不该参与 1MHz 扫描。排查时我会用示波器抓那路总线的 SCL 上升沿如果超过 120ns先优化上拉和接线如果波形达标了设备还是怪再逐个摘从机做二分定位。想快一点的话可以写一个频率步降扫描函数从 1MHz 依次降到 900kHz、800kHz、700kHz记录每个频率下哪些地址变成可 ACK。找到那颗设备的临界频率就基本锁定问题在时序余量还是器件能力了。5.3 地址冲突与多路复用通道A里的隐藏设备如果 Excel 表里某一列地址在多次扫描中反复出现但你的设计图上这个地址只对应一个器件那就得考虑冲突。最常见的是同一型号芯片多片共存地址引脚没有正确接电平。比如 EEPROM 的 A0/A1/A2 引脚本来可以组合出 8 个地址如果全部悬空或者焊错两片芯片实际地址相同扫描表里只会看到一个地址但通信时两片芯片会同时拉 SDA波形就会乱掉。这时最好的方法是手工断开其中一篇芯片的电源或者使能脚再做一次对照扫描。另一个容易误解的场景是总线上挂了多路复用器比如 TCA9548A。这时适配器看到的只有复用器自身的地址常见 0x70 或 0x71下游其它通道的设备必须先把复用器切到对应通道才能被扫描到。如果标题里的_A代表通道 A那你的扫描逻辑就要先在复用器上写控制字节选通道再对当前通道发起地址扫描。Excel 表里同样要增加 channel 列否则不同通道扫出来的相同地址会在表里互相纠缠后续根本没法分析。6. 测试资产化从项目标题到可追溯的记录规范有一次我在一个项目里找到三年前的扫描文件文件名是scan_data_backup.xlsx打开后里面只有一列地址没有时间、没有速率、没有通道信息完全无法判断这是哪块板子、什么条件下测的。那次之后我再看到USB TO I2C_(Excel)_Scan ---- 1000KHz总线速率测试_A这种命名就会特别敏感——它不是随手起的是一套可追溯的模板。6.1 命名规范为什么重要一个带完整参数的文件名等于把测试条件写进了元数据。看到USB TO I2C你立刻知道是 USB 转 I2C 工具扫的看到1000KHz你知道这是 1MHz 高速档意味着当时的目标不仅是找设备还包括验证总线在高速下能不能工作看到_A你知道除了这一组还有 B/C 等其他维度。这个命名模板应该被固定成团队协作的约定比如{链路方案}_{动作}_{输出格式}_{速率}_{通道}_{日期}_{版本}.xlsx每个字段都有明确含义。文件是留给未来的自己或者下一个同事看的最怕的就是只留结果不留条件。6.2 把Excel扫描结果变成自动报告一旦扫描结果以 Excel 为交付格式后续能做的事就多了。我常做的是周期性地把扫描目录下的所有 Excel 文件汇总到一张总表用 pandas 按地址列去重统计再和设计 BOM 清单比对自动列出设计上有、扫描里没有的地址缺口。这里的关键是把 BOM 信息也标准化成表比如器件类型、7 位地址、所属通道、额定速率然后扫描结果和 BOM 做两个维度的 join。出现差异时就自动标记一个待确认状态。这个思路适合测试量到一定规模、人工已经看不过来时用。不需要做得多花哨只要把 ACK、时间、通道、速率这些基础字段整理成可分析的结构条件格式、筛选、差集分析都是顺理成章的事。6.3 关于这套流程的几点个人体会来回做了几轮 1MHz 扫描之后我最大的体会是速率测试和功能测试要分开记录。1MHz 下能扫到地址只代表这颗设备在协议层面能 ACK不代表它能在 1MHz 下完整读写数据。所以我做扫描时会同时测一下寄存器回读比如向某设备写好一个已知值再读出来比对把这个结果也写进 Excel 的备注列。这样每次扫描的结果就不仅能回答分支地址对不对还能回答这个设备在这个速率下能不能用。另一个体会是慢下来反而快。先 100kHz 把整个总线的设备拓扑摸清楚再用 1MHz 跑信号质量最后用 1MHz 做批量枚举这三步顺序不要乱。很多现场问题都是拿 1MHz 一上来就扫扫不出来就乱换代码、乱换工具最后发现只是上拉没换。文件名留好了链路也清楚了剩下的就是按顺序把每一步做扎实。以后再看到这种带完整参数的文件名我会先感谢当初写命名规范的人——至少我不用打开表格猜这是在哪块板子上、用多少速度扫出来的。
