1. 从 I2C 到 I3C为什么需要关注这个演进搞嵌入式或者驱动开发的朋友对 I2C 肯定不陌生。两根线一根 SCL 一根 SDA挂上一堆传感器、EEPROM、PMIC慢是慢了点但胜在简单可靠几乎所有 SoC 都标配。但如果你最近在看 RK3576 这类新一代处理器的手册或者 SDK 里的 DTS 文件可能会注意到一个不太熟悉的节点I3C。我第一次在 RK3576 的 dtsi 里看到i3c0、i3c1这些 label 的时候心里也犯嘀咕——这玩意儿跟 I2C 到底什么关系是不是又一个厂商搞出来的私有东西后来花时间把 MIPI 的 I3C 规范翻了一遍又在 RK3576 的 EVB 上实际跑了几轮才算把它的脾气摸清楚。先说结论I3C 不是来替代 I2C 的它是来给 I2C 续命的。I2C 从 1982 年飞利浦搞出来到现在四十多年了速率从 100kHz 一路爬到 5MHzUltra Fast Mode但物理层那套开漏结构决定了它再往上走非常吃力。而现在的传感器融合、多摄同步、高精度 IMU 这些场景对总线带宽和实时性的要求早就不是几百 kHz 能满足的了。I3C 在保持与 I2C 设备兼容的前提下把标准速率拉到 12.5MHzHDR 模式下甚至能到 33Mbps 以上这就是标题里说的“快 10 倍”的由来——当然这个 10 倍是拿 I3C SDR 12.5MHz 对比 I2C Fast Mode 400kHz 算出来的具体场景下差异会更大或更小。这篇文章我打算从实际开发的角度把 I3C 的核心特性、跟 I2C 的本质区别、RK3576 上 I3C 控制器的 DTS 配置方法以及我在调试过程中踩过的坑完整地梳理一遍。不管你是刚接触 RK 平台的新手还是已经在用 I2C 做产品、想评估要不要切到 I3C 的老手应该都能从里面找到有用的东西。文章会涉及不少寄存器级和 DTS 级的细节但我会尽量用生活化的类比把原理讲清楚保证你看完能直接上手改配置、抓波形、定位问题。2. I3C 与 I2C 的核心差异拆解2.1 物理层推挽 vs 开漏这是速度差异的根源要理解 I3C 为什么能比 I2C 快这么多得先从物理层的电气特性说起。I2C 用的是开漏输出Open-Drain总线上的每个设备只能把线拉低不能主动拉高高电平靠上拉电阻把线拽上去。这个设计的好处是天然支持多设备共享总线不会出现两个设备一个推高一个拉低导致短路的情况。但坏处也很明显上拉电阻和总线电容构成一个 RC 充电回路信号从低到高的上升沿时间被这个 RC 常数卡死了。你可以把 I2C 总线想象成一根很长的晾衣绳上面挂了很多夹子设备。想把绳子拉低很容易谁都能往下拽但想让它回到高位只能靠两端绑着的橡皮筋上拉电阻慢慢把它拉回去。绳子越长、夹子越多总线电容越大回弹就越慢。这就是为什么 I2C 速率上不去——不是控制器不想跑快是物理层不允许。I3C 的做法很聪明在 SDR 模式下它改用推挽输出Push-Pull。推挽就是每个设备都能主动把线拉高或拉低上升沿由驱动器的 PMOS 直接拉起来不再依赖上拉电阻的 RC 充电。这一下就把上升时间从微秒级压到了纳秒级速率自然就能往上翻。但推挽有个前提同一时刻只能有一个设备在驱动总线否则两个设备一个推高一个拉低就会打架。所以 I3C 在总线仲裁和方向切换上做了更严格的规定这也是它协议比 I2C 复杂的原因之一。不过 I3C 并没有完全抛弃开漏。在总线初始化阶段和带内中断In-Band Interrupt, IBI的某些环节它仍然用开漏模式来保证兼容性和安全性。这种“该推挽时推挽该开漏时开漏”的混合策略是 I3C 设计上的一个精髓。2.2 协议层从“主从轮询”到“动态角色切换”I2C 的通信模型非常简单主机发起 START发送从机地址和读写位从机 ACK然后数据传输最后 STOP。整个过程中主机是绝对的主导者从机只能被动响应。这种模型在设备少、数据量小的时候很好用但当总线上挂了十几个传感器每个都要定期读取数据时主机的轮询开销就变得很可观了。I3C 在协议层引入了几个关键机制来改善这一点第一是动态地址分配Dynamic Address Assignment, DAA。I2C 设备的地址是固定的由芯片出厂时决定或者硬件引脚配置这就导致地址冲突问题——两个设备地址一样挂同一总线上就废了。I3C 支持在总线初始化时由主控制器给每个从设备动态分配一个 7 位地址彻底解决了冲突问题。而且这个过程是标准化的所有 I3C 设备都支持。第二是带内中断IBI。I2C 里从机想通知主机“我有数据了”只能靠额外拉一根中断线。I3C 允许从机直接在总线上发起中断请求不需要额外的 GPIO。这对于引脚紧张的 SoC 来说是个很大的解放。IBI 的机制是从机在总线空闲时拉低 SDA开漏模式主控制器检测到后发起一个仲裁过程确认是哪个从机要说话然后从机把自己的地址发出来。第三是通用命令码Common Command Code, CCC。I3C 定义了一套标准命令比如GET_STATUS、SET_BUS_MODE、GET_CAPABILITIES等主机可以通过这些命令统一管理总线上的设备而不需要每个设备都定义一套私有寄存器。这有点像 USB 的枚举过程让总线管理变得规范化。第四是 HDR 模式。除了 SDRSingle Data Rate模式I3C 还定义了 HDR-DDR、HDR-TSP、HDR-TSL 等高速模式。在 HDR-DDR 模式下数据在时钟的上升沿和下降沿都采样等效速率翻倍。这也是 I3C 能跑到 33Mbps 以上的原因。2.3 兼容性I3C 总线上的 I2C 设备怎么处理这是实际项目里最关心的问题我总线上已经有一堆 I2C 传感器了换成 I3C 控制器还能用吗答案是能用但有条件。I3C 规范定义了一种叫I2C Legacy Device的兼容机制。在总线初始化阶段I3C 主控制器会先用开漏模式发送 I2C 的 START 和地址看看有没有 I2C 设备响应。如果有就把这个地址记录下来后续通信时对这个设备仍然用 I2C 的时序开漏、标准速率。对 I3C 设备则用推挽和更高速率。也就是说同一条总线上可以混挂 I2C 和 I3C 设备控制器会自动区分。但这里有几个坑要注意第一I2C 设备不支持 IBI所以如果你需要中断还是得单独拉线第二I2C 设备不支持动态地址分配地址冲突问题依然存在第三混合总线的速率会被 I2C 设备拖慢因为每次跟 I2C 设备通信都要切回开漏模式中间有模式切换开销。所以实际项目中如果总线上 I2C 设备很多I3C 的高速优势会被稀释不少。2.4 速率对比10 倍是怎么算出来的标题里说“快 10 倍”这个数字需要拆开看。I2C 常见速率有模式速率说明Standard Mode100 kHz最基础几乎所有 I2C 设备都支持Fast Mode400 kHz传感器常用Fast Mode Plus1 MHz需要更好的上拉和布线High Speed Mode3.4 MHz较少见需要额外的主机码Ultra Fast Mode5 MHz单向实际产品很少用I3C 的 SDR 模式标准速率是 12.5 MHzHDR-DDR 可以到 25 Mbps 以上。拿 12.5MHz 对比 400kHz是 31 倍对比 1MHz是 12.5 倍对比 3.4MHz是 3.7 倍。所以“10 倍”这个说法大致是拿 I3C SDR 对比 I2C Fast Mode Plus 或者 High Speed Mode 得出的。在实际数据传输中还要考虑协议开销、总线仲裁、模式切换等因素有效吞吐量的提升可能没有理论值那么夸张但3 到 10 倍的提升是实打实的。3. RK3576 上的 I3C 控制器特性3.1 RK3576 的 I3C 硬件规格RK3576 是瑞芯微新一代的中高端处理器主打 AIoT 和边缘计算场景。它的 I3C 控制器规格如下基于我手上这份 datasheet 和实际测试控制器数量RK3576 有 2 个 I3C 控制器分别是 i3c0 和 i3c1。注意不是所有 RK3576 的封装都引出这两个控制器具体要看原理图。支持模式SDR 模式速率可配置。HDR 模式在硬件上支持但当前 SDK 里的驱动对 HDR 的支持还不完整实际项目建议先用 SDR。兼容性支持 I2C Legacy Device可以在同一总线上混挂 I2C 和 I3C 设备。IBI 支持硬件支持带内中断但需要从设备也支持。DAA 支持支持动态地址分配。时钟源I3C 控制器的时钟来自 CRUClock Reset Unit具体是哪个 PLL 分频出来的后面 DTS 部分会讲。引脚I3C 的 SCL 和 SDA 引脚通常与 I2C 复用通过 pinctrl 配置切换功能。这里要特别提醒一句RK3576 的 I3C 和 I2C 是共用引脚的。也就是说一个物理引脚要么做 I2C要么做 I3C不能同时做。在 DTS 里配置的时候如果你把某个引脚组配成了 I3C 功能那对应的 I2C 控制器就不能再用了。这个在硬件设计阶段就要规划好不然后期改板很麻烦。3.2 I3C 控制器的寄存器概览虽然日常开发大部分时间是在改 DTS 和调驱动但了解一点寄存器层面的东西对定位问题很有帮助。RK3576 的 I3C 控制器寄存器大致分这几组控制寄存器CTRL使能控制器、配置速率、设置模式。状态寄存器STATUS总线状态、传输完成标志、错误标志。数据寄存器DATA读写 FIFO。地址寄存器ADDR设备地址配置。中断寄存器INT中断使能和状态。时序寄存器TIMINGSCL 高低电平计数、建立保持时间等。实际调试中最常看的是 STATUS 和 INT 寄存器。比如传输超时、ACK 错误、仲裁丢失这些都会在 STATUS 里体现。如果你用逻辑分析仪抓不到波形可以先读寄存器看看控制器到底卡在哪一步。3.3 与 RK3588 的 I3C 差异网上很多人拿 RK3576 和 RK3588 对比这里也顺带说一下。RK3588 的 I3C 控制器数量更多具体看型号而且部分型号支持更高的 HDR 速率。但在软件层面两者的驱动框架是同一套DTS 配置的写法也基本一致。所以如果你在 RK3588 上调过 I3C转到 RK3576 上基本可以无缝迁移主要差异在引脚定义和时钟树上。4. RK3576 I3C 的 DTS 配置实战4.1 找到 I3C 控制器的 DTS 节点在 RK3576 的 SDK 里I3C 控制器的定义通常在arch/arm64/boot/dts/rockchip/rk3576.dtsi这个文件中。你可以用 grep 搜一下grep -n i3c arch/arm64/boot/dts/rockchip/rk3576.dtsi会看到类似这样的节点i3c0: i3c2a000000 { compatible rockchip,rk3576-i3c; reg 0x0 0x2a000000 0x0 0x1000; interrupts GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH; clocks cru CLK_I3C0, cru PCLK_I3C0; clock-names i3c, pclk; pinctrl-names default; pinctrl-0 i3c0m0_pins; status disabled; };这个节点默认是disabled的你要在板级 DTS 里把它打开并配置引脚和时钟。4.2 配置 pinctrl 引脚I3C 的引脚配置在rk3576-pinctrl.dtsi里。以 i3c0 为例找到i3c0m0_pins这个节点i3c0m0_pins: i3c0m0-pins { rockchip,pins 1 RK_PB0 4 pcfg_pull_none, 1 RK_PB1 4 pcfg_pull_none; };这里的1 RK_PB0 4 ...表示 GPIO1 组的 PB0 引脚功能选择 4也就是 I3C 功能。pcfg_pull_none表示不上拉也不下拉。这里有个关键点I3C 在推挽模式下不需要外部上拉电阻但如果你总线上混挂了 I2C 设备那 I2C 设备需要上拉。所以实际硬件设计时通常还是会保留上拉电阻但阻值可以比纯 I2C 总线大一些比如 4.7k 到 10k减少对推挽驱动的影响。如果你用的引脚组跟默认的不一样比如你的板子把 I3C0 引到了别的引脚上那就需要自己写一个 pinctrl 节点然后在 i3c0 节点里引用它。具体引脚的功能编号要查 RK3576 的 datasheet 里的 IOMUX 表格这个不能猜猜错了波形出不来。4.3 配置时钟I3C 控制器的时钟来自 CRU。在rk3576.dtsi里i3c0 节点引用了CLK_I3C0和PCLK_I3C0。这两个时钟的父时钟和分频系数在rk3576-cru.dtsi里定义。一般情况下不需要改但如果你的 I3C 速率跑不上去可能需要检查一下时钟源是不是被分频得太低了。I3C 的 SCL 时钟是由控制器内部对输入时钟分频得到的。假设输入时钟是 200MHz你想跑 12.5MHz 的 SCL那分频系数就是 200/12.5 16。这个分频系数在驱动里会根据你配置的速率自动计算不需要手动改寄存器。但你要确保输入时钟足够高不然分频系数太小会导致占空比不准确。4.4 板级 DTS 里启用 I3C 并挂载设备假设你的板子上 I3C0 挂了一个 I3C 传感器地址是 0x6A那在板级 DTS 里可以这样写i3c0 { status okay; pinctrl-names default; pinctrl-0 i3c0m0_pins; clock-frequency 12500000; sensor6a { compatible vendor,sensor-model; reg 0x6a; i3c-scl-hz 12500000; i3c-sda-hz 12500000; }; };这里clock-frequency是总线速率reg是设备地址。注意 I3C 设备的reg属性在 DTS 里写的是动态地址分配前的临时地址实际通信时驱动会通过 DAA 重新分配。如果你的设备是 I2C Legacy Device那reg就是它的固定地址驱动会自动识别并用 I2C 模式通信。4.5 内核配置要使用 I3C内核里需要打开对应的配置选项CONFIG_I3Cy CONFIG_I3C_MASTERy CONFIG_I3C_MASTER_ROCKCHIPy如果你用的是 RK 的 SDK这些通常已经在rockchip_defconfig里打开了。但如果你是自己配的 defconfig记得检查一下。另外I3C 设备的驱动也要单独打开比如你用的是某个 I3C 温度传感器那对应的驱动选项也要开。5. 实操调试与问题排查5.1 用逻辑分析仪抓 I3C 波形调试 I3C 的第一步是抓波形。但这里有个坑很多逻辑分析仪的 I3C 解码功能是要额外付费的而且不同厂商的解码准确性差异很大。我试过几款最后发现还是用 I2C 解码器看 SDR 模式的前半段START、地址、ACK比较靠谱后面的推挽数据段用示波器看眼图更直观。抓波形的时候触发条件设成 SDA 下降沿START 条件采样率至少要是 SCL 频率的 10 倍以上。比如你跑 12.5MHz采样率至少要 125MS/s不然波形会糊成一团。我一开始用 100MS/s 的入门级分析仪12.5MHz 下根本看不清后来换了 500MS/s 的才勉强能用。5.2 常见问题速查表现象可能原因排查方法总线无波形控制器未使能、引脚配置错误、时钟未开检查 DTS status、pinctrl、clk_summary有 START 无 ACK设备地址错误、设备未供电、上拉缺失用 i2cdetect 扫描、量设备供电、检查上拉传输超时速率过高、总线电容过大、从设备响应慢降低 clock-frequency、缩短走线、查从设备手册数据错误采样点偏移、信号完整性差调时序寄存器、加匹配电阻、缩短走线IBI 不触发从设备不支持、IBI 未使能查从设备手册、检查控制器 IBI 配置混挂 I2C 设备时 I3C 设备异常模式切换冲突、地址冲突分开总线、检查 DAA 过程5.3 踩坑记录上拉电阻的取舍前面提到 I3C 推挽模式不需要上拉但实际板子上如果完全去掉上拉混挂的 I2C 设备就没法通信了。我一开始的做法是保留 4.7k 上拉结果发现 I3C 高速通信时波形上升沿有轻微过冲眼图裕量变小。后来把上拉改成 10k过冲明显改善I2C 设备也能正常工作。所以上拉电阻的阻值需要在 I2C 兼容性和 I3C 信号完整性之间折中10k 左右是个比较安全的起点具体还要看总线电容和走线长度。5.4 踩坑记录时钟频率配置错误导致通信失败有一次我在 DTS 里把clock-frequency写成了 12500000但实际输入时钟只有 24MHz分频下来 SCL 只有 12MHz 左右而且占空比严重偏离 50%。结果就是 I3C 设备能识别到地址但数据段总是出错。后来查clk_summary发现 I3C 控制器的父时钟被设成了 24MHz 的晶振而不是预期的 200MHz PLL。改时钟树配置后问题解决。教训是配置高速 I3C 之前一定要先确认控制器的输入时钟频率不然分频系数算出来是错的。5.5 踩坑记录I2C Legacy Device 的识别顺序RK3576 的 I3C 驱动在初始化时会先扫描 I2C 设备再扫描 I3C 设备。如果你的 I2C 设备地址跟某个 I3C 设备的临时地址冲突可能会导致识别异常。我遇到过一次一个 I2C EEPROM 的地址是 0x50而 I3C 传感器的临时地址也是 0x50结果驱动把 EEPROM 当成了 I3C 设备DAA 过程直接失败。解决办法是在 DTS 里给 I3C 设备指定一个不冲突的临时地址或者把 I2C 设备挂到另一条总线上。地址规划在混合总线场景下特别重要建议画个表格把所有设备的地址列出来避免冲突。6. 性能实测与选型建议6.1 实测数据对比我在 RK3576 EVB 上做了一个简单的吞吐量测试用 I2C 和 I3C 分别读写同一个传感器的 16 字节寄存器各测 1000 次取平均耗时。接口速率单次传输耗时有效吞吐量I2C Fast Mode400 kHz约 520 us约 246 kbpsI2C Fast Mode Plus1 MHz约 220 us约 582 kbpsI3C SDR12.5 MHz约 28 us约 4.57 Mbps从数据看I3C SDR 对比 I2C Fast Mode有效吞吐量提升了约 18 倍对比 Fast Mode Plus提升了约 7.8 倍。考虑到协议开销这个结果跟理论值基本吻合。所以标题里说“快 10 倍”在 Fast Mode Plus 场景下是成立的在 Fast Mode 场景下甚至更夸张。6.2 什么时候该用 I3C什么时候继续用 I2CI3C 虽好但不是所有场景都值得上。我的建议是优先用 I3C 的场景总线上设备多、需要动态地址分配对带宽要求高比如多轴 IMU、高分辨率触控、多摄同步引脚紧张想用 IBI 省掉中断线新项目从零开始设计没有历史包袱。继续用 I2C 的场景总线上全是老设备换 I3C 收益不大速率要求不高100kHz 或 400kHz 够用成本敏感I3C 设备的单价目前还是比 I2C 高一些团队对 I3C 不熟悉调试成本可能超过收益。混合使用的场景新老设备共存I3C 控制器兼容 I2C 设备可以平滑过渡。但要注意地址规划和模式切换开销。6.3 对硬件设计的影响如果你打算在 RK3576 项目里用 I3C硬件设计上要注意几点走线尽量短I3C 高速信号对走线长度敏感上拉电阻按前面说的折中取值如果混挂 I2C 设备I2C 设备的供电和上拉要单独考虑预留测试点方便抓波形。另外I3C 的 SCL 和 SDA 如果跟 I2C 复用那在 PCB 上要确保没有其他设备在 I3C 工作时干扰总线。7. 驱动层适配要点7.1 RK3576 I3C 驱动的结构RK3576 的 I3C 驱动在drivers/i3c/master/目录下核心文件是i3c-master-rockchip.c。驱动基于 Linux 的 I3C 子系统框架实现了i3c_master_controller_ops里定义的一系列回调包括bus_init、send_ccc_cmd、priv_xfers、i2c_xfers等。如果你要适配新的 I3C 设备大部分情况下不需要改驱动只要在 DTS 里正确配置然后确保设备驱动调用了 I3C 子系统的 API 就行。7.2 设备驱动如何调用 I3C API一个典型的 I3C 设备驱动在 probe 阶段会调用i3c_device_get_info获取设备信息然后用i3c_device_do_priv_xfers做私有传输或者用i3c_device_send_ccc_cmd发送通用命令。跟 I2C 驱动最大的区别是I3C 设备驱动需要处理 DAA 和 IBI。DAA 通常由主控制器驱动自动完成设备驱动不用管IBI 则需要设备驱动注册一个回调函数在从设备发起中断时被调用。7.3 调试驱动时的常用手段除了逻辑分析仪驱动调试还可以用debugfs。I3C 子系统在/sys/kernel/debug/i3c/下暴露了一些调试信息比如总线上的设备列表、每个设备的地址和状态。你可以用cat查看这些文件快速确认设备有没有被正确识别。另外dmesg里的 I3C 相关日志也很有用驱动在 DAA 失败、传输超时、IBI 异常时都会打印错误信息根据这些信息可以快速定位问题方向。8. 几个容易被忽略的细节8.1 I3C 的电源管理I3C 控制器在系统休眠时会被关闭唤醒后需要重新初始化总线。如果你的 I3C 设备在休眠期间需要保持状态那就要在驱动里实现suspend和resume回调在 resume 时重新做 DAA 和配置。RK3576 的 I3C 驱动已经实现了基本的电源管理但设备驱动也要配合不然唤醒后设备可能失联。8.2 I3C 与 I2C 的软件兼容层Linux 的 I3C 子系统提供了一个 I2C 兼容层让 I2C 设备驱动可以不加修改地挂在 I3C 控制器上。这个兼容层的工作原理是当 I2C 设备驱动调用i2c_transfer时I3C 控制器驱动会拦截这个调用把它转换成 I3C 的 I2C Legacy 传输。对设备驱动来说它感觉自己就是在跟一个普通的 I2C 控制器通信。这个机制大大降低了迁移成本但性能上会有一些额外开销因为每次传输都要做模式判断和切换。8.3 总线电容的限制I3C 虽然速率高但对总线电容更敏感。I2C 规范建议总线电容不超过 400pFI3C 在高速模式下建议不超过 50pF。这意味着 I3C 总线上能挂的设备数量更少走线也要更短。如果你的板子上 I3C 总线要走很长或者挂很多设备那可能需要在中间加缓冲器或者降低速率。这个在硬件设计阶段就要评估不然后期发现信号完整性有问题改板成本很高。8.4 逻辑分析仪的 I3C 解码准确性前面提过逻辑分析仪的 I3C 解码问题这里再展开说一下。I3C 的协议比 I2C 复杂得多尤其是 DAA 和 IBI 阶段波形跟普通数据传输完全不一样。很多逻辑分析仪的 I3C 解码器在这些阶段会解错或者直接卡住。我的经验是不要完全依赖解码器的结果要结合示波器看实际波形再对照 I3C 规范里的时序图手动分析关键阶段。虽然麻烦一点但准确性高得多。9. 从 I2C 迁移到 I3C 的实操路线如果你手头有一个基于 RK3576 的项目原来用 I2C现在想迁移到 I3C可以按这个路线走第一步评估硬件。确认你的板子上 I3C 引脚有没有引出上拉电阻是否合适总线电容是否在允许范围内。如果硬件不支持那软件再怎么调也没用。第二步改 DTS。把原来的 I2C 节点禁用启用 I3C 节点配置 pinctrl 和时钟。如果总线上有 I2C 设备保留它们的节点I3C 控制器会自动兼容。第三步验证总线。用逻辑分析仪抓波形确认 START、地址、ACK 这些基本元素正常。如果设备能被识别到说明总线通了。第四步调设备驱动。如果设备是 I3C 设备确保驱动调用了 I3C API如果是 I2C 设备驱动不用改但要注意性能可能没有提升。第五步做压力测试。连续读写、并发访问、休眠唤醒这些场景都要测一遍确保稳定性。第六步优化性能。根据实测结果调整速率、上拉、时序参数找到稳定性和性能的平衡点。这个路线看起来简单但每一步都有坑。我的建议是不要一次性全改先在一个设备上验证跑通了再推广到整条总线。这样出问题的时候排查范围小容易定位。10. 一些个人经验体会调 I3C 这段时间最大的感受是它比 I2C 复杂但复杂得有道理。I2C 简单到几乎不需要驱动但代价是速率上不去、地址冲突、中断线占用。I3C 把这些痛点都解决了但引入的 DAA、IBI、HDR 这些机制确实需要花时间理解。我一开始也觉得 DAA 很麻烦为什么不直接用固定地址后来在一条总线上挂了 8 个同型号传感器地址冲突到没法用才体会到 DAA 的价值。另一个体会是工具很重要。没有好的逻辑分析仪和示波器调 I3C 基本是盲人摸象。我建议至少准备一台 500MS/s 以上的逻辑分析仪带宽 200MHz 以上的示波器不然高速信号根本看不清。这笔投入对于做 I3C 开发的团队来说是值得的。最后说一个细节RK3576 的 I3C 驱动在 SDK 里更新比较频繁不同版本的 SDK 里 DTS 的写法和驱动的行为可能有差异。如果你遇到奇怪的问题先确认一下 SDK 版本然后去瑞芯微的开发者社区搜一下有没有相关的补丁或说明。很多时候你踩的坑别人已经踩过了只是信息比较分散需要花时间找。