我们使用 Raspberry PI4作为 UCD9081的 Linux Master 运行 i2c 每100毫秒读取一次。
由于 UCD9081使用了链路上的 SCL，我们将主中继器配置为使用软件 i2c，而不使用其所拥有的 i2c 硬件，因为它不支持链路上的链。
但是，我们偶尔会遇到通信错误，无法确定问题所在。
在该图中，我们可以看到主控制器的 i2c 最终在 SCL 中产生1,584ms 的暂停，此时 UCD 返回一个 nack。 默认情况下，主 I2c 最终尝试再次发送相同字节，但 UCD 仍返回 NAKC。
由于 i2c 通信是异步通信，并且主中继器拥有控制 SCL 的特权，因此我们无法确定出现这种情况的原因。
因此，正如我所说，我们必须选择使用软件 i2c，在这种情况下，Linux 控制 i2c，它可以在任何时候导致这些延迟，从而处理另一个系统任务。
您所指的最小时钟速度是多少？ UCD i2c 是否不是异步的？
使用硬件 i2c 时，导轨读数经常出现卡入，这是没有明显原因的。 如果按顺序执行状态读取，则会发出 IIC 故障信号，如我们在图像中所见。
我们可以使用它的硬件 i2c，但这一个似乎不支持 strech。 我问只有在 UCD 使用与 Flash 交互的命令(重置闪存错误日志；配置 UCD9081；用户数据)时才会发生 strech？ 只有在这些命令之后才会发生这种情况？ 如果是，您可以使用硬件命令，对于这些命令，请在命令末尾加上延迟。
所以，
我跟随测试，使用了另外3个硬件作为 i2c 主设备来执行与 UCD 从设备的通信测试，所有这些硬件都具有拉伸支撑。
我们可以看到，在向 UCD 发出前16个寄存器(rail1h.rail8l 0x65 0x00 0x10)请求期间，通信错误仍然没有明显的原因发生。
首先，我们可以在图片中看到正确的交付，然后看到对同一请求的错误答案。
据观察，有一段很短的时间由主教练正确照顾，主教练仍在等待必要的时间来继续生成时钟。
