一、USB Type-C 与 PD 概述
1.1 USB Type-C 接口的物理特性
说到 Type-C，大家可能第一反应是「那个扁扁的口」。没错，但作为硬件工程师，我们要看的是它背后的物理层设计。Type-C 接口有 24 个引脚，这比我们以前用的 Type-A 或 Micro-B 多太多了。为什么需要这么多引脚？其实就是为了支持更高的功率、更快的速率，以及正反插。
我个人习惯把 Type-C 的引脚分成三组来看：
- 电源和地（VBUS, GND）：最多 4 个 VBUS 和 4 个 GND，承担大电流传输。我最早做 Type-C 项目时就踩过坑——以为两个 VBUS 并联就够了，结果 3A 电流一跑，接口发热严重。
- 高速数据线（TX/RX, D+, D-）：两组 SuperSpeed 差分对（TX/RX），一组 USB 2.0 差分线（D+/D-）。要注意的是，实际应用中 D+/D- 在 CC 逻辑协商后才真正接通。
- 配置通道（CC1, CC2）：这是 Type-C 的灵魂引脚。它们负责检测正反插、协商供电协议（PD）、识别电子标签芯片等。
一定要记住：CC1 和 CC2 是 Type-C 系统中最重要的两个引脚。如果 CC 信号出问题，整个 PD 协商都转不起来。
1.2 PD 协议发展历史
USB PD 协议从 1.0 走到现在的 3.2，这中间变化挺大的。我简单梳理一下关键节点：
| 协议版本 | 发布时间 | 最大功率 | 核心特点 |
|---|---|---|---|
| PD 1.0 | 2012年 | 100W（20V/5A） | 首次引入功率协商概念 |
| PD 2.0 | 2014年 | 100W | 基于 Type-C，替代旧版接口；增加 PPS |
| PD 3.0 | 2015年 | 240W（48V/5A） | 引入快充策略（FRS）、电源角色可编程；规整消息格式 |
| PD 3.1 | 2021年 | 240W | 扩展功率范围 EPR，支持 28V/36V/48V；AVS 调压 |
我刚开始接触 PD 协议时，还是 PD 2.0 的天下。那时候最头疼的就是 CC 逻辑——为什么两个 CC 引脚要同时检测？后来才明白，这是为了兼容正反插和各种附件模式。说白了，Type-C 的物理层设计是和 PD 协议深度绑定的。
避坑提示：我曾经只看了 Type-C 标准的需求，以为 100W 就是 20V/5A 一条路走到黑。后来 PD 3.1 加入了 48V，直接让充电器设计翻了一倍。所以做产品时，一定要搞清楚你的目标市场最需要哪种功率等级。
1.3 PD 协议层到底在干什么
大多数硬件工程师可能觉得，PD 协议不就是协商电压电流吗？其实不止这些。PD 协议层定义了完整的消息交互流程：
- 物理层：基于 BMC（双向曼彻斯特编码）在 CC 线上通信，速率 300kbps～1Mbps。
- 协议层：定义消息类型，包括控制消息（比如 Get_Source_Cap）、数据消息（比如 Source_Capabilities）、扩展消息（比如制造商信息）。
- 策略引擎：负责决定当前设备应该当 Source 还是 Sink，以及什么时候改变功率。
非常重要：很多同学以为 PD 协商只在插拔瞬间完成一次。错了！PD 协议随时可以因为负载变化、线缆热插拔或电源枯竭而重新协商。所以你的固件必须能实时响应 PD 消息。
1.4 应用场景：不止是充电
PD 协议最开始是为了充电，但现在它的应用范围远超当初的设计目标。我在项目中遇到过以下场景：
- 大功率充电：从 15W 到 240W，覆盖手机、笔记本、显示器到工业设备。
- 视频传输：DisplayPort Alt Mode 和 HDMI Alt Mode，一条 Type-C 线同时传视频和供电。
- 音频/附件：通过 Audio Adapter Accessory Mode 或模拟音频模式转接耳机。
- 调试与 DFU：利用 CC 线的调试能力做固件更新或调试信息输出。
嗯，说到这里，你会不会觉得 PD 协议其实比想象中要「重」？它已经不单纯是一个充电协议了，更像一个通用的设备控制总线。
1.5 第一章核心框架图
为了方便理解 Type-C 与 PD 的层级关系，我习惯这样画图：
这张图展示了 Type-C 和 PD 的三层结构。物理层负责连接，协议层负责消息交互，策略引擎决定整个系统的行为。在实际调试中，很多问题都出在最底层的 CC 信号质量上——我见过不少因为 CC 线阻抗不匹配导致无法协商的案例。
经验分享：我在用示波器看 CC 波形时，一定要确保探头地线尽量短。BMC 信号的边沿速度很快，地环路一大，信号就失真了。嗯，这个习惯我一直在用。
1.6 为什么搞懂这些对信号调试很重要
你可能会问：「我只是个硬件工程师，知道协议层的事情做什么？」我个人的体会是，PD 的物理层和协议层是互锁的。比如，CC 线上的噪声会导致 BMC 解码出错，然后协议层就收不到正确的消息，整个协商会超时或失败。这时候光看眼图是解决不了问题的，你还需要理解协议层的时序窗口。