1. Type-C接口概述：物理层、CC逻辑与角色定义

大家好，我是你们的讲师。今天咱们聊聊Type-C接口。说实话，我刚入行那会儿，Type-C还是个新鲜玩意儿。那时候我还在用Micro-USB做项目，每次插拔都要看方向，烦得很。后来Type-C一出来，我第一反应是——终于不用再教用户怎么插线了。

但真正深入之后才发现，Type-C远不止是「正反随便插」这么简单。它背后有一套完整的物理层规范、CC逻辑控制，还有PD协议来支撑。今天这一章，咱们就把这些基础打牢。

1.1 Type-C物理层特性

Type-C接口有24个引脚。你没看错，24个。相比Micro-USB的5个引脚，这简直是质的飞跃。我刚开始看Type-C的引脚定义时，说实话有点懵。但用多了就会发现，这些引脚其实分成了几大类：

• 电源引脚：VBUS（4个）、GND（4个）—— 承载大电流用的
• 数据引脚：D+/D-（2个）—— 兼容USB 2.0
• 高速数据引脚：TX1/TX2、RX1/RX2（8个）—— USB 3.x/4、DP、PCIe 都走这里
• 配置通道引脚：CC1/CC2（2个）—— 这是Type-C的灵魂
• 边带使用引脚：SBU1/SBU2（2个）—— 音频、调试等

这里有个细节我想强调一下。Type-C的VBUS和GND各有4个引脚，这不是浪费。我做过一个项目，需要给设备提供5A电流。如果只有一对VBUS/GND，接触电阻和线阻会导致严重发热。4个引脚并联，电流分摊，温升就下来了。

1.2 CC逻辑：Type-C的「大脑」

CC引脚，全称是Configuration Channel。说白了，它就是Type-C的「谈判官」。我习惯把CC逻辑理解为：两个设备插在一起后，先通过CC引脚互相打个招呼，确认一下「你是谁」、「你能给多少电」、「你要多少电」。

CC逻辑的核心机制是这样的：

1. 检测连接：通过CC1/CC2上的电阻值，判断有没有设备插入
2. 识别角色：通过CC线上的上拉/下拉电阻，确定谁是DFP（下行端口）、谁是UFP（上行端口）
3. 协商电流：通过CC线上的电压，确定默认电流等级（500mA、1.5A、3A）
4. 触发PD通信：如果需要更高功率或更复杂的功能，就启动PD协议

嗯，这里要注意。CC逻辑里有个关键参数叫Rd和Rp。Rp是上拉电阻，接在DFP端；Rd是下拉电阻，接在UFP端。我见过不少新手工程师，把这两个电阻值搞反了，结果设备死活识别不了。我曾经在一个项目中，就因为Rd电阻选错了封装，导致批量生产的板子有5%无法正常握手。排查了整整两天才找到原因。

1.3 PD协议基础

PD协议，全称是Power Delivery。它是在CC逻辑之上的一个通信协议。你想想看，CC逻辑只能协商到3A电流，但PD协议可以做到5A，甚至更高。而且PD还能协商电压——5V、9V、15V、20V，都可以谈。

PD协议的通信方式很有意思。它是在CC线上通过FSK（频移键控）调制的。说白了，就是在CC线上叠加一个高频信号，用来传输数据包。这个数据包的结构是这样的：

// PD数据包结构（简化版）
// 前导码 + SOP + 消息头 + 数据对象 + CRC + EOP

// 消息头示例（16位）
Bit 15-12: 消息类型（0=控制消息，1=数据消息）
Bit 11-9:  端口号
Bit 8-5:   消息ID
Bit 4-0:   数据对象数量

PD协议定义了多种消息类型。我常用的有：

• Source_Capabilities：电源端告诉设备「我能提供这些电压电流组合」
• Request：设备端告诉电源「我要这个电压电流组合」
• Accept/Reject：电源端回应「行」或「不行」
• PS_RDY：电源端说「电压已经切换好了，你可以用了」

我记得第一次调试PD协议时，设备端一直收不到Source_Capabilities。我查了三天，最后发现是CC线上的电容值不对，导致FSK信号被衰减了。嗯，这种坑踩过一次就记住了。

1.4 DFP/UFP/DRP角色定义

这三个角色，是Type-C生态里的「身份标签」。我刚开始接触时，总觉得这些概念很绕。其实说白了很简单：

角色	全称	说白了就是	典型设备
DFP	Downstream Facing Port	「供电方」，向下游提供电源和数据	充电器、电脑USB口
UFP	Upstream Facing Port	「受电方」，向上游请求电源和数据	手机、外设
DRP	Dual Role Port	「墙头草」，既能当DFP也能当UFP	笔记本、移动电源

DRP的实现稍微复杂一些。它会在DFP和UFP之间来回切换，直到和对方匹配上。我做过一个DRP的固件，切换周期是50ms。如果两个DRP设备对接，它们会通过Try.SRC和Try.SNK机制来决定谁当电源、谁当设备。

这里有个小技巧。做DRP设备时，我建议把Try.SRC的优先级设高一些。为什么呢？因为大多数用户希望自己的设备能主动给外设充电。比如你的笔记本插上手机，用户肯定希望笔记本给手机充电，而不是反过来。我曾经在一个项目中没注意这个优先级，结果笔记本插上手机后，手机开始给笔记本充电——虽然技术上没问题，但用户反馈说「这不对劲」。

1.5 从角色到固件升级的关联

讲到这里，你可能要问：这些和固件升级有什么关系？

关系大了。Type-C的固件升级，本质上就是通过Type-C接口的数据通道（D+/D-或高速数据通道）来传输固件数据。而CC逻辑和PD协议，决定了你的设备在升级过程中能不能稳定供电、能不能正确识别主机。

举个例子。如果你的设备是UFP角色，它需要通过CC逻辑从DFP那里获取足够的电流来维持升级过程。如果电流不够，升级到一半断电了——嗯，那你的设备就变砖了。我见过一个产品，就是因为没处理好PD协商，导致升级时电流不足，结果批量返厂。

所以，理解Type-C的物理层、CC逻辑、PD协议和角色定义，是做固件升级的基础。后面几章，我们会一步步深入，把这些知识用到实际的OTA实现中。