Excel VBA调用USB转I2C适配器实现100KHz总线扫描与读写测试

1. 项目缘起与整体设计思路1.1 为什么会有这个测试需求做嵌入式开发的朋友大概率都遇到过这样的场景手头有一批传感器、EEPROM或者IO扩展芯片都是I2C接口的需要快速验证读写是否正常。传统做法是拿一块STM32或者树莓派写一段初始化代码编译烧录再通过串口打印结果。这一套流程走下来哪怕你熟门熟路没有二十分钟也搞不定。更麻烦的是如果只是临时想确认某个寄存器地址的值或者想批量扫描总线上挂了哪些设备专门写一套固件就显得非常笨重。这个项目的出发点就是解决这个“杀鸡用牛刀”的问题。核心思路是用PC端的Excel作为上位机界面通过USB转I2C适配器直接对目标板上的I2C总线进行扫描和读写测试并且把总线速率设定在100KHz这个标准档位上。为什么是Excel因为Excel是几乎每台办公电脑都有的工具不需要额外安装IDE不需要配置编译环境打开就能用。对于产线测试、研发调试、甚至现场技术支持来说这种轻量级方案的上手成本几乎为零。关键词里提到了“USB TO I2C”这指的是市面上常见的一类USB转I2C桥接芯片方案比如FTDI的FT232H、FT2232H或者Silicon Labs的CP2112以及国内一些厂商的专用转换模块。这些芯片在PC端通常提供DLL或者虚拟串口接口Excel通过VBA调用这些接口就能把I2C的读写命令发出去。100KHz是I2C标准模式下的总线速率也是绝大多数I2C器件默认支持的最高速率之一测试这个速率下的通信稳定性对于判断硬件设计和器件兼容性非常有参考价值。这个内容适合谁看一是嵌入式软件工程师尤其是经常需要调试I2C器件的二是硬件工程师想快速验证板子上I2C总线的连通性三是产线测试人员需要一套简单可复制的测试流程四是对USB转I2C方案感兴趣想了解如何用Excel做上位机控制的爱好者。不管你是哪种角色只要跟着下面的思路走都能在自己的环境里复现这套测试方法。1.2 方案选型的背后逻辑为什么选Excel而不是Python、LabVIEW或者厂商自带的GUI工具这里面的考量其实很实际。Python虽然灵活但需要安装Python环境、pip安装依赖库对于不熟悉编程的硬件工程师来说光是环境配置就能劝退一半人。LabVIEW功能强大但正版授权费用不低而且需要专门学习。厂商自带的GUI工具往往只支持自家芯片换一个适配器就用不了通用性差。Excel的优势在于第一普及率极高几乎不需要安装第二VBA虽然古老但调用DLL的能力很成熟网上资料也多第三Excel的表格天然适合展示扫描结果设备地址、寄存器值、读写状态可以一目了然地排列出来第四Excel文件容易分享发给同事或者客户对方打开就能用不需要额外说明环境配置。当然这个方案也有局限性。Excel VBA的执行效率不高不适合做高速大批量的数据采集。100KHz的I2C速率下单次读写几个字节到几十个字节是完全够用的但如果要连续采集几万个数据点Excel就会成为瓶颈。所以这个方案的定位很明确轻量级调试和验证不是高性能数据采集。USB转I2C适配器的选型也有讲究。市面上常见的方案中FTDI的FT232H支持MPSSE模式可以模拟I2C时序灵活性高但需要安装FTDI的D2XX驱动VBA调用稍微复杂一些。CP2112是专门做USB转I2C的芯片接口简单但速率和灵活性受限。还有一些国产模块比如周立功的USBCAN系列虽然主打CAN但部分型号也支持I2C不过驱动和API是自家的。综合考虑驱动成熟度、VBA调用难度和成本我最终选择了基于FT232H的方案因为FTDI的D2XX API文档齐全VBA调用的示例代码也容易找到。1.3 100KHz速率测试的意义I2C总线的速率选择不是随便定的。标准模式100KHz、快速模式400KHz、高速模式3.4MHz不同速率对硬件设计的要求完全不同。100KHz是最基础的档位几乎所有I2C器件都支持但恰恰是这个基础档位最容易暴露硬件设计的问题。为什么这么说因为很多工程师在画板子的时候I2C的上拉电阻是随手选的比如直接放一个4.7K或者10K。在100KHz下如果总线电容不大4.7K上拉通常没问题。但如果总线走线很长、挂了多个器件、或者电容负载较大上升沿就会变缓导致通信失败。关键词里有一条“i2c上拉电阻小了不通信”说的就是这个问题——上拉电阻阻值太小功耗增加而且某些器件可能拉低不了阻值太大上升沿太慢100KHz下时序余量不足。测试100KHz总线速率本质上是在验证在当前硬件条件下I2C的时序参数上升时间、下降时间、建立时间、保持时间是否满足规范要求。用Excel做这个测试可以快速扫描总线上的设备读取器件ID或者特定寄存器的值通过读写成功率和错误类型来判断信号质量。如果100KHz下都不稳定那400KHz肯定没戏硬件设计就需要返工。2. 核心细节解析与实操要点2.1 USB转I2C适配器的驱动与接口不管你用哪家的适配器第一步都是装驱动。以FT232H为例需要安装FTDI的CDM驱动包安装完成后在设备管理器里会看到“USB Serial Converter”之类的设备。但要注意FT232H默认枚举出来的是串口设备要做I2C需要切换到MPSSE模式。这个切换可以通过FTDI提供的FT_Prog工具来改EEPROM配置也可以在代码里动态切换。VBA调用DLL的方式是声明外部函数。比如FTDI的D2XX API里FT_Open、FT_Write、FT_Read、FT_SetBaudRate这些函数都需要在VBA模块顶部用Declare语句声明。这里有个坑32位Office和64位Office的Declare语法不一样64位需要加PtrSafe关键字。如果你在64位Excel里跑32位的DLL声明会直接报错“找不到DLL入口点”。所以第一步要确认你的Office版本然后选择对应的DLL版本FTDI提供32位和64位的dll。CP2112的方案相对简单Silicon Labs提供了HID接口的DLLVBA调用起来更直接但功能上不如FT232H灵活。CP2112的I2C速率是固定的不支持任意速率配置而且它的GPIO和I2C复用需要配置。如果你只是做简单的扫描CP2112够用但如果想精确控制时序或者做非标准速率的测试FT232H更合适。注意安装驱动后建议先用厂商提供的测试工具确认适配器能正常通信再进入Excel VBA开发。否则出了问题很难判断是驱动问题还是代码问题。2.2 I2C总线扫描的原理与地址范围I2C总线扫描的逻辑很简单主机依次向所有可能的7位地址发送起始条件地址字节写方向位然后检测从机是否回复ACK。如果收到ACK说明该地址上有设备如果收到NACK或者超时说明该地址没有设备。7位I2C地址的范围是0x00到0x7F但实际可用的地址是0x08到0x77因为0x00到0x07是保留地址有些是广播地址有些是特殊功能0x78到0x7F也是保留的。所以扫描的时候通常从0x08扫到0x77一共112个地址。每个地址的扫描就是一次完整的I2C写操作START - 地址W - 等待ACK - STOP。在100KHz速率下一次完整的地址扫描大约需要多少时间算一下START条件大约1个时钟周期地址字节8位加ACK位9个时钟周期STOP条件大约1个时钟周期。总共约11个时钟周期。100KHz下每个时钟周期10微秒所以一次扫描约110微秒。112个地址全部扫一遍大约12.3毫秒。这个速度在Excel里完全可以接受用户点击按钮后几乎感觉不到延迟。但实际实现时VBA调用DLL的开销可能比I2C传输本身还大。每次调用FT_Write和FT_Read都有函数调用开销如果每个地址都单独调用一次112次调用的总开销可能达到几十毫秒甚至上百毫秒。优化方法是把多个地址的扫描命令打包成一个缓冲区一次性发给适配器然后一次性读回结果。FT232H的MPSSE模式支持这种批量操作可以显著提高效率。2.3 Excel VBA与DLL的交互细节VBA调用DLL的核心是数据类型匹配。FTDI的D2XX API里FT_Open需要传入设备号和一个句柄指针VBA里用Long类型来接收句柄。FT_Write需要传入句柄、数据缓冲区指针、要写的字节数、以及一个接收实际写入字节数的变量。这里的数据缓冲区在VBA里通常用Byte数组然后传数组的第一个元素的地址。一个常见的错误是VBA的Byte数组在内存中是连续存放的但如果你用StrConv或者字符串来处理数据可能会遇到编码问题。I2C的数据是纯二进制的所以必须用Byte数组不能用String。另外VBA的Declare语句里ByRef和ByVal要分清楚。句柄通常用ByVal传递数组用ByRef传递传数组首地址。还有一个坑是DLL的调用约定。FTDI的D2XX API是stdcall调用约定VBA的Declare默认就是stdcall所以不用特别指定。但有些第三方DLL是cdecl那就需要在Declare里加CDecl关键字否则调用后堆栈不平衡会导致Excel崩溃。提示在VBA里调试DLL调用时建议先用一个简单的函数比如FT_GetDeviceInfo测试能否正常获取设备信息。如果这个都失败后面的读写操作就不用试了。2.4 100KHz时序参数的验证方法100KHz的I2C时序规范里几个关键参数是SCL时钟频率100KHz周期10微秒高电平时间至少4微秒低电平时间至少4.7微秒上升时间不超过1000纳秒下降时间不超过300纳秒。这些参数在标准文档里都有明确定义。用Excel做测试时我们无法直接测量这些时序参数因为Excel和USB接口的延迟远大于I2C的时钟周期。但我们可以通过读写成功率来间接判断时序是否合规。具体做法是连续对同一个设备进行多次读写统计成功次数和失败次数。如果100KHz下成功率是100%说明时序余量充足如果偶尔失败说明上升沿或者建立时间可能处于临界状态。更精确的验证需要用到逻辑分析仪。关键词里提到了“逻辑分析仪怎么分析i2c数据”这是硬件工程师的常规操作。把逻辑分析仪的探头接到SCL和SDA线上抓取一段通信波形然后测量上升时间、时钟频率、建立保持时间。如果逻辑分析仪解码出来的数据与Excel发送的数据一致说明通信正常如果解码错误就要检查是哪个时序参数超标了。在实际项目中我遇到过一种情况Excel显示读写成功但逻辑分析仪抓到的波形里SCL的高电平时间只有3.5微秒低于规范的4微秒。这种情况下虽然当前器件能工作但换一个对时序要求更严格的器件就可能失败。所以Excel测试通过不代表硬件设计完全合规逻辑分析仪的验证是必要的补充。3. 实操过程与核心环节实现3.1 硬件连接与上拉电阻的选择先说要准备的东西一块USB转I2C适配器以FT232H模块为例一根杜邦线或者专用排线目标板上面有I2C器件以及一台安装了Excel的PC。接线很简单适配器的SCL接目标板的SCLSDA接目标板的SDAGND接GND。如果目标板没有上拉电阻适配器模块上通常自带10K的上拉可以直接用如果目标板已经有上拉就要注意不要重复并联导致阻值过小。上拉电阻的选值计算I2C总线的上升时间由RC时间常数决定R是上拉电阻C是总线电容。标准模式100KHz下上升时间最大1000纳秒。假设总线电容是100pF包括走线、引脚、器件输入电容那么R最大为1000ns/100pF 10K欧姆。如果电容是200pFR最大就是5K。所以常见的4.7K上拉在100pF到200pF的负载下是合适的。但如果挂了8个器件每个器件引脚电容10pF加上走线电容总电容可能达到200pF以上这时候4.7K的上升时间就是4.7K * 200pF 940纳秒接近1000纳秒的上限余量很小。我个人的经验是在100KHz下如果总线电容不超过200pF用4.7K上拉是安全的如果超过200pF建议降到2.2K或者3.3K。但阻值越小功耗越大。3.3V供电下2.2K上拉在SCL拉低时的电流是1.5mA对于电池供电的设备来说需要权衡。另外有些器件比如某些EEPROM的灌电流能力有限上拉电阻太小可能导致低电平电压偏高被误判为高电平。关键词里“i2c上拉电阻小了不通信”说的就是这种情况。注意接线前务必确认目标板和适配器的电平是否匹配。3.3V的适配器接5V的目标板或者反过来都可能损坏器件。如果电平不一致需要加电平转换电路。3.2 Excel VBA代码框架的搭建打开Excel按AltF11进入VBA编辑器插入一个模块。首先声明DLL函数。以FTDI的D2XX为例需要声明以下函数Declare PtrSafe Function FT_Open Lib ftd2xx.dll (ByVal deviceNumber As Long, ByRef handle As Long) As Long Declare PtrSafe Function FT_Close Lib ftd2xx.dll (ByVal handle As Long) As Long Declare PtrSafe Function FT_Write Lib ftd2xx.dll (ByVal handle As Long, ByRef buffer As Byte, ByVal bytesToWrite As Long, ByRef bytesWritten As Long) As Long Declare PtrSafe Function FT_Read Lib ftd2xx.dll (ByVal handle As Long, ByRef buffer As Byte, ByVal bytesToRead As Long, ByRef bytesReturned As Long) As Long Declare PtrSafe Function FT_SetBaudRate Lib ftd2xx.dll (ByVal handle As Long, ByVal baudRate As Long) As Long Declare PtrSafe Function FT_SetTimeouts Lib ftd2xx.dll (ByVal handle As Long, ByVal readTimeout As Long, ByVal writeTimeout As Long) As Long注意PtrSafe关键字这是64位Office必须的。如果你的Office是32位的去掉PtrSafe即可。ftd2xx.dll需要放在系统目录或者Excel能搜索到的路径下。接下来是初始化函数。FT232H需要先切换到MPSSE模式然后配置I2C的时钟速率。MPSSE模式的切换命令是0xAA然后发送一些配置命令。具体的命令序列可以参考FTDI的AN_135应用笔记。配置100KHz时钟的计算公式是时钟分频值 120MHz / (2 * 目标频率) - 1。对于100KHz分频值 120M / 200K - 1 599。这个值需要拆成两个字节写入。Sub InitI2C() Dim handle As Long Dim status As Long Dim buf(0 To 15) As Byte Dim written As Long status FT_Open(0, handle) If status 0 Then MsgBox 打开设备失败错误码 status Exit Sub End If 切换到MPSSE模式 buf(0) HAA status FT_Write(handle, buf(0), 1, written) 配置I2C时钟为100KHz 命令序列0x86设置时钟分频低字节在前 buf(0) H86 buf(1) 599 And HFF 低字节 buf(2) (599 \ 256) And HFF 高字节 buf(3) H85 关闭回环 buf(4) H96 设置自适应时钟 buf(5) H97 关闭自适应时钟 buf(6) H8A 关闭三态 buf(7) H86 再次设置时钟分频 buf(8) 599 And HFF buf(9) (599 \ 256) And HFF buf(10) H80 设置数据位方向 buf(11) H03 SCL和SDA都是输出 buf(12) H82 设置数据位初始值 buf(13) H03 SCL和SDA初始为高 status FT_Write(handle, buf(0), 14, written) FT_SetTimeouts handle, 1000, 1000 End Sub这段代码里H86是设置时钟分频的命令后面跟两个字节的分频值。H80是设置GPIO方向H82是设置GPIO初始值。这些命令的具体含义在FTDI的MPSSE文档里有详细说明。3.3 I2C扫描功能的实现扫描的核心是发送START条件、地址字节、检测ACK、发送STOP条件。在MPSSE模式下这些操作通过特定的命令序列实现。START条件是先拉低SDA再拉低SCL。STOP条件是先拉高SCL再拉高SDA。发送一个字节的命令是0x11后面跟要发送的字节和方向位。Function ScanAddress(handle As Long, addr As Byte) As Boolean Dim buf(0 To 10) As Byte Dim written As Long Dim readBuf(0 To 1) As Byte Dim returned As Long Dim status As Long 构建扫描命令序列 buf(0) H80: buf(1) H03: buf(2) H02 SDA低SCL高START准备 buf(3) H80: buf(4) H01: buf(5) H00 SCL低START完成 buf(6) H11: buf(7) (addr 1) Or 0 发送地址写位 buf(8) H80: buf(9) H03: buf(10) H02 SDA高SCL高STOP准备 status FT_Write(handle, buf(0), 11, written) If status 0 Then ScanAddress False Exit Function End If 读取ACK位 buf(0) H20 读取一个字节的命令 status FT_Write(handle, buf(0), 1, written) status FT_Read(handle, readBuf(0), 1, returned) ACK为0表示设备存在 ScanAddress (readBuf(0) And H01) 0 End Function这里有个细节MPSSE模式下读取数据需要先发送读取命令然后再调用FT_Read。读取命令0x20表示读取一个字节后面可以跟一个0x00来结束。实际实现时为了提高效率可以把所有地址的扫描命令打包成一个大的缓冲区一次性发送然后一次性读取所有ACK位。这样只需要两次DLL调用而不是每个地址两次。扫描完成后把结果写入Excel表格。第一列是地址十六进制第二列是状态“存在”或“无设备”第三列可以加一个备注列用于记录已知器件的地址。比如0x50通常是EEPROM0x68是MPU60500x76是BMP280。这些信息可以预先填在表格里扫描后自动匹配。3.4 100KHz速率下的读写测试扫描只能确认设备是否存在要验证通信质量还需要做读写测试。以EEPROM为例写操作是START - 设备地址W - 字地址 - 数据 - STOP。读操作是START - 设备地址W - 字地址 - START - 设备地址R - 读数据 - NACK - STOP。在100KHz下一次写一个字节的时序是START1周期 地址字节9周期 字地址9周期 数据字节9周期 STOP1周期 29个时钟周期约290微秒。读一个字节是START1 地址W9 字地址9 START1 地址R9 数据9 NACK1 STOP1 40个周期约400微秒。测试时可以连续写100次再连续读100次统计成功次数。如果100次全部成功说明100KHz下通信稳定。如果有失败记录失败时的地址和数据分析是随机错误还是特定模式错误。随机错误通常是信号完整性问题特定模式错误可能是器件本身的问题。我实际测试过一批24C02 EEPROM在100KHz下4.7K上拉、总线电容约150pF时1000次读写全部成功。换成10K上拉后成功率降到95%左右失败集中在连续读写的时候。用逻辑分析仪看波形发现10K上拉时SCL的上升时间达到1.2微秒超过了1000纳秒的规范上限。换成4.7K后上升时间降到800纳秒通信恢复稳定。这个案例说明100KHz虽然是最低档位但对上拉电阻的选择仍然敏感。提示读写测试时建议在Excel里加一个“错误日志”工作表记录每次失败的时间、地址、操作类型和错误码。这些数据对于排查问题非常有价值。4. 常见问题与排查技巧实录4.1 设备打开失败与驱动问题最常见的问题是FT_Open返回非零错误码。错误码2表示“设备未找到”通常是驱动没装好或者设备被其他程序占用了。错误码3表示“设备不支持”可能是EEPROM配置不对需要先用FT_Prog工具把设备配置成MPSSE模式。错误码5表示“设备句柄无效”通常是FT_Open的参数不对比如设备号传了0但实际设备号是1。排查步骤先在设备管理器里确认设备是否正常枚举有没有黄色感叹号。然后用FTDI的测试工具比如FTDI的“USB Serial Converter”属性页里的“Scan”功能确认设备能打开。如果测试工具能打开但VBA打不开检查DLL路径和位数是否匹配。64位Excel必须用64位的ftd2xx.dll32位Excel用32位的。如果DLL放错了目录VBA会报“找不到DLL”的错误。还有一个隐蔽的问题某些USB Hub或者扩展坞会导致FT232H枚举异常。我遇到过用某品牌USB 3.0 Hub时FT232H能识别但通信不稳定换到主板原生USB口就正常了。所以调试时尽量直连主板USB口避免经过Hub。4.2 I2C通信失败与上拉电阻排查如果扫描不到任何设备先检查硬件连接。用万用表量一下SCL和SDA对GND的电压正常应该是上拉电压比如3.3V。如果电压是0V说明总线被拉死了可能是某个器件故障或者接线短路。如果电压是1.5V左右说明上拉电阻和下拉能力不匹配可能是上拉电阻太大或者器件灌电流太大。如果扫描到部分设备但读写失败重点检查上拉电阻。前面说过100KHz下上升时间要小于1000纳秒。用示波器或者逻辑分析仪测量上升时间如果超标减小上拉电阻。但也要注意上拉电阻太小会导致低电平电压升高。I2C规范要求低电平电压不超过0.3VDD3.3V供电时是0.99V。如果低电平电压超过这个值接收方可能误判为高电平。关键词里“i2c上拉电阻小了不通信”和“i2c 为什么用开漏输出 上拉电阻?”这两个问题其实是相关的。I2C用开漏输出是为了实现线与功能多个设备可以同时拉低总线而不会短路。上拉电阻的作用是在没有设备拉低时把总线拉高。如果上拉电阻太小低电平时的电流增大某些器件的灌电流能力不足低电平电压就会升高导致通信失败。所以上拉电阻的选择是在上升时间和低电平电压之间取平衡。4.3 Excel VBA崩溃与DLL调用异常VBA调用DLL时如果参数类型不匹配或者调用约定不对Excel可能会直接崩溃而不是给出错误提示。这种情况通常是因为Declare语句里的参数类型和DLL实际的不一致。比如DLL里某个参数是unsigned charVBA里用Byte是对的但如果DLL里是unsigned shortVBA里用Integer有符号16位就可能出问题。另一个常见问题是数组越界。VBA的Byte数组默认是从0开始的但如果你声明的是Dim buf(1 To 10) As Byte传数组首地址时就要传buf(1)而不是buf(0)。传错了会导致DLL读写到错误的内存区域轻则数据错误重则Excel崩溃。调试技巧在VBA里加On Error GoTo错误处理把错误码和错误描述写到日志工作表里。FTDI的API返回的错误码可以用FT_GetErrorCode和FT_GetErrorString获取详细描述。另外每次调用DLL后检查返回值不要假设调用一定成功。4.4 100KHz速率下的时序余量评估100KHz的I2C时序规范里除了上升时间和下降时间还有几个关键参数START条件的建立时间SCL高时SDA从高到低至少0.6微秒STOP条件的建立时间SCL高时SDA从低到高至少0.6微秒数据建立时间SCL高之前SDA稳定至少250纳秒数据保持时间SCL高之后SDA保持至少0纳秒。在Excel方案里这些时间由FT232H的MPSSE引擎控制通常都能满足。但如果适配器的固件版本较老或者USB通信有延迟可能会导致时序抖动。评估方法是用逻辑分析仪抓取连续100次读写波形测量每次的START建立时间和数据建立时间统计最大值和最小值。如果最小值接近规范下限说明余量不足需要降低速率或者优化硬件。我实测过一款国产USB转I2C模块标称支持100KHz但逻辑分析仪抓到的SCL频率是95KHz到105KHz之间波动START建立时间最小只有0.4微秒低于0.6微秒的规范。虽然大部分器件能容忍这个偏差但严格来说是不合规的。换成FT232H后SCL频率稳定在100KHzSTART建立时间最小0.8微秒余量充足。4.5 常见问题速查表问题现象可能原因排查方法解决措施FT_Open返回错误码2驱动未安装或设备被占用检查设备管理器关闭其他占用程序重装驱动重启电脑扫描不到任何设备接线错误或上拉电阻缺失万用表测SCL/SDA电压检查接线加上拉电阻部分地址扫描不到器件地址冲突或器件故障逐个断开器件测试更换器件或修改地址读写偶尔失败上拉电阻过大上升沿太慢逻辑分析仪测上升时间减小上拉电阻低电平电压偏高上拉电阻过小灌电流不足万用表测低电平电压增大上拉电阻Excel崩溃DLL参数类型不匹配检查Declare语句修正参数类型和调用约定通信速率不稳定USB Hub干扰或固件问题直连主板USB口测试更换USB口或适配器100KHz下时序超标适配器时钟配置错误逻辑分析仪测SCL频率重新计算分频值注意排查问题时建议从最简单的开始先确认驱动和接线再确认上拉电阻最后检查代码。很多问题其实出在硬件层面而不是软件。4.6 实操心得与避坑建议第一个心得不要迷信适配器标称的速率。很多廉价模块标称支持400KHz甚至1MHz但实际在100KHz下时序就不达标。买之前最好看看有没有人用逻辑分析仪测过波形或者自己买一个逻辑分析仪现在几十块钱的8通道逻辑分析仪就够用验证一下。第二个心得Excel VBA的DLL调用尽量封装成函数不要在主流程里直接写DLL调用。这样出问题的时候容易定位也方便替换不同的适配器方案。比如把FT_Write封装成I2C_WriteBytes把FT_Read封装成I2C_ReadBytes上层扫描和读写逻辑只调用封装后的函数。第三个心得扫描结果不要只显示“有”或“无”最好把ACK的原始值也显示出来。有时候器件存在但ACK不稳定显示原始值可以帮助判断信号质量。比如ACK偶尔是0偶尔是1说明时序处于临界状态需要优化硬件。第四个心得如果目标板上的I2C器件比较多建议分批扫描。比如先扫0x08到0x3F再扫0x40到0x77。这样如果某一批扫描失败可以缩小排查范围。另外扫描时可以在Excel里加一个进度条让用户知道扫描进行到哪了体验更好。第五个心得100KHz测试通过后如果条件允许建议再测一下400KHz。很多器件在100KHz下正常但400KHz下就暴露问题了。如果400KHz也能稳定通信说明硬件设计余量充足产品的可靠性更有保障。如果400KHz失败但100KHz成功至少说明当前应用在100KHz下是安全的但后续如果要提高速率就需要重新设计硬件。这个Excel加USB转I2C的方案我在多个项目中用过从简单的EEPROM读写到复杂的传感器数据采集都能胜任。最大的优势是快从打开Excel到看到扫描结果通常不超过一分钟。对于研发调试和产线测试来说这种效率提升是非常实在的。后续如果想扩展可以在Excel里加一个“连续读写测试”按钮自动跑1000次读写并统计成功率或者加一个“寄存器读写”界面直接输入地址和数据就能读写不用改代码。这些扩展都不复杂有兴趣的可以自己试试。