Если вы используете периферийное устройство MSSP
краткий ответ: То, о чем вы просите, возможно, невозможно с PIC, по крайней мере, без ударов по битам линий ввода / вывода. Причина в том, что подтверждение / подтверждение проверяется на 9-м тактовом фронте, а прерывание SSPIF не срабатывает до конца 9-го тактового сигнала. Вы можете попытаться повторно проверить бит BF, как он установлен, как только байт данных сдвинут в регистр ввода / вывода (8-й такт). Если вы можете выполнить сравнение и установить бит SSPOV до 9-го тактового цикла, это должно сгенерировать NACK, это довольно схематично, если у вас запущены какие-либо прерывания.
более длинный ответ: звучит так, будто вы пытаетесь проверить, является ли байт данных, который получает ведомый, действительным или не использует ack. лично я бы не стал этого делать, ack должен сигнализировать о целостности линии, а не проверять целостность данных. Если устройство является подчиненным, мастер по определению должен точно знать, как оно должно работать, и может проверить правильность байта, прежде чем выдвинуть его на линии I2C. В таких случаях я предполагаю, что у вас также есть контроль над основным кодом I2C, используйте один общий заголовочный файл, который определяет все команды или действительные байты данных, которые можно отправлять, чтобы избежать несоответствий в коде.
Если вы по какой-то причине должны гарантировать, что правильный байт был отправлен, попросите, чтобы мастер запросил у ответного байта ответный байт, чтобы подчиненный вернул код, указывающий результат предыдущей передачи.
Если ваша цель - гарантировать целостность линии I2C, ни один из этих подходов действительно не работает. Единственным вариантом будет отправлять большую часть байтов при загрузке или периодически с CRC и проверять, совпадают ли они на ведомом устройстве. Обычно линии I2C либо работают, либо нет, они имеют низкую скорость, обычно имеют короткие трассы и имеют высокую допустимую емкость шины, если они не работают, вы вообще не увидите никаких подтверждений.