i2c - I2c 总线上的 NACK 和 ACK 响应

我最近的项目需要使用具有多个从站的单个主站来使用 i2c 通信。我知道对于主机发送的每个数据字节(实际数据)，从机以 Nack\Ack(1,0) 响应。
我很困惑如何解释这个 Nack 和 ACK。我在网上搜索，但我没有清楚地了解这一点。我的理解是这样的。

ACK-我已成功接收数据。给我发送更多数据。
NACK- 我还没有收到数据。再次发送。
这是这样的还是我错了。
请澄清并提出正确答案。

谢谢
阿米特·库马尔

最佳答案

您确实应该阅读 I2C 规范 here ，但简而言之，ACK/NACK 有两种不同的情况需要考虑:

发送从机地址后:当 I2C 主机发送要通话的从机地址(包括读/写位)时，识别其地址的从机发送 ACK。这告诉主站它试图访问的从站实际上在总线上。如果没有从设备识别该地址，则结果为 NACK。在这种情况下，主人必须中止请求，因为没有人可以与之交谈。这通常不是可以通过重试来解决的问题。

在一次传输中:在读取一个字节的一侧(接收时主机或发送时从机)接收到一个字节后，它必须发送一个 ACK​​。主要的异常(exception)是如果接收器控制发送的字节数，则它必须在要发送的最后一个字节之后发送 NACK。例如，在从设备到主设备的传输中，主设备必须在发送停止条件以结束传输之前发送 NACK。 (这是规范要求的。)

也可能是接收方有错误可以发送NACK；我不记得规范是否允许这样做。

但最重要的是，NACK 要么表示无法重试的致命情况，要么只是表示传输结束。

顺便说一句，接收设备需要更多时间来处理的情况从不由 NACK 指示。相反，从设备要么执行“时钟延长”(或主设备只是延迟生成时钟)，要么使用更高层的协议(protocol)来请求重试。

2019 年 6 月 8 日编辑:正如@DavidLedger 所指出的，有些 I2C 闪存设备使用 NACK 来指示闪存内部繁忙(例如完成写操作)。我回到 I2C 标准(见上文)，发现以下内容:



因此，这些 NACK 条件根据标准是有效的。

短延迟，特别是在单个操作中，通常会使用时钟延长，但较长的延迟，尤其是在操作之间，以及无效操作，我会产生 NACK。

关于i2c - I2c 总线上的 NACK 和 ACK 响应，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37040696/