我正在研究PIC16F88X的I2C协议。 我想做的是根据I2C上接收的数据启用I2C从设备ACK或NACK。
PIC可以对线路上发送的I2C地址进行ACK或NACK，但是根据我的读取，它将始终在后续接收的字节上进行ACK。这是对的吗？
在以下沟通中：
Start - I2c_Addr+write/ACK - Register_value/Nack
我希望奴隶能够根据寄存器_的值来确认Ack或Nack。如果从属设备不理解注册_值，则不应该确认。
有人可以确认这是不可能的，或者告诉我该怎么做？
答案 0 :(得分：8)
假设您使用MSSP外设
简短的回答：使用PIC可能无法满足您的要求，至少没有比特敲击I / O线。原因是在第9个时钟沿检查ack / nack，并且直到第9个时钟结束才触发SSPIF中断。只要数据字节移入I / O寄存器（第8个时钟），就可以尝试重复检查BF位。如果您可以在第9个时钟周期之前进行比较并将SSPOV位置1，则应生成NACK，如果您正在运行任何中断，这非常粗略。
更长的答案：听起来你试图验证从机接收的数据字节是否有效使用ack。我个人不会这样做，ack是表示线路的完整性，而不是验证数据的完整性。如果器件是从器件，则定义器必须确切地知道它是如何工作的，并且可以在将字节推出I2C线之前检查字节的有效性。在这种情况下，我假设您也可以控制I2C主代码，使用一个公共头文件来定义可以发送的所有命令或有效数据字节，以避免代码中的不匹配。
如果您必须保证由于某种原因发送了正确的字节，请让主设备向从设备询问响应字节，让从设备返回指示前一次传输结果的代码。
如果您的目的是保证I2C线路的完整性，那么这些方法都不起作用。您唯一的选择是在启动时发送大量字节，或者使用CRC定期发送，并检查它是否与从站匹配。一般情况下I2C线路是否工作，它们是低速的，通常具有较短的走线并具有较高的允许总线电容，如果它们无法正常工作，则根本不会看到任何确认。
答案 1 :(得分：1)
如果I2C硬件内置于PIC，我的猜测是否定的。我使用的所有硬件解决方案都有一个状态机，除非传输出现问题（例如缺少一点），否则无法确认第二个字节。你最好在软件中使用bit-banging和一个用于ACK的开放式收集器缓冲区来实现自己的I2C实现。然后你可以做任何你想做的事。它不是I2C标准，因此请注意您是否在总线上放置了不符合您规格的设备。我不确定，但我认为对于任何标准I2C设备，如果它没有收到ACK，它可能会重新传输数据或只是故障，因为它不确定谁在失败后控制了总线（由NAK表示） ）。