TCPC简介

TCPC 是 USB Type-C Port Controller 的首字母缩写,翻译成中文就是通用串行总线 C 型端口控制器,简单点说就是 USB-C 型端口控制器,也就是说一个 USB-C 型端口要做的事情它得全管,这句话说起来有点笼统,需要深入标准去看看是咋回事。
USB Type-C Port Controller Interface Specification (USB-C 型端口控制器接口规范,可简称 TCPCI 规范)里是这样来描述 TCPC 的:The TCPC is a functional block which encapsulates VBUS and VCONN power controls, USB Type-C CC logic, and the USB PD BMC physical layer and protocol layer other than the message creation. 这话的意思是说 TCPC 是个功能块,其中含有 VBUS 和 VCONN 的电源控制功能、CC 信号的处理逻辑、USB PD 应用中的 BMC 物理层和协议层(也就是 PD 信息的编码发送、接收和处理过程都在里面了),而信息的生成是不包含在其中的。这个功能块在现实中的位置在哪里呢?我们常常会看到论及 TCPC 的地方会有下面这幅图:

 


另有一幅图是这样的:

 

这两幅图其实是一回事,只不过是一个带有多个 TCPC,一个只有一个 TCPC,它们要表达的重点是中间画圈的部分即 TCPCI(TCPC Interface,TCPC 接口),意思是说 USB-IF 制订了一个接口标准,它通过 I2C 接口将 TCPM 即 USB Type-C Port Manager(USB-C 型端口管理器)和 TCPC 连接起来,所有的 TCPC 产品都以此标准进行设计,意即 TCPM 看到的 TCPC 都是标准化的,它们内部都有大量的寄存器挂在 I2C 接口上,这些寄存器的地址和内容绝大部分都是相同的,只有扩展的部分才是容许厂家自己定义的,当你对不同型号的 TCPC 的同一个地址的寄存器进行读写操作时,能够起到的作用都是相同的(除非该 TCPC 的设计不支持这个功能,或是它容许厂家自己定义其具体内容,但凡遇到这样的状况时也都会在其设计里被明示出来,例如我们的 RT1715 就明确说明它不支持 PD3.0 的 Fast Role Swap 功能),这样就简化了 TCPM 的设计,它在遇到任何 TCPC 时都有一样的功能,啥都不需要修改,除非遇到了不支持的状况或是自定义的状况。所以真正的 TCPC 其实只是前面两幅图中的下半部分所展示的内容,其中的小方块表示它含有的功能或是模块,下面与之连接的自然是实际中的 USB 端口的物理部分,就像下图中的 RT1718S 上边和左边所连接到的部分:

 

而 TCPM 在上图中也只能是位于右侧的 MCU/EC 之中的一个组件或说是其一个功能,只是由于 RT1718S 的构成除了 TCPC 以外还有对端口各个信号的过压保护和静电释放保护功能,所以它看起来就比较复杂了,但理解了 TCPC 后就比较容易搞清楚它是怎么回事了。
TCPCI 规范以需求的形式对 TCPC 要完成的工作进行了说明,前面已经说过它包含三个部分,下面对此进行简单说明。
TCPC 需要完成的第一部分工作是对 VBUS 和 VCONN 电源进行管控。

VBUS 就是通过 USB 线传输的电源正极端,它的电压在 USB诞生的时候就是 5V,能传输的电流随着 USB 的不断升级从百 mA 级一直往上增长,到了 C 型接口出现后发展到最大 3A,在 PD 协议出现以后就发展到了 5A,现在它可传输的电压已到了 48V,所以通过VBUS 已经可以传输高达 240W 的功率了,但其最基本的规格仍然还是 5V,只有利用 PD 协议才使其规格可以在工作过程中进行改变,但 TCPCI 对此并不关心,它提供的只是一个通道而已。实际是有关 PD 的协议在通过 TCPC 的时候是不会被解读的,它们会直接通过 TCPC 进行传输,到了 TCPM 以后才会被处理,其处理结果会反应在 VBUS 电压的变化上,而 TCPC 却可以对 VBUS 电压进行监测、对 VBUS 通道进行开关控制,到了连接中断时还会对 VBUS 通道进行放电处理以确保安全。如果某个器件将 TCPC 和电压转换器的功能集成在一起了,那么这里所说的 TCPM 对 VBUS 电压的调整功能也会被集成在其中,对于用户来说就变成完全透明的了,只需要将其拿来使用即可,很可能完全不需要自己去做软件设计等操作,而立锜的很多高度集成的产品便是这样做的,对用户来说会非常友好,但是技术支持的力度却要增强,因为不同用户的不同需求都需要在产品设计中予以满足,这就要有针对性的服务才能实现。

对于连接在 USB 上的不同设备来说,有的可作为电源的供应端,有的可作为用电端,还有的可以在两个角色之间进行转换,它们的这种能力分别被定义为 Source、Sink 和 DRP,TCPC 中就定义了很多寄存器来对这些角色的实现或是转换等进行控制,实际实施的时候就需要 TCPM 根据不同的角色和需要随时对 TCPC 的寄存器进行操控以实现其应用目标,这也导致不同角色的 TCPC 需要去完成不同的任务。
VCONN 的作用和 VBUS 有点类似,其生成的位置也是供电端,但使用它的电路位于电缆之中,如 USB-C 型电缆上的电子标签就需要它来供电,其电压、电流和功率也需要是可控的,TCPC 内部也有寄存器可用于 VCONN 的生成和控制。
下面的几个表格是从 TCPCI 规范中截取下来的,它们说明了不同角色的 USB 设备中的 TCPC 需要完成的工作,有兴趣的读者可以仔细看看。

 

 

 

TCPC 需要完成的第二部分任务是对 CC 信号进行处理,其中涉及角色判断、对 CC 线的状态进行监测、根据需要使用 Rp/Rd 等等。到了 PD 协议上场以后,TCPC 又新增了对 PD 协议信息的传输能力,其中就有 BMC 编解码、信息的存储和收发等内容,这就构成了 TCPC 需要完成的第三个任务,使得 TCPM 完全不需要去关心 PD 协议是如何传输的,它只管根据自己的需要去生成和处理信息即可,传输上的事情都丢给 TCPC 了。
TCPM 在与 TCPC 通讯的时候处理的都是 TCPC 内部的寄存器,这些寄存器在规范中的定义如下表所示:

 

 

详细解读表中信息的工作量会很大,TCPCI 规范和我们的产品如 RT1718S 规格书都用了很大的篇幅来列出寄存器的详细信息,需要做详细设计的人肯定要去仔细研究,作为大概的了解就不必了,但是浏览一下还是能找到一些乐趣,例如我们可以从寄存器的排序上看出它的发展历程,PD 协议是后来才有的,它的发送和接收寄存器也被排在后面,这大概就是先来后到的影响吧,但这也只是我自己的看法,因为我并没有对多个版本的规范进行比较;扩展定义是厂家需要的,它的排序就在最后的 80h…FFh,这也在 RT1718S 的寄存器配置上表现出来,它的超出 TCPC 定义范围以外的东西都在地址 80h 以后的寄存器里进行表达,使用它的用户必须对它们进行操作,同时立锜的技术支持人员也能在其开发工作中提供支持,已有的一些源码应该是可以提供给大家参考使用的,至少有一些定义可以供你使用,就这也可以减少不小的工作量,

 

很抱歉,我无法直接为您提供完整的协议栈代码。协议栈的实现可能因硬件和操作系统不同而有所不同,需要根据具体情况进行适当的修改。 以下是一些常用协议栈的简介及其相关资源,供您参考: 1. WIFI协议栈:WIFI协议栈主要包括PHY层、MAC层和网络层。常用的WIFI协议包括IEEE 802.11a/b/g/n/ac/ax等。如果您需要实现WIFI协议栈,您可以参考以下资源: - ESP8266 WIFI模块源代码:https://github.com/espressif/esp8266-rtos-sdk/tree/master/components/esp8266/include/driver/include/driver - ESP32 WIFI模块源代码:https://github.com/espressif/esp-idf/tree/master/components/esp_wifi - Linux下的WIFI实现:https://wireless.wiki.kernel.org/en/developers/documentation/wireless-drivers 2. 蓝牙协议栈:蓝牙协议栈主要包括PHY层、MAC层、L2CAP层、RFCOMM层、SDP层等。常用的蓝牙协议包括BLE、Classic Bluetooth等。如果您需要实现蓝牙协议栈,您可以参考以下资源: - BlueZ蓝牙协议栈:https://git.kernel.org/pub/scm/bluetooth/bluez.git/ - Android蓝牙协议栈:https://android.googlesource.com/platform/system/bt/ - Nordic Semiconductor的nRF5 SDK:https://www.nordicsemi.com/Software-and-Tools/Software/nRF5-SDK 3. TCP/IP协议栈:TCP/IP协议栈主要包括物理层、数据链路层、网络层、传输层和应用层。常用的TCP/IP协议包括TCP、UDP、IP等。如果您需要实现TCP/IP协议栈,您可以参考以下资源: - lwIP协议栈:http://www.nongnu.org/lwip/ - Linux内核中的TCP/IP协议栈实现:https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt - Contiki OS中的TCP/IP协议栈实现:https://github.com/contiki-os/contiki/tree/master/os/net 4. CoAP协议栈:CoAP协议栈是一种轻量级的RESTful协议,适用于物联网设备之间的通信。如果您需要实现CoAP协议栈,您可以参考以下资源: - Erbium CoAP协议栈:https://github.com/contiki-os/er-coap - LibCoAP协议栈:https://github.com/obgm/libcoap - Californium CoAP协议栈:https://github.com/eclipse/californium 5. MQTT协议栈:MQTT协议栈是一种轻量级的消息协议,适用于物联网设备之间的通信。如果您需要实现MQTT协议栈,您可以参考以下资源: - Paho MQTT协议栈:https://github.com/eclipse/paho.mqtt.embedded-c - Mosquitto MQTT协议栈:https://github.com/eclipse/mosquitto - Eclipse IoT MQTT协议栈:https://www.eclipse.org/paho/clients/c/embedded/ 6. HTTP(S)协议栈:HTTP(S)协议栈是一种广泛应用于互联网上的应用层协议。如果您需要实现HTTP(S)协议栈,您可以参考以下资源: - Mongoose HTTP(S)协议栈:https://github.com/cesanta/mongoose - libcurl HTTP(S)协议栈:https://curl.se/libcurl/ - Microchip HTTP(S)协议栈:https://www.microchip.com/design-centers/wireless-connectivity/wifi/products/wi-fi-software/mrf24w-software 7. SSL/TLS协议栈:SSL/TLS协议栈是一种安全传输协议,适用于互联网上的安全通信。如果您需要实现SSL/TLS协议栈,您可以参考以下资源: - OpenSSL SSL/TLS协议栈:https://www.openssl.org/ - wolfSSL SSL/TLS协议栈:https://www.wolfssl.com/ - mbed TLS SSL/TLS协议栈:https://tls.mbed.org/
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值