PIC I2C slave ack on data

Question

Я изучаю протокол I2C для PIC16F88X. Что я хотел бы сделать, это включить ведомый I2C либо ACK, либо NACK в зависимости от данных, полученных на I2C.

PIC может использовать ACK или NACK на адресе I2C, отправленном по линии, но из того, что я прочитал, всегда будет ACK для последующих принятых байтов. Это верно?

В следующем сообщении:

Start - I2c_Addr+write/ACK - Register_value/Nack 

Я хотел рабыню, чтобы иметь возможность Ack или Nack в зависимости от значения в _ значение регистра. Если ведомое устройство не понимает значение _, оно не должно быть Ack.

Не могли бы вы либо подтвердить, что это невозможно, либо рассказать мне, как это сделать?

Answer 1

Если предположить, что с помощью MSSP периферийное

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

более длинный ответ: похоже, что вы пытаетесь проверить, действителен ли байт данных, который получает подчиненный, или нет с помощью ack. лично я бы этого не сделал, ack должен сигнализировать целостность строки, а не проверять целостность данных. Если устройство является подчиненным устройством, мастер по определению должен точно знать, как он должен работать и может проверить правильность байта, прежде чем выталкивать его на линии I2C. В таких случаях я предполагаю, что вы также имеете контроль над кодом хозяина I2C, используйте один общий файл заголовка, который определяет все команды или допустимые байты данных, которые можно отправить, чтобы избежать несоответствий в коде.

Если вы должны гарантировать, что по какой-либо причине был отправлен правильный байт, попросите ведущего запросить подчиненный ответный байт, чтобы подчиненный вернул код, указывающий результат предыдущей передачи.

Если вы намерены гарантировать целостность линии I2C, ни один из этих подходов не работает. Единственный вариант - отправить большую часть байтов при загрузке или периодически с помощью CRC и проверить, совпадает ли он с ведомым. Обычно линии I2C будут работать или нет, они имеют низкую скорость, обычно имеют короткие трассы и имеют высокую допустимую емкость шины, если они не работают, вы вообще не увидите никаких акков.

Answer 2

Моя догадка отсутствует, если оборудование I2C встроено в ПОС. Все аппаратные решения, с которыми я работал, имеют конечный автомат, который не может помочь, кроме ACK второго байта, если в передаче нет чего-то неправильного (например, отсутствует бит). Вам будет лучше сделать свою собственную реализацию I2C в программном обеспечении с бит-биением и буфером с открытым коллектором для ACK. Тогда вы можете делать все, что хотите. Это не стандарт I2C, поэтому следите, не помещаете ли какие-либо устройства в шину, которые не работают с вашими спецификациями. Я не уверен, но я думаю, что для любого стандартного устройства I2C, если он не получает ACK, он может повторно передавать данные или просто сбой, так как не уверен, кто имеет контроль над шиной после сбоя (обозначается NAK).