再介绍一下我们正在尝试做的测试：
我们的客户有一个 I3C master call SCOUT 和他们制作的 I3C slave。
他们希望用 RT685 替换 SCOUT。
我们用来评估替换的测试是读取 I3C 从设备的 ID 数据。
我们使用scope捕获SCOUT读取ID数据的行为后，可以得到三个命令行，解码如下：
命令 1。[Start+0x7E+Write+Ack, Sr+0x18+Write+Ack, 0xCE, 0xFA, 0x01, ...机密数据]
命令 2。 [Start+0x7E+Write+Ack, Sr+0x18+Read+Ack, 0xCE, 0xFA, 0x02, ...机密数据]
命令 3。[Start+0x7E+Write+Ack, Sr+0x18+Read+Ack, 4字节ID数据]
在上面的命令中，
command1 和 2的第 5 个字节 表示消息的类型。（例如 0x01 是“命令”；0x02 是“响应”）
下面是来自 SCOUT（原始 I3C Master）的
command2 的波形：
根据你之前Private RnW transfer的建议，我们需要将0x7E和0x31分开，让0x31作为slave地址。
所以 0x31 将被编码为“0x18+读取位”。
但是，根据波形，
Master 仍在向 command2 中的 Slave 传输数据。
（因为你可以看到0x18的第8位是High，代表“Read”。而且Header“0xCE,0xFA”仍然存在）
那么，我们的新问题是，
当 I3C 方向设置为“读取”时，RT685 是否能够将数据“写入”到 Slave？
