PIC I2C 从机确认数据
我正在研究 PIC16F88X 的 I2C 协议。 我想做的是根据 I2C 上接收到的数据启用 I2C 从机以 ACK 或 NACK。
PIC 可以对线路上发送的 I2C 地址进行 ACK 或 NACK，但从我读到的内容来看，它将始终对后续接收到的字节进行 ACK。 那是对的吗？
在以下通信中：
Start - I2c_Addr+write/ACK - Register_value/Nack
我希望从站能够根据 Register_value 中的值进行 Ack 或 Nack。 如果从设备不理解 Register_ 值，则不应确认。
有人可以确认这是不可能的，或者告诉我该怎么做吗？
I am looking into the I2C protocol for PIC16F88X.
What I would like to do, is to enable an I2C slave to either ACK or NACK depending on the data received on the I2C.
The PIC can ACK or NACK on the I2C address sent on the line, but from what I've read it will always ACK on the subsequent received bytes. Is that correct?
In the following communication:
Start - I2c_Addr+write/ACK - Register_value/Nack
I'd like the slave to be able to Ack or Nack depending on the value in Register_value. If the slave does not understand Register_value, it should not Ack.
Could someone please either confirm that this is not possible, or tell me how to do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
假设您使用 MSSP 外设，
简短回答：您所要求的内容对于 PIC 来说可能是不可能的，至少在没有位碰撞 I/O 线的情况下是不可能的。 原因是在第 9 个时钟沿检查 ack/nack，并且直到第 9 个时钟结束才触发 SSPIF 中断。 您可以尝试重复检查 BF 位，因为一旦数据字节移入 I/O 寄存器（第 8 个时钟），该位就被设置。 如果您可以在第 9 个时钟周期之前完成比较并设置 SSPOV 位，这应该会生成 NACK，如果您有任何中断正在运行，则这是相当粗略的。
更长的答案：听起来你试图验证从机接收到的数据字节是否有效或不使用ack。 就我个人而言，我不会这样做，ack是为了表示线路的完整性，而不是验证数据的完整性。 如果设备是从设备，则根据定义，主设备必须确切地知道它是如何工作的，并且可以在将字节推送到 I2C 线路之前检查字节的有效性。 在这种情况下，我假设您还可以控制 I2C 主设备的代码，请使用一个通用头文件来定义可以发送的所有命令或有效数据字节，以避免代码中的不匹配。
如果由于某种原因必须保证发送正确的字节，请让主站向从站请求响应字节，让从站返回一个指示先前传输结果的代码。
如果您的目的是保证 I2C 线路的完整性，那么这些方法都不起作用。 您唯一的选择是在启动时发送大量字节或定期使用 CRC 发送大量字节，并检查它在从属设备上是否匹配。 一般来说，I2C 线路要么工作，要么不工作，它们速度低，通常走线短，允许的总线电容高，如果它们不工作，您根本看不到任何确认。
Assuming your using the MSSP peripheral
short answer: What your asking for is not probably possible with a PIC, at least without bit banging I/O lines. The reason is that ack / nack is checked on the 9th clock edge and the SSPIF interrupt is not fired until the end of the 9th clock. You could attempt to repeatedly check the BF bit as it is set as soon as the data byte is shifted into the I/O register(8th clock). If you can pull off a comparison and set the SSPOV bit before the 9th clock cycle this should generate a NACK, this is quite sketchy if you have any interrupts running.
longer answer: it sounds like your attempting to validate if the data byte the slave receives is valid or not using ack. personally i wouldn't do this, ack is to signal the integrity of the line, not verify data integrity. If the device is a slave the master by definition must know exactly how it is to work and can check the validity of the byte before pushing it out on the I2C lines. In such cases i assume you also have control over the I2C master's code, use one common header file that defines all the commands or valid data bytes that can be sent to avoid mismatches in the code.
If you must guarantee the proper byte was sent for some reason, have the master ask the slave for a response byte, have the slave return a code indicating the result of the previous transfer.
If your intent is to guarantee the integrity of the I2C line, none of these approaches really work. Your only option would be to send a bulk of a bytes at boot or periodically with a CRC and check that it matches on the slave. Generally I2C lines will either work or not, they are low speed, generally have short traces and have high allowable bus capacitance, if they arn't working you won't see any ack's at all.
如果 I2C 硬件内置于 PIC 中，我的猜测是不会。 我使用过的所有硬件解决方案都有一个状态机，它只能确认第二个字节，除非传输出现问题（例如丢失了一点）。 您最好在软件中使用位碰撞和用于 ACK 的集电极开路缓冲区来实现自己的 I2C。 然后你就可以做任何你想做的事。 它不是 I2C 标准，因此请注意是否在总线上放置了任何不符合您的规格的设备。 我不确定，但我认为对于任何标准 I2C 设备，如果它没有收到 ACK，它可能会重新传输数据或只是出现故障，因为它不确定在故障后谁拥有总线控制权（由 NAK 表示） ）。
My guess is no IF the I2C hardware is built-in to the PIC. All of the hardware solutions I've worked with have a state machine that can't help but ACK the second byte unless there's something wrong with the transmission (missing a bit for instance). You'd be better off making your own I2C implementation in software with bit-banging and an open-collector buffer for the ACK. Then you can do anything you want. It won't be I2C standard, so watch out if you put any devices on the bus that aren't working to your specifications. I'm not sure offhand but I think for any standard I2C device if it doesn't receive an ACK it may retransmit the data or just fault since it isn't sure who has control of the bus after a failure (signified by a NAK).