I3C数据传输：SDR模式与HDR模式的实战抉择
这一章我们聊聊I3C怎么传数据。说白了，就是两种模式——SDR和HDR。你可能会问，为什么需要两种？一种不够用吗？嗯，我刚开始接触I3C时也有这个疑问。
在我参与的某个项目中，传感器需要同时兼容低速配置和高速突发传输。SDR负责控制指令，HDR负责批量数据。这个分工，其实很典型。
核心观点： SDR是I3C的基础通信模式，所有设备都必须支持。HDR是高性能扩展模式，用于大数据量传输。
SDR模式：稳字当头
SDR全称Single Data Rate，单倍数据速率。每个时钟周期只传输1位数据。听起来不快，但好处是——简单、可靠、兼容性好。
我在调试一块老款I3C传感器时，就发现它在SDR模式下跑得稳稳当当。换成HDR就不行。后来查了规格书...嗯，这芯片只支持SDR。
SDR模式的特点很清晰：
- 时序简单： 数据在SCL的上升沿采样，下降沿切换。你不需要考虑复杂的位对齐。
- 所有设备都支持： I3C规范强制要求每个从设备必须实现SDR。
- 适合配置和状态读取： 传寄存器值、控制命令，SDR足够了。
个人习惯： 我通常用SDR做初始化握手和错误恢复。因为即便总线出问题，SDR的容错机制也最简单。
HDR模式：性能炸裂
HDR是High Data Rate的缩写，翻译过来就是高数据速率。说白了，就是给那些需要大量吞吐的场景准备的——比如图像传感器、音频流、陀螺仪批量数据。
HDR模式不是一种，而是四种：
| 子模式 | 速率倍数（相对SDR） | 典型场景 |
|---|---|---|
| HDR-DDR | 2x | 低延迟双倍速率传输 |
| HDR-TSP | 3x | 三线制高吞吐 |
| HDR-TSL | 3x | 三线制低功耗 |
| HDR-BT | 可配置 | 突发传输、可变速率 |
你想想看，SDR只能传1位/周期，HDR-DDR能传2位。HDR-TSP甚至能利用三根数据线传3位。速度差距不是一点半点。
我曾经踩过一个坑： 在HDR-DDR模式下没有正确配置数据采样沿，导致高字节和低字节错位。整包数据都废了。后来加了位校验才锁定问题。
模式切换流程：不是你想切就能切
从SDR切换到HDR，不是简单的写个寄存器就完事。I3C有一套严格的握手协议：
- 广播ENTHDRx： 主设备发送ENTHDRx CCC（公共命令码），告诉所有从设备要切模式了。
- 响应与确认： 支持该HDR模式的从设备在指定时隙响应ACK。
- 切换时序： 总线进入HDR预置时序，SCL和SDA调整速率。
- 数据开始： 主设备发送HDR下的第一个数据包。
我建议你写驱动时，每一步都要加超时判断。因为有一次我在项目中就碰上从设备不支持HDR-DDR，但不发NACK，直接死等...那叫一个崩溃。
实战对比：选SDR还是HDR
还是那句话——看场景。我给你列个对比表，很直观：
| 对比维度 | SDR模式 | HDR模式 |
|---|---|---|
| 兼容性 | 所有设备必选 | 可选，老设备可能不支持 |
| 传输速率 | 低（12.5MHz典型） | 高（可达几十MHz等效） |
| 功耗 | 低，控制简单 | 较高，需要更多逻辑 |
| 错误率 | 低，时序宽松 | 较高，对信号完整性敏感 |
| 应用场景 | 配置、状态、小数据量 | 图像、音频、批量采样 |
说到这，我得提一句：在实际产品中，很多系统会同时使用两种模式。初始化用SDR，传输数据用HDR。这也是I3C的灵活之处。
你看这个流程图就很清楚。从SDR出发，发送ENTHDRx，等ACK，成功了就直接切HDR。失败了？别慌，老老实实回SDR。
我记得有一次在量产测试中，某个批次的芯片HDR-DDR老切换不成功。分析后发现是PCB走线过长导致信号完整性问题。换成SDR跑低速率测试就全过了。这就是为什么SDR一直作为保底模式存在。
代码实战：模拟SDR/HDR数据包
光看理论不够，我们来写点代码。下面这个Python示例模拟了SDR和HDR-DDR的位采样过程：
def simulate_i3c_transfer(data_bits, mode='SDR'):
"""
模拟I3C数据传输
:param data_bits: 待传输的数据位列表，如[1,0,1,1,0,0,1,0]
:param mode: 'SDR' 或 'HDR-DDR'
:return: 解码后的位序列
"""
scl_cycles = len(data_bits) if mode == 'SDR' else len(data_bits) // 2
decoded_bits = []
for cycle in range(scl_cycles):
if mode == 'SDR':
# SDR: 每个时钟沿采样1位
bit = data_bits[cycle]
decoded_bits.append(bit)
print(f"Cycle {cycle}: SCL上升沿采样， bit = {bit}")
elif mode == 'HDR-DDR':
# HDR-DDR: 每个时钟采样2位（上升沿+下降沿）
pos_edge_bit = data_bits[cycle * 2]
neg_edge_bit = data_bits[cycle * 2 + 1]
decoded_bits.extend([pos_edge_bit, neg_edge_bit])
print(f"Cycle {cycle}: POS={pos_edge_bit}, NEG={neg_edge_bit}")
return decoded_bits
# 演示
sdr_data = [1,0,1,0,1,1,0,0]
hdr_data = [1,0,0,1,1,0,1,1,0,0,1,0]
print("=== SDR模式 ===")
result_sdr = simulate_i3c_transfer(sdr_data, mode='SDR')
print(f"解码结果: {result_sdr}")
print("\n=== HDR-DDR模式 ===")
result_hdr = simulate_i3c_transfer(hdr_data, mode='HDR-DDR')
print(f"解码结果: {result_hdr}")
这个代码我故意写得很简单。重点在于对比两种模式下时钟和数据位的关系。你跑一下就能看到：同样的时钟周期数，HDR能传两倍的数据。
一个小技巧： 实际开发中，可以用这个模拟器来验证时序纠错逻辑。我经常先模拟，再上硬件调试，效率高很多。
避坑指南
- 别混用数据线： 在HDR-TSP模式下，三根数据线不能随意交换。我曾经因PCB布局时交换了D1和D2，导致解码全乱。
- 注意HDR退出时序： HDR结束后必须发EXIT模式命令。否则总线可能卡在高速状态，后续设备无法访问。
- SDR是救命的： 任何HDR异常后，你都应该能回到SDR做错误诊断。我习惯在驱动中保留一个SDR-only的回退路径。