跳转至

I3C：I2C 的下一代总线

做嵌入式开发的朋友，I2C 一定不陌生——两根线、简单好用，连接传感器、EEPROM、各种小外设，几乎成了低速通信的"万金油"。但你可能还没听说过它的继任者：I3C（Improved Inter-Integrated Circuit，改进型集成电路总线）。

这篇文章就来聊聊 I3C 是什么、为什么诞生、比 I2C 强在哪里，以及什么时候你真的应该考虑它。

1. I2C 的痛点

I2C 诞生于上世纪 80 年代，距今已经 40 多年了。虽然它在大多数低速场景下依然够用，但随着 IoT、可穿戴、自动驾驶等场景的爆发，I2C 的短板开始凸显：

速度慢：I2C 常见速率包括 Standard-mode 100 kbps、Fast-mode 400 kbps、Fast-mode Plus 1 Mbps；High-speed mode 可到 3.4 Mbps，但实际在普通传感器系统中并不常见。

地址固定：7-bit 地址在设计阶段就要定死，多设备时容易冲突

无带内中断：设备有事要汇报只能靠额外的 GPIO 中断引脚，消耗 IO 口

功耗优化弱：电源管理机制匮乏，对电池供电设备不友好

2. I3C 登场：MIPI 联盟的答案

I3C 由 MIPI Alliance（手机行业接口联盟）主导制定，目标是在保持 I2C 兼容性的前提下，把速度、功耗、功能全面升级。它的设计初衷来自对手机、IoT、MEMS 传感器厂商的广泛需求调研。

最关键的一点：I3C 仍然使用 SDA + SCL 两根线，并支持与部分 Legacy I2C 设备共存。但混合总线并不是“无条件兼容”，I2C 设备通常需要满足毛刺滤波等条件，并且不能通过 I3C DAA 自动发现，系统软件仍需静态描述这些 I2C 设备。

I3C 总线拓扑示意

image-20260427225327239

I3C 与 I2C 设备可共存于同一总线，控制器自动识别并切换通信方式

3. I3C vs I2C 区别对比

image-20260501010839453image-20260501010900527

  • I3C 可以理解为 I2C 的升级版。 它仍然保留两根线的总线形式，但在速度、功耗、地址管理、中断机制和错误检测方面都做了明显增强。

相比 I2C，I3C 的优势主要有：

  • • 速度更快：I2C 常见是 400 kbps 到 1 Mbps，I3C SDR 可到约 11 Mbps，HDR-DDR 可到约 20 Mbps，速度提升明显。
  • • 功耗更低：I2C 依赖开漏和上拉电阻，功耗相对更高；I3C 大部分时间使用 push-pull，效率更高。
  • • 支持带内中断：I2C 设备通常需要额外 INT 引脚；I3C 可以直接通过总线发起中断，减少 GPIO 占用。
  • • 支持动态地址分配：I2C 地址一般是静态的，容易冲突；I3C 可以在初始化时动态分配地址。
  • • 错误检测更完善：I2C 协议本身没有标准化错误检测；I3C 把主从两侧的错误检测标准化了。
  • • 内置命令更丰富：I2C 基本靠自定义协议；I3C 有标准化的 CCC 命令，用于设备发现、总线管理、时间控制等。

四大核心特性，展开讲讲

  • Push-Pull 驱动：I2C 用开漏输出，上升沿靠上拉电阻，速度受限。I2C 主要依赖开漏输出和上拉电阻，上升沿受 RC 时间常数影响。I3C 在部分阶段仍保留开漏用于兼容和仲裁，但在 SDR 数据传输阶段使用推挽方式，因此可以在相近引脚数量下获得更高有效吞吐。
  • 带内中断（IBI） 设备可在总线上直接拉低 SDA 向主控报中断，不需要额外 INT 引脚，节省 GPIO、简化 PCB 布线。
  • 动态地址分配（DAA） 设备上电后由主控统一分配地址，根据设备的唯一 ID 区分，再也不怕多设备地址冲突。
  • 热插拔（Hot-Join） 设备随时接入总线并发起加入请求，系统无需重启即可识别并通信，适合动态扩展的系统。

4. I3C 时序

本章节可以参考：NXP Tech Days 2022

I3C当中，可以看到，I3C 是支持 I2C 的，I3C 设备分为主设备和从设备；

设备类型：

  • I3C 主设备 -----SDR-only master

  • I3C secondary MASTER -----SDR-only secondary master（注意是 main master 的 slave，即相对于主设备而言仍然是从设备）

  • I3C 从设备 -----SDR only slave

4.1 I3C读写时序

image-20260427231958416

写操作和 I2C 几乎一模一样，唯一的区别在第 5 个字段：I2C 用 ACK/NACK 应答，I3C 换成了 T-bit（奇偶校验位）。T-bit 由发送方驱动，接收方通过它判断数据完整性，不再依赖对端拉低应答——这让总线驱动逻辑更简洁。

读操作的差异更值得关注。I3C 中从机可以主动结束读传输：T-bit = 0 时从机终止，T-bit = 1 + 释放总线（Z）则继续。而 I2C 只能由主机决定何时停止读，从机没有发言权。这个改变在读传感器 FIFO 数据时非常实用——传感器数据读完了可以自己"举手"告诉主机别再读了。

4.2 SDR 传输关键

image-20260427232019472

左图是 START 条件，与 I2C 完全相同——SCL 高电平期间 SDA 由高变低，兼容所有存量 I2C 设备。

中图是开漏地址阶段的时钟特征：SCL 高电平仅约 45 ns，远低于 I2C 要求的 50 ns 毛刺滤波门限。I3C 正是利用这一点——I2C 设备的滤波器会把这段时钟"滤掉"，从而感知不到 I3C 的推挽数据传输，实现在同一总线上的透明共存，最终实际频率约 4 MHz。

右图是 ACK 之后的模式切换：主机收到从机 ACK 后，立即将 SDA 切换为推挽驱动，SCL 频率从 4 MHz 跃升至 12.5 MHz，进入高速数据传输阶段。时钟周期压缩到 80 ns，这就是 I3C 带宽远超 I2C 的核心原因。

4.3 地址仲裁

image-20260501012545478

image-20260501012601337

这两张图是 IBI 地址仲裁的完整时序过程，展示了从机 7h'5F 和 7h'77 同时发起中断时，总线如何一位一位竞争、7'77 在 A5 位输掉仲裁退出、7'5F 最终胜出并切换推挽模式的全过程。

两个从机同时将 SDA 拉低，主机检测到中断请求后启动 SCL，仲裁正式开始。总线工作在开漏 4 MHz 模式，两个从机各自驱动自己的动态地址逐位输出。

仲裁规则很简单：开漏总线"线与"，0 吃掉 1。A6 位两者都是 1，A5 位出现分歧——7'5F 的 A5 = 0，7'77 的 A5 = 1。总线被拉低到 0，7'77 读回的值与自己想发的 1 不一致，当即判定仲裁失败，释放 SDA 退出竞争，此后保持监听直到下一个 START。

7'5F 独占总线，继续发完 A4～A0 + RnW 位，主机回以 ACK 确认受理。地址握手完成后，主机立即将 SDA 切换为推挽驱动，SCL 频率从 4 MHz 跃升至 12.5 MHz，7'5F 在高速模式下发送 Mandatory Data Byte，告知主机中断原因。

整个过程没有占用任何额外引脚，也没有软件轮询，仲裁完全由硬件在总线电气层面自动完成。

4.4 DAA（动态地址分配）流程

DAA 是 I3C 总线初始化的核心机制，解决了 I2C 静态地址冲突的根本问题——同类型传感器无法共存于同一总线。整个流程由主机主导，通过仲裁逐一为每个从机分配唯一的动态地址。

第一步：ENTDAA 广播命令 主机向总线广播 ENTDAA CCC 命令（7Eh + 07h），通知所有尚未获得动态地址的 I3C 从机进入 DAA 模式。I2C 设备因为无法识别该命令格式，会自动忽略，不参与后续过程。

第二步：Repeated Start + 仲裁 主机发出 Repeated Start 条件后，所有待分配地址的 I3C 从机同时将各自的 48-bit Provisional ID（PID）送上总线进行仲裁。仲裁规则与 IBI 完全相同——开漏模式下 0 胜出，PID 数值最小的从机赢得本轮仲裁，其余从机检测到总线电平与自身输出不符后立即退出，静默等待下一轮 Repeated Start。

第三步：PID + BCR + DCR 上报 获胜从机将完整的身份信息发送给主机：

  • PID（48-bit）：是 I3C 设备用于动态地址分配的 48-bit 标识，通常包含 MIPI Manufacturer ID、类型选择位以及厂商定义或随机生成的 32-bit 字段。它的目标是让同一条总线上的设备可以被区分，避免 DAA 过程中的身份冲突。
  • BCR（Bus Characteristics Register）：声明自身能力，例如是否支持 IBI、是否可成为次级主机、最大速率等
  • DCR（Device Characteristics Register）：器件类型编码，如加速度计、陀螺仪等

image-20260501015240890

4.5 HDR-DDR 传输时序

HDR-DDR（High Data Rate – Double Data Rate）是 I3C 在不提升时钟频率的前提下将吞吐量翻倍的核心手段。SDR 模式仅在 SCL 上升沿采样，而 HDR-DDR 在上升沿和下降沿各采样一次，同样 12.5 MHz 的时钟即可实现约 20 Mbps 的净数据速率，是 SDR 的近两倍。

image-20260501015347680

进入 HDR-DDR 模式 主机通过广播 CCC 命令 ENTHDR0 通知总线切换到 HDR-DDR 模式。不支持 HDR-DDR 的从机收到该命令后会执行预定义的"忽略并等待退出模式"逻辑，不会干扰总线上其他支持 HDR-DDR 的器件正常通信。

数据编码方式 HDR-DDR 采用曼彻斯特式差分编码：每个时钟周期传输 2 bit，上升沿锁存高位，下降沿锁存低位。SDA 在 SCL 低电平期间切换，在高低电平的采样窗口保持稳定，时序余量与 SDR 推挽阶段相当，无需更改硬件 IO 规格。

帧结构与错误保护 HDR-DDR 帧包含完整的 CRC 校验（写方向和读方向均有），这是相比 SDR 的重要增强——SDR 仅依赖奇偶 T-bit，而 HDR-DDR 的 CRC 可检测多位翻转错误。帧结束时从机或主机可主动终止传输，不必像 I2C 那样由主机预先知晓数据长度。

退出机制 HDR-DDR 定义了专用的退出模式（HDR Exit Pattern）：一段在 SCL 保持高电平时 SDA 连续翻转的特殊序列，任何状态下的从机都能识别这个 Pattern 并安全回到 SDR 模式，避免因异常中断导致总线死锁。I3C v1.1 进一步将这一机制复用为 Slave Reset，主机可通过它强制复位卡死的从机，从根本上杜绝了 I2C 时代因时钟拉伸失控导致的总线挂死问题。

适用场景 HDR-DDR 适合中等数据量、需要双向通信且对错误检测有要求的场景，例如 IMU 批量读取、环境传感器连续采样等。若数据量更大（固件升级、图像传输），则应考虑 HDR-BT（Bulk Transport），后者通过多数据线可达 97 Mbps。

5. I3C 版本

I3C 由 MIPI Alliance 的 I3C Working Group 负责维护，自 2016 年首版发布至今，已经历了多轮更新。另外还有一条平行的免费开放版本线——I3C Basic，专为不想加入 MIPI 的厂商提供。

# 2016年12月：I3C v1.0 `首版`
正式奠定 I3C 核心架构：SDR 模式（12.5 Mbps）、动态地址分配（DAA）、带内中断（IBI）、Hot-Join、多控制器、向下兼容 I2C。确立 CCC 命令体系。HDR-DDR 为可选。

# 2018年7月：I3C Basic v1.0 `免费开放`
MIPI 将核心功能子集以 RAND-Z（零专利费）形式对外开放，无需加入 MIPI 即可实现。涵盖 SDR、DAA、IBI、Hot-Join，但不含 HDR-DDR 等高级模式。

#2019年12月：I3C v1.1 `新功能版`
新增多项可选功能：HDR 流控（Flow Control）、调度命令（Scheduled Commands）、Standby 模式下的次级控制器、Dead Bus 恢复机制。强制要求 Target Reset。废弃了 RSTDAA 的 Direct 形式。

# 2021年6月：I3C v1.1.1 / I3C Basic v1.1.1 `勘误更新`
纯编辑性更新，无新功能，修复 v1.1 中的不一致和技术错误。重要里程碑：正式废弃 “Master/Slave” 术语，改用 “Controller/Target”。Basic 版本此次大幅对齐 v1.1 功能，新增 HDR-DDR、HDR-BT 和 Target Reset 支持。

#2025 年：I3C v1.2 / I3C Basic v1.2 发布。
该版本主要进行文档模块化重组、澄清强制/可选特性，并补充动态地址管理、Target Reset、HDR CCC 流程、时序参数、最大消息长度、错误恢复等说明。

注：I3C v1.0/v1.1 完整规格仅 MIPI 成员可获取；I3C Basic 系列任何人均可免费下载。

image-20260427171133193

6. I3C 适合用在哪些场景？

智能手机传感器集线、汽车 ADAS 传感器、 IoT 可穿戴设备、服务器内存管理（DDR5）、 工业自动化、 医疗监测设备

特别值得一提的是 DDR5 内存——JEDEC 在 2020 年已将 I3C Basic 纳入 DDR5 的旁路总线标准（JESD403-1），用于内存模块的管理通信。这意味着 I3C 已经悄悄出现在你的电脑主板上了。

7. 现在上手，时机如何？

I3C 的生态正在快速成熟。ST、NXP、Microchip（PIC18-Q20）等主流 MCU 厂商都已推出原生支持 I3C 的芯片。Linux 内核从 5.x 版本开始也加入了 I3C 子系统支持。

不过，生态惯性是真实存在的——I2C 的器件库太庞大了。如果你的项目传输速率在 1 Mb/s 以内、没有大量传感器管脚烦恼、系统也不需要热插拔，I2C 依然是省心之选。

换个角度理解：I3C 不是要消灭 I2C，而是在 I2C 够不着的地方，提供一条更宽的路。速度需求上去了、传感器数量多了、GPIO 不够用了——这些时候 I3C 才真正发光。

8. 写在最后

嵌入式协议的演进，往往不是革命，而是渐进的升级。I3C 以最小的引脚代价，带来了性能和功能的大幅飞跃，是 MIPI 联盟在传感器总线领域交出的一份答卷。如果你正在做下一个 IoT 产品、或者在考虑传感器集线方案，不妨把 I3C 列进你的技术选型清单里——它可能比你想象的更接近你的需求。