Вам действительно стоит прочитать здесь спецификацию I2C, но вкратце, есть два разных случая рассмотреть для ACK / NACK:
После отправки адреса подчиненного устройства: когда мастер I2C отправляет адрес подчиненного устройства для разговора (включая бит чтения / записи), подчиненное устройство, которое распознает его адрес, отправляет ACK. Это сообщает мастеру, что ведомое устройство, которого он пытается достичь, действительно находится на шине. Если ни одно ведомое устройство не распознает адрес, результатом будет NACK. В этом случае мастер должен прервать запрос, так как разговаривать не с кем. Обычно это не то, что можно исправить повторной попыткой.
Внутри передачи: после того, как сторона, читающая байт (главный при приеме или ведомый при отправке) получает байт, она должна отправить ACK. Основным исключением является то, что если получатель контролирует количество отправленных байтов, он должен отправить NACK после последнего отправляемого байта. Например, при передаче от ведомого к ведущему ведущий должен отправить NACK непосредственно перед отправкой условия STOP для завершения передачи. (Этого требует спецификация.)
Также может случиться так, что получатель может отправить NACK, если есть ошибка; Я не помню, разрешено ли это спецификацией.
Но суть в том, что NACK либо указывает на фатальное состояние, которое нельзя повторить, либо просто указывает на конец передачи.
Кстати, случай, когда принимающему устройству требуется больше времени для обработки, никогда не указывается NACK. Вместо этого ведомое устройство либо выполняет «растягивание часов» (или ведущее устройство просто задерживает генерацию часов), либо использует протокол более высокого уровня для запроса повторной попытки.
Изменить 6/8/19: как указано @DavidLedger, существуют флэш-устройства I2C, которые используют NACK, чтобы указать, что флэш-память внутренне занята (например, завершает операцию записи). Я вернулся к стандарту I2C (см. Выше) и обнаружил следующее:
Есть пять условий, которые приводят к созданию NACK:
На шине нет получателя с переданным адресом, поэтому нет устройства, которое могло бы ответить подтверждением.
Приемник не может принимать или передавать, потому что он выполняет некоторую функцию в реальном времени и не готов начать обмен данными с мастером.
Во время передачи получатель получает данные или команды, которые он не понимает.
Во время передачи получатель не может получить больше байтов данных.
Мастер-приемник должен сигнализировать об окончании передачи подчиненному передатчику.
Следовательно, эти условия NACK действительны в соответствии со стандартом.
Для коротких задержек, особенно в пределах одной операции, обычно используется растяжение часов, но при более длительных задержках, особенно между операциями, а также при недопустимых операциях, я могу получить NACK.
person
DoxyLover
schedule
10.05.2016
