请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：SN65DSI85 主题中讨论的其他器件： SN65DSI83、 SN65DSI84
我们开始在设计中使用该组件时没有遇到任何问题、当我们移至新电路板时、我们完全失去了与器件的 I2C 通信。
新电路板具有相同的 CPU、相同的 SN65DSI 原理图和布局、但器件数量和同一 I2C 总线上其他器件的布线不同。
在消除任何其他类型的可能错误(包括切断连接到其他器件的 I2C 布线)后、我们注意到该器件对于 SCL 下降时间过长非常明智。 同一总线中的任何其他部件在同一条件下运行。
在 I2C 快速模式下可能会出现这种情况、因为 SCL 下降时间的最小值受到限制、但据我了解、在 I2C 正常模式(<= 100kHz)下、根据 I2C 规范、这是意外的。 深入探究后、第一块电路板在 SCL 上有足够的布线和器件电容来适应快速规格、因此 SN65DSI85似乎希望 SCL 下降时间也在正常模式下限制为快速模式规格。 我想 知道 TI 是否可以确认这一点。
我们设计的解决 方案是放宽 I2C 的驱动强度并避免 Linux GPIO 恢复(驱动程序功能)、在我们的案例中、这两种功能都使 SCL 下降时间大约为4.5ns、而不是6.5ns (1.8V)。 在修补配置并使下降时间超过6.5ns 后、器件开始正确响应。
我希望这一条件也适用于 SN65DSI83和 SN65DSI84。
我希望这一职位能帮助那些不太可能出现同样情况的人。
