Home/ Questions/Q 223069
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T19:11:11+00:00

I am looking into the I2C protocol for PIC16F88X. What I would like to

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0