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