企业官网建设流程全解析

1. 项目缘起与整体设计思路

1.1 一块核心板引发的“血案”

手头这个项目，目标很明确：用 RK3576 这颗 SoC 做一块带 HDMI 输出的嵌入式主板，跑一个轻量级的显示终端。RK3576 是瑞芯微新一代的八核处理器，CPU 是 4×A72 + 4×A53 的架构，GPU 是 Mali-G52 MC3，视频编解码能力相当能打，做多屏异显、4K 输出这类场景非常合适。我拿到的是核心板加底板的组合，核心板已经把 DDR、eMMC、电源管理这些高集成度的部分做好了，底板需要自己设计 HDMI、USB、以太网、I2C 外设这些接口电路。

问题就出在 HDMI 这块。我原本以为 HDMI 就是“把差分线连上、把 I2C 连上、把 HPD 连上”这么简单，结果板子打回来一上电，显示器直接黑屏，连个“无信号”的提示都没有。折腾了整整两天，从硬件查到软件，从设备树查到 I2C 波形，最后发现是一个极其低级的错误——HDMI 的 DDC 通道 I2C 线序接反了，SDA 和 SCL 对调了。

这个坑看起来很小，但它牵扯出来的东西非常多：I2C 的开漏与推挽模式到底怎么选、HDMI 的 DDC 通道和 CEC 通道有什么区别、SoC 端 I2C 控制器的上拉电阻怎么算、电平转换需不需要加、设备树里 I2C 节点怎么配、HPD 信号怎么处理。这篇文章就把整个排查过程、原理分析和最终的解决方案完整地记录下来，适合正在做 RK3576 或其他 SoC 平台 HDMI 接口设计的硬件工程师和嵌入式软件工程师参考。

1.2 为什么选择 RK3576 做这个项目

选 RK3576 的原因其实很实际。第一，它的 HDMI 输出规格够用，支持 HDMI 2.1 标准，最高可以输出 4K@120Hz，虽然我这个项目只用到 1080P@60Hz，但余量留足总没坏处。第二，它的 I2C 控制器资源丰富，一共有 9 组 I2C 总线，其中 I2C0 到 I2C8 分布在不同的引脚复用组里，方便底板走线。第三，瑞芯微的 SDK 生态相对成熟，设备树配置有比较多的参考案例，调试起来不至于完全摸黑。

但这里要提醒一句：SoC 的 I2C 控制器虽然多，但并不是每一组都适合拿来做 HDMI 的 DDC 通道。原因在于 HDMI 的 DDC 通道工作在 5V 电平域，而 SoC 的 I2C 控制器通常工作在 3.3V 或 1.8V 电平域，中间必须做电平转换。如果选错了 I2C 组，可能会遇到上拉电压不匹配、电平转换芯片选型困难等问题。我在设计初期就忽略了这一点，直接选了 I2C4 来连 HDMI 的 DDC，结果后来发现 I2C4 的引脚复用和调试串口冲突，又不得不换到 I2C7。这种返工在设计阶段完全可以避免，后面会详细说怎么提前规划。

1.3 HDMI 接口的核心信号组成

在深入排查之前，先把 HDMI 接口的信号组成理清楚。一个标准的 HDMI Type-A 接口有 19 个引脚，按功能可以分为四组：

• TMDS 差分对：包括 3 组数据通道（TMDS Data0/1/2）和 1 组时钟通道（TMDS Clock），每组都是差分信号，负责传输音视频数据。这是 HDMI 的核心高速通道，速率从几百 Mbps 到几 Gbps 不等。
• DDC 通道：包括 SDA 和 SCL 两根线，本质上是一组 I2C 总线，用来读取显示器的 EDID 信息。EDID 里面包含了显示器的分辨率、刷新率、支持的颜色格式等参数，SoC 必须读到 EDID 才能知道该输出什么格式的信号。
• CEC 通道：消费电子控制通道，用于设备之间的联动控制，比如用电视遥控器控制机顶盒。这个通道在很多项目里可以不接，但如果不接，要注意在软件层面做好处理，避免驱动报错。
• HPD 信号：热插拔检测信号，显示器插入时 HPD 会被拉高，SoC 检测到这个信号后才开始输出 TMDS 信号。如果 HPD 处理不当，会出现“显示器插着但 SoC 不知道”的情况。

我这次踩的坑就在 DDC 通道上。SDA 和 SCL 接反了，导致 SoC 根本读不到 EDID，HDMI 驱动初始化失败，显示器自然就黑屏了。

2. 核心细节解析与实操要点

2.1 I2C 开漏模式与推挽模式的本质区别

要理解为什么 SDA 和 SCL 接反会导致完全无法通信，得先从 I2C 的电气特性说起。I2C 总线是一种多主多从的总线结构，所有设备都挂在同一组 SDA 和 SCL 线上。这就带来一个问题：如果两个设备同时驱动总线，一个输出高电平、一个输出低电平，就会形成电源到地的短路，烧毁器件。

为了解决这个问题，I2C 标准规定总线必须工作在开漏模式（Open-Drain）。开漏模式下，器件的输出级只有一个 NMOS 管，漏极开路。输出低电平时，NMOS 导通，把线拉到地；输出高电平时，NMOS 关断，线处于高阻态，靠外部上拉电阻把线拉到高电平。这样任何设备都只能把线拉低，不能主动拉高，就不会出现短路冲突。

那推挽模式（Push-Pull）呢？推挽输出级有上下两个管子，上管导通时输出高电平，下管导通时输出低电平，驱动能力强，上升沿陡峭。推挽模式适合点对点的单主单从通信，比如 SPI 总线，但不适合 I2C 这种多设备总线。

这里有一个常见的误区：很多人以为 I2C 的 SDA 和 SCL 都必须用开漏模式，其实不完全对。SCL 线在标准模式下确实应该用开漏，因为时钟同步机制需要多个主设备通过线与逻辑来同步时钟。但在实际工程中，如果总线上只有一个主设备，SCL 也可以用推挽模式来获得更陡峭的上升沿，提高通信速率。不过这种做法不符合标准，兼容性有风险，我不建议在正式产品里这么干。

SDA 线则必须用开漏模式，因为数据线需要双向传输，主设备发数据时从设备要能拉低 ACK，从设备发数据时主设备要能拉低 NACK，只有开漏模式才能实现这种双向线与逻辑。

回到我的问题：SDA 和 SCL 接反后，SoC 的 I2C 控制器在 SCL 线上发送时钟信号，但实际连到了显示器的 SDA 引脚；在 SDA 线上发送数据，但实际连到了显示器的 SCL 引脚。显示器的 EDID 芯片检测不到正确的时钟信号，自然不会响应，SoC 读 EDID 超时，HDMI 驱动初始化失败。

2.2 HDMI DDC 通道的上拉电阻计算

I2C 总线在开漏模式下，上拉电阻的选型非常关键。阻值太大，上升沿太慢，高速通信时波形会变成“圆角”，导致误码；阻值太小，低电平时灌电流太大，可能超过器件的驱动能力。

上拉电阻的计算公式是：

Rp(max) = tr / (0.8473 × Cb)

其中 tr 是允许的最大上升时间，Cb 是总线电容。对于 HDMI 的 DDC 通道，标准规定工作在 100kHz 以下的低速模式，最大上升时间 tr = 1000ns。总线电容 Cb 包括 PCB 走线电容、连接器电容和器件引脚电容，一般估算为 100pF 到 200pF。

代入公式：Rp(max) = 1000ns / (0.8473 × 200pF) ≈ 5.9kΩ。

所以上拉电阻不能超过 5.9kΩ。那下限呢？下限由低电平时的灌电流决定。I2C 标准规定低电平最大电压 VOL = 0.4V，最大灌电流 IOL = 3mA。所以：

Rp(min) = (VDD - VOL) / IOL = (3.3V - 0.4V) / 3mA ≈ 967Ω

综合来看，3.3V 电平域下，HDMI DDC 通道的上拉电阻建议在 1kΩ 到 5.9kΩ 之间，常用值是 2.2kΩ 或 4.7kΩ。我这次用的是 4.7kΩ，实测波形上升沿在 800ns 左右，满足要求。

但这里有个细节：HDMI 的 DDC 通道在显示器端通常已经有上拉电阻了，一般是 2.2kΩ 上拉到 5V。如果主板端再加一组上拉，等效阻值会变小，可能导致低电平灌电流超标。所以正确的做法是：先确认显示器端的上拉情况，如果显示器端已经有上拉，主板端可以不加，或者只加一个 10kΩ 的弱上拉作为备份。

2.3 电平转换的必要性与方案选型

前面提到，HDMI 的 DDC 通道工作在 5V 电平域，而 RK3576 的 I2C 控制器工作在 3.3V 或 1.8V 电平域。如果不做电平转换，直接把 5V 的 DDC 线接到 SoC 的 I2C 引脚上，可能会损坏 SoC 的 IO。

电平转换的方案有几种：

• MOSFET 电平转换：用一颗 N 沟道 MOSFET，源极接低压侧，漏极接高压侧，栅极接低压侧电源。这是最经典的双向电平转换方案，成本低，适合 I2C 这种双向总线。缺点是上升沿需要靠上拉电阻，速率不能太高。
• 专用电平转换芯片：比如 TXS0102、PCA9306 这类专门为 I2C 设计的电平转换芯片，内部集成了上拉和方向控制，使用方便，但成本略高。
• 电阻分压：在高压侧到低压侧之间串一个电阻，配合低压侧的上拉电阻分压。这种方案只适合单向通信，I2C 是双向的，不适用。

我这次用的是 MOSFET 方案，选了一颗 2N7002，源极接 3.3V 侧，漏极接 5V 侧，栅极接 3.3V。实测下来，3.3V 侧的低电平可以正常拉到 0V，5V 侧的低电平可以拉到 0.3V 左右，满足 I2C 的 VOL 要求。

但这里有一个坑：MOSFET 的体二极管方向要注意。如果接反了，高压侧的 5V 会通过体二极管灌到低压侧，可能损坏 SoC。正确的接法是：源极接低压侧，漏极接高压侧，体二极管从源极指向漏极，这样高压侧的电流不会倒灌。

3. 实操过程与核心环节实现

3.1 硬件排查：从波形入手定位问题

板子打回来之后，我先用万用表量了一下 HDMI 接口的 DDC 引脚对地阻值，没有短路。然后上电，用示波器抓 I2C 波形。这里有个操作细节：HDMI 接口的引脚间距很小，普通示波器探针太粗，容易短路相邻引脚。我用的是细针探针，配合一个 HDMI 公头转接板，把信号引出来再抓波形。

抓到的波形很有意思：SCL 线上有时钟信号，但 SDA 线上没有数据，而且 SCL 的波形上升沿很慢，大概在 1.5μs 左右。这说明两个问题：第一，SDA 线上没有数据，可能是 SoC 根本没发出数据，也可能是数据发出去了但显示器没响应；第二，SCL 上升沿太慢，说明上拉电阻偏大或者总线电容偏大。

我先检查了上拉电阻，确认是 4.7kΩ，理论上不应该这么慢。然后我用万用表量了一下 SCL 和 SDA 对地的电容，发现 SCL 对地电容有 300pF 左右，比预期高了不少。后来发现是 PCB 走线太长，而且走线旁边有一根 5V 电源线，产生了寄生电容。

但这不是根本问题。我接着用逻辑分析仪抓了一次完整的 I2C 通信过程，发现 SoC 发出的地址是 0x50，这是 EDID 的标准地址。但显示器没有任何 ACK 响应。我换了一台显示器，还是一样。这时候我开始怀疑是线序问题。

我把 HDMI 线剪开，用万用表量了一下线序，发现主板端的 SDA 连到了显示器的 SCL，SCL 连到了显示器的 SDA。这就是问题所在。

3.2 硬件修复：飞线与重新打板

找到问题后，我先用飞线做了临时修复。把主板端的 SDA 和 SCL 对调，重新上电，显示器立刻亮了。这说明问题确实出在线序上。

但飞线只是临时方案，正式产品必须重新打板。在重新打板之前，我做了几件事：

第一，重新检查了原理图。发现是画原理图的时候，HDMI 连接器的引脚定义搞错了。我用的 HDMI 连接器是标准 Type-A 母座，引脚 15 是 SCL，引脚 16 是 SDA。但我在画原理图的时候，把这两个引脚标反了。这种错误在原理图阶段很难发现，因为引脚名称看起来都对，只有对照连接器的机械图才能发现。

第二，在 PCB 布局上做了优化。把 I2C 走线尽量缩短，远离电源线和高速差分线。I2C 走线旁边加了地线屏蔽，减少寄生电容。上拉电阻的位置也调整了，尽量靠近 SoC 端，减少走线长度。

第三，增加了测试点。在 SDA 和 SCL 线上各加了一个测试点，方便以后调试。这个经验很实用：I2C 总线一定要留测试点，不然调试的时候探针没地方放。

3.3 设备树配置：I2C 节点与 HDMI 驱动

硬件修复之后，软件层面也需要配合。RK3576 的 SDK 里，HDMI 的 DDC 通道对应的 I2C 控制器需要在设备树里正确配置。以下是我用的设备树片段：

&i2c7 { status = "okay"; clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&i2c7m0_xfer>; hdmi_ddc: hdmi-ddc@50 { compatible = "generic-edid"; reg = <0x50>; }; }; &hdmi { status = "okay"; ddc-i2c-bus = <&i2c7>; hpd-gpios = <&gpio3 RK_PC4 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&hdmi_tx_pins>; };

这里有几个关键点：

• clock-frequency设置为 100000，即 100kHz。HDMI DDC 通道的标准速率是 100kHz，不要设太高，否则波形质量跟不上。
• ddc-i2c-bus指向 I2C7，这是实际连接 DDC 的 I2C 控制器。如果这里配错了，HDMI 驱动会去读一个不存在的 I2C 总线，自然读不到 EDID。
• hpd-gpios配置了 HPD 信号对应的 GPIO。HPD 信号是热插拔检测，显示器插入时会被拉高。如果这个 GPIO 配错了，SoC 检测不到显示器插入，也不会输出 TMDS 信号。

还有一个细节：RK3576 的 HDMI 驱动在初始化时会先读 EDID，如果读不到，会重试几次，然后报错退出。如果 HPD 信号一直是低电平，驱动会认为没有显示器插入，直接不初始化。所以调试的时候，要先确认 HPD 信号是否正常。

3.4 I2C 读写 EDID 的代码实现

为了验证 I2C 通信是否正常，我写了一个简单的测试程序，直接通过 I2C 读取 EDID 数据。以下是核心代码：

#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/i2c.h> #include <linux/i2c-dev.h> #define EDID_ADDR 0x50 #define EDID_SIZE 128 int main(void) { int fd; unsigned char buf[EDID_SIZE]; struct i2c_rdwr_ioctl_data packets; struct i2c_msg messages[2]; unsigned char reg = 0x00; fd = open("/dev/i2c-7", O_RDWR); if (fd < 0) { perror("open i2c-7 failed"); return -1; } messages[0].addr = EDID_ADDR; messages[0].flags = 0; messages[0].len = 1; messages[0].buf = &reg; messages[1].addr = EDID_ADDR; messages[1].flags = I2C_M_RD; messages[1].len = EDID_SIZE; messages[1].buf = buf; packets.msgs = messages; packets.nmsgs = 2; if (ioctl(fd, I2C_RDWR, &packets) < 0) { perror("read edid failed"); close(fd); return -1; } for (int i = 0; i < EDID_SIZE; i++) { printf("%02x ", buf[i]); if ((i + 1) % 16 == 0) printf("\n"); } close(fd); return 0; }

这段代码的逻辑是：先向 EDID 芯片写入寄存器地址 0x00，然后读取 128 字节的 EDID 数据。如果 I2C 通信正常，会打印出 EDID 的原始数据，开头应该是00 ff ff ff ff ff ff 00。如果通信失败，会报read edid failed。

实测下来，线序修复之前，这个程序会超时报错；线序修复之后，可以正常读到 EDID 数据。这个方法比看显示器有没有画面更直接，推荐在调试初期就用。

4. 常见问题与排查技巧实录

4.1 HDMI 无信号问题速查表

在调试 HDMI 输出的过程中，我整理了一份常见问题速查表，覆盖了从硬件到软件的主要排查点：

这张表是我在实际调试中总结出来的，基本上覆盖了 HDMI 调试中 90% 以上的问题。其中“SDA/SCL 接反”这一项，就是我这次踩的坑，放在表格里提醒自己以后不要再犯。

4.2 I2C 调试的独家避坑技巧

I2C 调试有几个技巧，是常规文档里不会写的，但实际用起来非常管用：

第一，先用万用表量静态电平。I2C 总线在空闲状态下，SDA 和 SCL 都应该被上拉到高电平。如果量出来是低电平，说明有器件在拉低总线，或者上拉电阻没焊。这个检查只需要 10 秒钟，但能排除很多低级问题。

第二，用示波器看上升沿。I2C 的上升沿时间直接反映了上拉电阻和总线电容的匹配情况。如果上升沿超过 1μs，说明上拉电阻偏大或者总线电容偏大。这时候可以尝试减小上拉电阻，或者缩短走线。

第三，用逻辑分析仪抓完整通信过程。示波器只能看波形质量，逻辑分析仪可以解码 I2C 协议，直接看到地址、数据和 ACK/NACK。如果 SoC 发出了地址但没有收到 ACK，说明从设备没有响应，可能是地址错了、从设备没供电、或者线序错了。

第四，注意 I2C 的时钟延展。有些从设备（比如 EDID 芯片）在处理数据时需要时间，会拉低 SCL 线来延展时钟。如果主设备不支持时钟延展，通信会失败。RK3576 的 I2C 控制器支持时钟延展，但需要在设备树里确认配置。

第五，电平转换芯片的方向要接对。用 MOSFET 做电平转换时，源极接低压侧，漏极接高压侧，栅极接低压侧电源。如果接反了，高压侧的电压会通过体二极管灌到低压侧，可能损坏 SoC。

4.3 从这次踩坑中总结的设计检查清单

这次踩坑之后，我整理了一份 HDMI 接口设计的检查清单，在以后的项目里每次打板前都会对照检查：

• 原理图检查：HDMI 连接器的引脚定义是否与机械图一致？SDA 和 SCL 是否接对？HPD 是否接对？CEC 是否需要接？
• 电平转换检查：DDC 通道是否需要电平转换？电平转换芯片的方向是否接对？上拉电阻是否计算正确？
• PCB 布局检查：TMDS 差分对是否等长？阻抗是否控制在 100Ω？I2C 走线是否远离电源和高速信号？测试点是否预留？
• 设备树检查：I2C 控制器编号是否与硬件一致？clock-frequency 是否设置为 100kHz？HPD GPIO 是否配置正确？
• 软件调试检查：I2C 工具是否能读到 EDID？HPD 信号是否能被检测到？HDMI 驱动是否正常加载？

这份清单看起来简单，但每一条都是血泪教训。特别是“原理图检查”这一条，我这次就是栽在这里。HDMI 连接器的引脚定义，不同厂家、不同封装可能不一样，一定要对照机械图逐脚确认，不能凭记忆。

4.4 关于 I2C 扩展与多设备挂载的注意事项

在实际项目中，I2C 总线上往往不止挂一个设备。比如 HDMI 的 DDC 通道，除了 EDID 芯片，可能还有 CEC 控制器、HDCP 密钥芯片等。多设备挂载时，有几个问题要注意：

地址冲突：I2C 设备的地址是 7 位的，范围是 0x00 到 0x7F。EDID 的标准地址是 0x50，CEC 的地址通常是 0x3C 或 0x3D。如果总线上有其他设备也用了这些地址，就会冲突。解决方法是换一个 I2C 控制器，或者用 I2C 多路复用器（比如 PCA9548）来隔离。

总线电容：每增加一个设备，总线电容就会增加。I2C 标准规定总线电容不能超过 400pF。如果设备太多，电容超标，波形会严重变形。这时候需要减小上拉电阻，或者用 I2C 缓冲器来分段驱动。

上拉电阻的取舍：多设备挂载时，每个设备可能都有自己的上拉电阻。如果所有上拉电阻都焊上，等效阻值会变得很小，低电平灌电流可能超标。正确的做法是：只保留一组上拉电阻，其他设备的上拉电阻不焊。具体保留哪一组，要看总线的主设备是谁，通常保留靠近主设备的那一组。

电平转换的兼容性：如果总线上既有 3.3V 设备又有 5V 设备，电平转换是必须的。但电平转换芯片本身也有电容和延迟，会增加总线负载。选型时要选低电容、低延迟的型号。

这次踩坑虽然折腾了两天，但收获很大。最大的体会是：嵌入式硬件设计里，没有“理所当然”的事情。每一个信号、每一个引脚、每一个电阻，都要有明确的依据和验证。凭经验、凭记忆、凭感觉，迟早会踩坑。希望这篇记录能帮到正在做类似项目的朋友，少走一些弯路。