这与之前的查询(几个月前)有关、I2C 事务在处理器时钟速率降低时发生故障。 由于有一个简单的解决方法(不要太慢！)，我把它放在卷边篮中，但它让我感到很困扰，最后有一些空闲时间来玩它，尝试并了解正在发生的情况。
简而言之、我在主接收器模式下以100K 运行基于 USCI 的 I2C、从传感器读取3个字节的数据(2个字节加一个 PEC)。 这在更高的时钟速率(高于4MHz)下工作正常、但在这种情况下尝试读取一个额外的杂散字节。 下面是我对当前情况的理解。
该文档指出、在读取最终字节时必须请求 STP。 在代码方面、这意味着需要立即请求 STP、以便为倒数第二个字节的 RXBUF 提供服务。 我曾假设我有时间读取最后一个字节来玩-在100K 时、这应该给我大约80uS。 这应该很容易就足够了、尤其是在为倒数第二个字节的 RXBUF 提供服务和请求 STP 之间没有发生任何事情。 但我仍然看到故障、即使是一些微不足道的测试逻辑、RXBUF 读取紧随 STP 之后。 逻辑分析仪的一个游戏、以及对文档的另一个阅读、终于让我们了解了这一点。
我忽略了 USCI 对传入字节的缓冲、并将在等待前一个 RXBUF 被处理时继续计时和读取数据。 如果 RXBUF 没有及时处理(这是在降低的时钟速率下发生的情况)、USCI 最终将在缓冲完除下一个字节的最后一位之外的所有位后停止 I2C 时钟。 一旦 RXBUF 被读取、它将立即为最后一个位计时。 这意味着、如果下一个字节已经被完全缓冲、则可用窗口仅是读取最后一位所需的时间(大约8us)、而不是读取整个字节以使 STP 就位所需的时间(~80us)。 在低 MSP 时钟速率(例如1MHz)下、在 USCI 完成接收当前字节并开始读取另一个杂散字节之前、根本没有足够的时间来请求 STP。
此声音是否有效？ 除了对低 MSP 时钟速率和高 I2C 数据速率的组合非常谨慎之外、我看不到任何保护方法。
此致- Andrew
