调试工具准备：五件趁手的兵器

EDID 读不出来，别急着怀疑人生。先问问自己——手上家伙齐了吗？

我刚开始搞显示调试那会儿，就一根串口线加一个记事本，愣是跟一块 EDID 空白的屏较劲了两天。后来一位老前辈扔给我一台逻辑分析仪，十分钟就定位到问题。工具不对，努力白费。这一章咱们把五样常用工具捋一遍——逻辑分析仪、I2C 调试器、示波器、DDC/CI 工具，还有 EDID 编辑软件。每样工具用在什么场景，怎么用才顺手，我会把个人踩过的坑也抖出来。

逻辑分析仪——抓时序的首选

逻辑分析仪说白了就是个数字信号录像机。它不关心电压多准，只看电平高低和时间关系。调试 EDID 读取失败时，我最先用它。为什么？因为它能一口气抓下 I2C 总线上所有通信过程——地址、读写方向、数据字节、ACK/NACK，清清楚楚。

我用的是 Saleae Logic 8，便宜又好带。接线很简单：把通道 0 挂 SCL，通道 1 挂 SDA，地线接好。设置触发为 I2C Start 条件，抓一次读 EDID 的过程。你会看到类似这样的波形和协议解析：

Time [s]      Channel 0 (SCL)   Channel 1 (SDA)   Decoded
0.000 000     High              High              Idle
0.000 015     High              Low               Start
0.000 030     [0xA0] WR         ACK               Device address 0x50 write
0.000 120     [0x00]            ACK               Register = 0x00
0.000 210     [0xA1] RD         ACK               Device address 0x51 read
0.000 310     [0x00]            NACK              Data byte 0 – NACK!  ← 问题在这里

看到那个 NACK 了吗？这就是 EDID 读取失败的典型信号——显示器在第 9 个时钟周期没有拉低 SDA，主机收到 NACK 后就终止传输了。逻辑分析仪能让你一眼锁定它。

I2C 调试器——手动发命令的狙击枪

逻辑分析仪只能看，不能改。有些场景你需要主动发 I2C 命令去试探显示器的反应——比如重新触发一次 EDID 读取，或者写一个字节到某个寄存器看反馈。这时候 I2C 调试器就上了。

我手头常备的是 USB-I2C 适配器（比如 FT232H 刷的 pyftdi 固件）。Windows 下用“I2C Driver”软件，Linux 下直接用 i2c-tools 命令。比如想确认 0x50 地址是否存在：

# 检测设备
i2cdetect -y 1
# 输出： 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
# 00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

看到 0x50 地址返回了 50（表示探测成功），说明物理 I2C 通路没问题。

我曾经碰到过一个奇葩案例：逻辑分析仪抓到波形很漂亮，就是读不到数据。后来用 I2C 调试器手动写寄存器 0x00 再读，发现连续读的时候显示器会在第 129 个字节后强制 NACK。原来那块屏的 EDID 只有 128 字节，而主机试图读 256 字节——协议不符。这种问题用示波器未必能发现，但 I2C 调试器可以精细控制字节数。

示波器——模拟信号的照妖镜

说实话，纯数字的 EDID 问题我很少开示波器。但有一种情况非它不可：怀疑信号质量有问题——比如上升沿太缓、噪声过大、电平幅值不够。这时候逻辑分析仪看不到细节，必须上示波器。

你需要至少 100 MHz 带宽，能测量上升沿时间。I2C 标准模式下上升沿要求 ≤ 300 ns（快速模式 ≤ 100 ns）。用示波器抓 SCL 和 SDA，看看波形长什么样：

• 如果上升沿超过 1 μs，那很可能是上拉电阻太大或总线上电容过大。
• 如果 SDA 在低电平有毛刺，可能来自电源噪声或信号反射。
• 如果 SCL 高电平只有 2.5 V 而主机是 3.3 V，那可能是漏极开路上拉不足。

DDC/CI 工具——软件层的瑞士军刀

以上都是硬件层工具。但有时候 EDID 读取失败纯粹是驱动或操作系统层面的问题。DDC/CI（Display Data Channel / Command Interface）软件可以绕过用户模式，直接与显示器通信。Windows 下推荐 MonInfo（老工具但好用），或者 DDCutil（跨平台，支持 Linux/macOS）。

用 DDCutil 排查 EDID 读取是否被系统防火墙或显卡驱动拦截：

# 列出所有显示器
ddcutil detect
# 输出应为：Display 1: I2C bus: /dev/i2c-4, EDID file: /etc/ddcutil/edid.bin
# 如果这里报 Cannot open I2C device，可能是权限不足

我曾经遇到一个客户，Windows 下用 MonInfo 能读出 EDID，但 Linux 下 DDCutil 死活读不出来。后来发现是显卡驱动在 Linux 下默认禁用了 DDC/CI 功能，进 BIOS 开一下就解决了。

EDID 编辑软件——读不出来就自己造

最后一样工具听着有点反直觉——明明读失败，为什么还要编辑软件？其实有两个场景很实用：

• 读取成功后保存备份：用 AW EDID Editor 打开 bin 文件，检查数据合法性。
• 模拟 EDID：当显示器完全无法通信时，可以手动构造一份最小 EDID（128 字节），写进显卡 EDID 模拟器或硬件 EDID 烧录器，让系统认为有显示器存在，方便后续调试。

AW EDID Editor 的特点是可以逐字节查看、校验校验和，还能自动修正。我最常用它的“验证”功能——把抓到的 EDID 拖进去，它会告诉你哪段解析异常，比如时钟频率超出范围、校验和不匹配。

// 一份最小 EDID 的核心字段示例（十六进制前16字节）
00 FF FF FF FF FF FF 00   // 头部固定
1E 3D 01 00 00 00 00 00   // 制造商 ID（1E3D=DEL?） + 产品代码
00 1C 01 03 68 1A 0A 78   // 版本 + 基本信息

工具选择路线图

上面讲了五个工具，但实际调试时先上哪一个？我一般按这个逻辑走：

说白了，逻辑分析仪是侦察兵，示波器是鉴定科，I2C 调试器是特种兵，DDC/CI 工具是内应，EDID 编辑软件是后勤。你手上有这五样，EDID 读取失败的问题基本没有能藏住的。

工具速查表