[参考译文] MSPM0G1507：在快速模式 (400kHz) 下进行通信时、控制器侧会在重复启动操作中将数据移位 1 个字节

尊敬的 O.H：

我不确定我是否理解正确、当 I2C 目标器件中接收到第一个 RX 字节时、您想填充 I2C TXFIFO、这样在重复启动情况下、I2C 数据将在“R“序列之前准备就绪、我是对的吗？

这听起来不错、请注意在首次填充 TXFIFO 之前刷新 TXFIFO。 您是否在这个逻辑上进行了测试、并解决了任何问题？

谢鹏飞

感谢您的答复。

我不确定我是否理解正确、当 I2C 目标器件中接收到第一个 RX 字节时、您要填充 I2C TXFIFO、因此在重复启动情况下、I2C 数据将在“R“序列之前准备就绪、我对吗？

基本正确。 更准确地说、我对于 接收 RX 字节的确切时序并不特别。 只要 在重复 START 事务中的“R“序列之前准备了 I2C 数据、任何时序都是可以接受的。

听起来不错、请注意在首次填充 TXFIFO 之前刷新 TXFIFO。 您是否使用此逻辑进行了测试并解决了任何问题？

此时、我还没有看到实际行为中存在任何问题。
我提出的原因是、我想确认 TI 是否有适合此用例的推荐方法、以及该方法是否存在任何潜在的问题或疑虑。

此致、
正常

谢鹏飞

很抱歉耽误你。 是否有其他意见或信息？

此致、
正常

嗨、O.H

很抱歉晚才回复。

请注意、在读取重复开始命令的序列之前、您只需确保 TX 数据准备充分。

我这边只有一条注释、如果 TX 数据是固定的、那么您可以在控制器读取 TX 数据之前随时准备该数据。 但是、如果此 TX 数据可由应用程序更改或应根据从控制器接收到的数据而有所不同、则最好在从控制器接收到重复启动命令的第一个字节时准备 TX 数据。

 谢鹏飞

感谢您的答复。

然后、当从控制器接收到 REPEAT START 命令的第一个字节时、最好准备 TX 数据。

如果“在接收到重复启动命令的第一个字节时准备好 TX 数据“、则移入 TX FIFO 的数据移位无法及时完成、从而导致 1 字节移位。 这正是我们所面临的问题、正因为如此、我们才提出这个问题。

尊敬的 O.H：

根据您的当前代码、看起来从 TXFIFO 以“R“序列发送的数据与 RX 缓冲区中先前接收到的数据相同。 如果这是您在应用中所需的功能、那么您当前的实现将会很好、我这边没有其他建议。

 谢鹏飞

感谢您的答复。

您是否打算在不进行时钟延展的情况下执行此操作（如另一个线程中所述）？ 时钟延展是 I2C 中的主（可以说是唯一的）流控制机制。 如果没有流量控制、总会有竞争。 重复启动情况下的竞态幅度为 (1+8+1) 个位时间、或 400KHz I2C 时为 25usec－32MHz 时为 800 个 SYSCLK、但这包括任何唤醒时间。

您的图表似乎描述了“寄存器“（或可能是“EEPROM“）模型的一个非常受限的版本、其中：

1) 不写入数据、因此每次写入时为 3 个字节（存储器地址）。

2) 每次写入之后、都会读取一个已知长度。

如果是、您的 Rx 代码可能会计数到 3 并立即开始填充 TXFIFO。 如果没有 (2)、这可能会在 TXFIFO 中留下过时的数据；I2C 单元中有一种机制来处理此问题、但它需要时钟延展才能工作。 如果没有 (1)、目标将不知道在后续启动中的 R/W 位之前是否有读取操作、因此竞速幅度约为 0。

或者、您可能需要停止（无重复启动）和控制器中停止 (W) 和启动 (R) 之间的人工延迟。 这有一些先例（虽然相当罕见）,它只是改善了比赛,而不是消除它。