★ FEATURED ARTICLE I3C 比 I2C 快 10 倍这个说法我一开始是不太信的。做嵌入式这么多年类似XX 比 XX 快 N 倍的标题见过太多很多都是拿理论峰值和实际体验做对比水分不小。直到我真把一块 RK3576 的板子跑起来在设备树里把 I3C 节点配好用逻辑分析仪抓完波形才算彻底搞明白数字本身站得住脚但快 10 倍背后的前提条件、接口特性的取舍、以及把老 I2C 设备挂到 I3C 总线上会踩的坑比单纯的倍率数字要复杂得多。这篇文章主要聊三件事I3C 比 I2C 快在哪里、为什么快RK3576 上做 I3C 的 DTS 配置时真正要动哪些地方以及实际调试中我遇到的兼容性问题和排查思路。读者对象是正在做 RK3576 板级 bring-up 的驱动工程师、准备从 I2C 迁移到 I3C 的嵌入式开发以及想评估要不要在新项目里用 I3C 的硬件工程师。1. 快 10 倍的账是怎么算的I2C 的历史包袱与 I3C 的协议改法1.1 I2C 的三座大山固定地址、中断靠 GPIO、速率天花板要理解 I3C 的价值得先看 I2C 到底憋了多少年的老问题。I2C 从 1982 年诞生到现在一直是板级低速总线的事实标准但它的很多设计还停留在当年挂几个 EEPROM、读个时钟芯片的年代。第一座大山是固定地址。I2C 用 7 位设备地址地址由器件引脚硬接线或芯片内部固定同一型号芯片的地址是写死的。遇到两个同型号传感器要挂同一条总线就只能改芯片的 ADDR 引脚电平或者干脆再开一条 I2C 控制器。设计阶段少拉一根地址线调试阶段就可能多花一整天。我去翻i2c数据帧格式相关的资料时经常看到一张经典时序图START 条件、7 位地址、R/W 位、ACK 位然后才是数据字节和 STOP。这套格式本身没毛病但地址空间小、地址静态分配是整个总线扩展性差的核心根源。第二座大山是中断。I2C 协议里没有带内中断这个概念从机想主动通知主机我有数据了只能把 INT 引脚单独接一根线到主控 GPIO。一个设备一根中断线挂五个传感器就是五根线到了 MCU 引脚资源紧张的时候这比地址冲突还要命。很多做 ESP32 的低功耗项目为什么有人搜esp32 休眠 i2c复位就是因为中断唤醒 总线复位的组合拳打不好睡眠唤醒后 I2C 总线上残留状态把整条总线卡死。第三座大山是速率。I2C 标准模式 100kbit/s快速模式 400kbit/s快速模式 到 1Mbit/s高速模式 3.4Mbit/s 是写进规范的但实际用的人很少。原因很简单I2C 是开漏结构靠上拉电阻把电平拉高SCL 上到 3.4MHz 之后信号边沿完全受总线电容和上拉电阻限制线上稍微多挂两个器件、PCB 走线稍微长一点波形就没法看。我见过不少项目标称 1MHz结果实测只有 300k 能稳定工作就是这个原因。三座大山叠加I2C 的设计者们自己也清楚所以 MIPI 联盟在 2016 年前后推出了 I3C 规范目标很明确向下兼容 I2C同时把地址、中断、速率这些问题从协议层面一次性解决。1.2 I3C 核心改进动态地址、带内中断、热加入、CCC先说动态地址分配DAA。I3C 从机不需要固定 7 位地址总线初始化时主机会发起 ENTDAA 流程逐个给总线上的 I3C 设备分配动态地址。这意味着什么同一型号、同样硬件配置的传感器挂多少颗都行不用担心地址冲突也不用在 PCB 上拉地址选引脚。设备树里你写的是期望地址实际运行地址由 master 在启动时协商分配这种运行时才算的机制对量产一致性的帮助非常大。然后是带内中断IBIIn-Band Interrupt。I3C 从机可以直接在总线上发起中断请求不再需要单独拉一根 INT 线到主控 GPIO。这对板级设计是实打实的利好同样的功能I2C 方案要预留 5 个 GPIO 接中断I3C 方案一根线上全搞定中断还能携带设备地址信息主机不需要遍历设备就能知道是谁在喊。热加入Hot-Join解决的是系统运行中设备接入的问题。模块化设计里某个传感器模组可能要热插拔I2C 想做到这一点很难地址和电源管理都绕不开。I3C 的热加入机制允许新设备上电后主动请求加入总线主机再分配动态地址整个流程被协议规范完整定义。最后是 CCC 命令Common Command Code主机可以用广播或组播的方式一次性地给所有总线设备下发配置命令比如查询设备能力、设置总线参数、触发设备复位再也不需要一个一个地址挨个写寄存器。不要小看这些协议层面的改动。动态地址解决的不只是地址冲突它让总线上的设备是谁这件事从硬件设计阶段挪到了系统运行时这才是 I3C 真正革新的地方。1.3 账目还原什么时候快 10 倍成立把速率账算清楚。I3C 的 SDRSingle Data Rate模式时钟最高 12.5MHz一次传 1 bit理论吞吐 12.5Mbit/s。HDRHigh Data Rate模式通过双沿采样或三态编码还能再翻倍但实际项目里绝大多数 I3C 从机设备只实现了 SDRHDR 需要主从两端同时支持没有普及开。所以对标的时候拿 SDR 12.5MHz 说事是最务实的口径。模式峰值速率相对 400k 的倍率I2C Standard100 kbit/s0.25xI2C Fast400 kbit/s1xI2C Fast1 Mbit/s2.5xI2C HS3.4 Mbit/s8.5xI3C SDR12.5 Mbit/s31xI3C HDR25 Mbit/s 起62x结论很清楚如果你之前用的是 I2C 快速模式 400kI3C SDR 是它的 31 倍不止 10 倍如果之前用的是 Fast 1MHz快 10 倍这个说法正好成立12.5 倍。要是拿 100k 这种老掉牙的慢速配置来比那差距就更夸张了。但要注意I3C 访问总线上挂载的 legacy I2C 设备时仍然要走 I2C 兼容时序该 400k 还是 400k不要指望接口协议升级能把老设备也提提速。所以我的看法是快 10 倍当宣传口号没问题但更值钱的改进其实是动态地址和带内中断。速率提升解决的是大数据量读取耗时的问题动态地址和 IBI 解决的却是板级设计和系统复杂度的问题后者在项目里往往更致命。2. RK3576 的 I3C 硬件资源控制器、时钟与引脚复用2.1 RK3576 平台定位与 I3C 控制器概况RK3576 是瑞芯微新一代中高端 SoC8 核架构4 个 A72 4 个 A53带 NPU主要面向 AIoT 盒子、平板、边缘计算这类场景。对我来说这块芯片真正让人眼前一亮的是它的外设补齐工作原生 I3C 控制器就是其中之一。在老的 RK3568、RK3399 上想用 I3C 基本不可能只能外挂桥接芯片或者干脆用 FPGA 去拼协议成本高、功耗大、驱动还难写。到了 RK3576 这一代MIPI I3C 被做进片内配套的 Linux 驱动栈也成熟了这才是 I3C 能真正落地的前提。控制器用的是 DesignWare 的 dw-i3c-master IP这在 Linux 内核里有现成驱动drivers/i3c/master/dw-i3c-master.c主线支持比较完整。RK3576 的 BSP 内核通常会把 compatible 写成 rockchip,rk3576-i3c, snps,dw-i3c-master前者是瑞芯微的定制化入口后者兼容通用 DesignWare 驱动。RK3576 一般引出两组 I3C 控制器标签是 i3c0 和 i3c1具体数量、寄存器基地址、中断号以 TRM 和官方 dtsi 为准。我建议拿到板子第一件事就是去翻 arch/arm64/boot/dts/rockchip/rk3576.dtsi里面 SoC 层已经把节点骨架写好了你只需要在板级 dts 里打开对应节点、配好引脚、挂子设备。2.2 时钟与控制器模式SDR 为主别一开始就追 HDR时钟配置是 I3C 调试里最容易翻车的一环。dw-i3c-master 通常需要两条时钟一条是控制器寄存器访问时钟设备树里叫 apb_pclk 或 pclk另一条是总线时序基准时钟叫 tbi_pclkI3C 的 SCL 频率就是从这条时钟分频得到的。I3C 的 bit rate 本质上是 tbi_pclk 分频算出来的tbi_pclk 没配好、频率不够你就算在 DTS 里写了 12.5MHz实际跑出来的波形也是乱的。设备树里 clock-names 常见写法是 tbi_pclk、apb_pclk对应 clocks 属性里填两个时钟的 phandle。这里没有捷径直接对着 rk3576.dtsi 里 i3c0 节点的注释看就行。另外一个常见的思路误区是上了 I3C 就一定要跑 HDR。现实不是这样。目前市场上大量 I3C 传感器尤其是做加速度计、磁力计、环境传感器的厂商很多只实现了 SDR 模式加 legacy I2C 兼容。HDR 需要主从双方都支持设备不支持时主机在 DAA 阶段会根据设备能力寄存器DCR、BCR判断握手时发现不支持 HDR 就会回退到 SDR。所以一旦你配好了总线发现只能跑 SDR 12.5MHz不要觉得是配置出了问题大概率是从机硬件就不支持。我建议的策略是先把 SDR 12.5MHz 稳定跑通把 DAA、IBI、动态地址这些都验证完再考虑要不要为某个特定设备上 HDR。一口吃不成胖子I3C 也不例外。2.3 查数据手册时的三个关键信息做 DTS 配置前必须先确认三组信息不然配出来的节点就是空中楼阁。寄存器基地址reg 属性。I3C 控制器的 base 地址、映射长度直接从 rk3576.dtsi 抄。中断号interrupts 属性。包括中断控制器类型GIC_SPI、中断号和触发方式LEVEL_HIGH 还是 EDGE。写错中断号最常见的结果是设备 probe 报 -EINVAL 或 -EBUSY。时钟 IDclocks 属性。clk 的 ID 定义在 include/dt-bindings/clock/rk3576-cru.h 头文件里不在设备树源文件里需要 grep 确认。这三个信息在官方 dtsi 里都有现成的不要凭记忆抄。我之前吃过一次亏按 RK3568 的记忆填 RK3576 的 i2c 中断号结果设备就是不 probe排查了半天才发现是中断号对不上。所以 DTS 配置的第一原则是能 grep 得到的值不要手写能抄 SoC 厂商 dtsi 的节点不要自己发明。3. DTS 配置实战节点怎么写、I2C 子设备怎么挂3.1 最小 I3C 主节点模板直接给一个我调 RK3576 时用的最小模板代码结构基于 dw-i3c-master 的通用模型具体寄存器地址、中断号以你手里的 rk3576.dtsi 为准不要照抄数值。i3c0 { status okay; /* 总线 SDR 频率RK3576 BSP 内核常见扩展属性 */ clock-frequency 12500000; /* legacy I2C 从机0.9 寸 SSD1306 OLED */ ssd13063c { compatible solomon,ssd1306-i2c; reg 0x3c; status okay; }; /* I3C 从机reg 第一个 cell 是静态地址(没有就填 0x0) 第二个 cell 是期望的动态地址 */ sensor68 { compatible vendor,some-i3c-sensor; reg 0x68 0x4A; }; };pinctrl 部分也不能少。很多情况下 i3c0 的引脚和 i2c0 是同一组引脚复用SoC 层已经把 pinctrl-0 定义好了但板级设计里如果引脚被改成别的功能就需要显式指定i3c0 { pinctrl-names default; pinctrl-0 i3c0_xfer; status okay; };引脚配置不对时现象很典型总线波形有但设备不 ACK或者另一个功能模块在 /sys/kernel/debug/pinctrl/ 里显示 pinmux 被占用。排查思路就是查 pinctrl 的分配情况不是查 I3C 控制器本身。3.2 动态地址与静态地址I3C 设备初始化的实际流程理解 I3C 总线上两类设备初始化流程的区别是配置 DTS 的核心。总线初始化时I3C master 会发起 DAA向总线上所有支持 I3C 的设备发送 ENTDAA 命令收集设备响应然后逐个分配动态地址。legacy I2C 设备不参与 DAA它们没有动态地址机制因此必须在 DTS 里静态声明地址。master 在分配动态地址时会跳过已被 legacy I2C 设备使用的地址段避免冲突。这里有一个很容易踩的坑如果你把一个纯 I2C 设备比如 SSD1306错误地声明成了 I3C 设备master 在 DAA 阶段会尝试用 I3C 帧格式去跟它握手这个老设备完全不认识 ENTDAA可能直接不响应也可能把总线状态搞乱。反过来如果你把一个 I3C 设备当 legacy I2C 设备声明master 就不会给它分配动态地址设备自身的 I3C 特性IBI、热加入全部无法使用等于花 I3C 的钱买了个 I2C 的体验。设备树里 I3C 设备的 reg 属性通常有两个 cell第一个是静态地址第二个是期望的动态地址。没有静态地址的纯 I3C 设备第一个 cell 填 0。还有一个要牢记的实际分配的动态地址是 master 运行时协商的结果可能跟你期望值不一样驱动里不要硬编码动态地址要用内核 I3C 子系统提供的接口去获取当前地址。3.3 会翻车的三个细节频率、上拉、资源冲突第一个细节是 clock-frequency 到底写多少。如果总线上只有 I3C 设备写 12500000 没问题。但混挂了 I2C legacy 设备时我建议先把频率降到 5MHz 甚至 1MHz 启动用逻辑分析仪确认波形稳定之后再慢慢往上拉。为什么老 I2C 从机的输入时序参数是按 I2C 标准设计的I3C SDR 的推挽边沿比 I2C 开漏边沿快得多某些老设备的输入缓冲在过快的边沿下可能出现误采样表现为间歇性 ACK 失败。降到 1MHz 先跑通再提频能快速区分是时序问题还是设备本身的问题。第二个细节是上拉电阻。很多人把 I2C 的上拉电阻值直接搬到 I3C 总线这是一个高发错误。I2C 总线是开漏结构SCL/SDA 的电平全靠上拉电阻拉高4.7k 上拉在 400k 下很常见但 I3C 的 SCL 是推挽驱动的SDA 在写数据时也是推挽模式只有读数据时才是开漏释放。如果你沿用 4.7k在 12.5MHz 下推挽驱动倒不至于拉不动但开漏读周期的上升沿会非常慢直接影响建立时间严重时从机 ACK 读不回来。比较好的做法是按 I3C 规范重新计算上拉电阻通常比 I2C 小具体值根据总线电容和走线长度标定。我的经验是混挂老设备时上拉电阻取折中值把 I3C 最高频率适当降下来比盲目追高更稳。第三个细节是资源冲突。同一个控制器同一组引脚不可能同时跑 I2C 和 I3C。如果板级 dts 里同时打开了 i2c0 和 i3c0 的同一个引脚复用组后加载的驱动会报 pin busy前一个功能却正常。常见做法是在板级 dts 中显式把不用的那个总线节点 status 改成 disabled。还有中断资源I3C 设备的中断脚如果跟其他设备共用且双方都配了同一路 GPIO 中断request_threaded_irq 会直接返回 -EBUSY。这种问题不看 dmesg 根本想不到排查时记得加一句 grep irq /proc/interrupts。4. 兼容性陷阱老 OLED、HID 中断与总线复位4.1 SSD1306 这类纯 I2C 从机挂 I3C 总线的兼容性坑热词里有人搜0.9 寸 OLED 对 i2c 兼容问题我猜是 SSD1306 这类显示屏挂在某些总线上不稳定。SSD1306 是一个标准的 legacy I2C 从机它只认识 I2C 帧格式对 I3C 的 ENTDAA、CCC 这类命令一无所知。当 I3C master 做总线初始化时会向所有设备广播 CCC 命令总线上的 SSD1306 也会看到这个帧头如果它没有正确进入被保护的静态地址列表就可能被 I3C 帧的内容干扰从机状态机直接跑飞。表现就是有时上电正常显示有时完全黑屏复位一次又好了。正确的处理方式就是在 DTS 里把它声明为 legacy I2C 设备reg 只写 7 位地址。内核 I3C 子系统在设计上考虑了这种混挂场景master 驱动在 DAA 时会把 legacy 设备的地址加到保护列表不拿 I3C 帧去碰它。但要注意这里要求你的内核版本不要太老。老 BSP 内核的 I3C 驱动栈可能没有完整实现 legacy I2C 设备保护逻辑混挂老设备就会出现各种奇怪问题。我建议先查一下你用的内核里 drivers/i3c/master/dw-i3c-master.c 的版本最好用 5.15 以上或 RK3576 对应的新 BSP 内核。还有一个硬件层面的问题SSD1306 这类器件的上电时序。如果 OLED 和主控不是同一电源域master 初始化 I3C 总线时 OLED 可能还没上电此时它的 SDA 引脚处于高阻或下拉状态会把总线电平拉死导致所有设备 DAA 失败。排查时先看 SDA 是否一直为低如果是给 OLED 供电加一个 GPIO 使能等电源稳定后再初始化总线问题立刻消失。4.2 I2C HID 设备 代码 12 背后的中断资源问题热词里有条i2c hid该设备找不到足够资源可以使用。 (代码 12)。这个错误在 Windows 设备管理器里很常见根因是 BIOS/ACPI 没有给 I2C HID 设备分配可用的中断资源或者中断线与其他设备共享后资源耗尽。放在 RK3576 的 Linux 场景下等价的问题就是 DTS 里触控/触摸板节点的中断资源配置不正确。我在 RK3576 上调试 I2C HID 触摸屏时遇到过类似的坑。现象是设备 probe 失败dmesg 里报 i2c-hid 无法注册中断。排查链路是这样的先看 dmesg 有没有 request_threaded_irq 失败然后 cat /proc/interrupts 看这个中断号有没有被别的设备占用再查 /sys/kernel/debug/gpio 确认 GPIO 是否成功申请为中断输入最后用示波器抓 INT 引脚看从机有没有真的把中断拉低。整个过程下来最常见的原因是 interrupt-parent 写错或者中断号和板子上另一个按键设备冲突。代码 12 的本质是资源不够用Linux 下对应的就是中断资源被抢、pinctrl 被复用、时钟没打开这三种情况排查思路完全一致。给个实用建议如果板子上有多个设备都要用 GPIO 中断尽量在硬件设计阶段错开 GPIO别共用。软件上虽然能用共享中断但 I2C HID 这类设备对中断响应时间有要求共享后容易引发中断风暴得不偿失。4.3 休眠与复位场景I3C 相对 I2C 的优势esp32 休眠 i2c复位这个热词我很熟悉。嵌入式低功耗项目里的经典噩梦系统睡了一觉醒来之后 I2C 总线卡死了SDA 一直被拉低主机怎么发 START 都发不出去。原因是 I2C 没有总线级的复位机制某个从机在掉电或复位过程中把 SDA 拉住了主机只能对 SCL 打 9 个脉冲尝试恢复或者干脆软复位整个控制器搞不定就得断电重启。I3C 在协议层面解决了一部分这类问题。动态地址分配机制让主机在每次总线初始化时都能重新枚举所有 I3C 设备设备掉电重挂后不需要驱动层去猜地址CCC 命令里也定义了总线管理相关的命令主机可以主动把从机恢复到一致状态。但要注意一个大前提这些好处只对真正的 I3C 设备有效。总线上如果挂了一批 legacy I2C 设备它们对 CCC 没有任何响应低功耗唤醒后的总线恢复依然是个麻烦事。我的习惯是无论在 I2C 还是 I3C 上设备驱动 resume 之后先对控制器做一次 master reset再重新枚举总线。这套流程在 I3C 上更加流畅因为 master reset 之后 DAA 会自动重新分配动态地址不需要驱动层做任何额外操作。如果你的项目对唤醒时间有严苛要求I3C 在这方面的优势就会直接体现在时序数据上。4.4 逻辑分析仪与 I3C 解码调试工具的真实体验调试 I3C 的第一个门槛是工具。逻辑分析仪对 I2C 解码非常成熟市面上几十块的逻辑分析仪配合软件就能把 I2C 帧解析得明明白白网上那些i2c时序图i2c逻辑分析仪的教程一抓一大把。但到了 I3C情况就尴尬了。很多逻辑分析仪的协议解码器对 I3C 的支持停留在 SDR 帧级别DAA、CCC、IBI 这些 I3C 特有的过程基本是白板抓下来一片解析失败的帧头。我的调试经验有三条。第一上电后第一件事是完整抓一遍总线枚举过程把 DAA 那一段单独放大看确认动态地址分配是否按预期进行。第二调试 legacy I2C 设备时直接在逻辑分析仪里选 I2C 协议解码因为 master 访问老设备时走的就是兼容帧格式选 I3C 反而解不出来。第三采样率要够。12.5MHz 的总线时钟至少要用 100Msps 采样率的设备24MHz 采样率的入门逻辑分析仪抓 I3C 会漏掉关键边沿看着波形像一堆乱码。如果能借到带协议解码的示波器调试体验会好很多但价格不是所有人都能接受。5. 我的选型建议什么场景 I3C 真正值回票价5.1 适合换到 I3C 的场景第一个是传感器多、数据量大的场景。比如 9 轴 IMU 加多颗加速度计FIFO 深度动辄几十 KB用 I2C 1MHz 读一次要占主控 CPU 很长时间在 RTOS 或 Linux 上都会推高 CPU 占用率。换成 I3C SDR 12.5MHz读取时间直接缩短一个数量级CPU 占用率大幅下降省下来的算力可以做更多事情。这是 I3C 最直接的价值。第二个是中断线不够用的场景。I3C 的带内中断省掉每一颗传感器的独立 INT 引脚板级设计不用再为 GPIO 资源发愁驱动开发也不用给每个中断单独写一套 handler 来区分设备。我见过一个 6 颗传感器的板子从 I2C 换到 I3C 之后直接省了 5 根信号线PCB 布线难度下降一个等级。第三个是模块化设计、设备可能要热插拔的场景。I3C 的热加入机制比 I2C 的固定地址优雅太多。新模组插上去总线自动枚举、自动分配地址、自动注册设备整个流程是协议标准的一部分不需要在驱动层做特殊的检测到新设备处理。5.2 不建议追 I3C 的场景如果板上几乎全是老 I2C 外设比如 SSD1306、PCF8563 时钟芯片、ADS1115 ADC 这类I3C 对它们的收益约等于零。这些设备本身跑不了高速也用不上 IBI 和动态地址混挂在 I3C 总线上反而要处理兼容性问题。我见过有人在 I3C 总线上挂了四颗老 I2C 传感器结果 DAA 阶段的兼容问题调了一个礼拜最后不得不单独加一条 I2C 总线把老设备摘出去——早知如此何必当初。成本敏感的项目也要谨慎。支持 I3C 的传感器普遍比同类 I2C 器件贵即使规格相近I3C 版本的价格也可能高出一截。如果产品对总线速率和中断数量没有硬性需求纯 I2C 方案成本更低、供应链更成熟。工具链不熟的团队我不建议在工期紧张的新项目里强行上 I3C。逻辑分析仪解码支持、内核驱动版本、BSP 完善程度都是现实约束。先在一款小项目上把 I3C 的 DAA、IBI、混挂调通再逐步推广到大项目比一上来就全线上 I3C 稳妥得多。我的原则很简单新项目、新器件优先选 I3C老外设单独留一条 I2C 总线别混在高速 I3C 上。这样既享受了 I3C 的红利又把兼容性风险隔离在固定范围内。5.3 给正在做板级设计的你几点经验硬件设计阶段就把哪些器件走 I3C、哪些走 I2C 分开这件事定下来不要等画完原理图、开始写 DTS 了再纠结。引脚复用、上拉电阻、电源域这些都是硬件设计时就要敲定的东西DTS 只是把它们表达出来改变不了物理连接。上拉电阻按 I3C 规范重新算别直接抄 I2C 的 4.7k。给一个大概的方向I3C 总线混挂设备不多时1k 到 2k 的范围比较常见具体值按总线上设备的数量和走线长度做调整最好用示波器实测边沿斜率来决定。12.5MHz 下如果上升沿超过 10ns就要考虑减小上拉电阻或缩短走线。RK3576 的 I3C 引脚与 I2C、SPI、GPIO 的复用关系表画原理图之前必须对着 TRM 过一遍。别光看 I3C 控制器本身还要看你选的那组引脚在同一个封装里有没有和其他外设打架。软件上先跑一个 I3C 设备的 demo确认 DAA 正常、动态地址分配正确、IBI 能收到再扩展其他设备。一次挂太多设备出了问题时你根本分不清是哪个环节的锅。我调试 RK3576 的 I3C 时习惯先用一颗最成熟的 I3C 传感器单独验证跑通再加第二颗、第三颗最后再加 legacy I2C 设备。最后分享一个小技巧DTS 里临时把 clock-frequency 写小到 1MHz用来做信号完整性和设备兼容性的交叉验证。如果 1MHz 下一切正常拉到 12.5MHz 就出问题那基本可以断定是板级信号完整性问题如果 1MHz 下就有设备不正常那是设备枚举或兼容性问题跟速率无关。这个二分法排查手段我一直在用效率很高帮你少走很多弯路。
阅读完成 · 觉得有帮助？
