Подключаю к STR912 DS1631 (термодатчик). В соответсвии с даташитом, при получении байтов, после получения последнего байта надо передавать NASK вместо ASK. Как бы это провернуть?
А то DS1631 не получив NASK подвисает . И его приходится сбрасывать (вручную) для продолжения работы.

Вы хоть поняли, что спросили?

P.S.
ACK и NAK, имеются ввиду, полагаю?

Что сказал - понял. Просто именно такая терминология используется в даташите к DS1631 и в других местах.

За указание другого термина спасибо. Сейчас попробую погуглить по нему

А я нет . Какая проблема? Байт 0x06 отправлять умею, а оставшиеся 255 вариантов нет?

Не понимаю, при чем тут байт 06?
STR912 автоматически посылает (ну или выставляет) ASK после каждого принятого байта. Если настроено. АSK это вообще то не байт. И сравнивать выставление ASK или NASK с передачей байтов странно.

Очевидно байт 06 это та величина, которую надо записать в командный регистр контроллера I2C STR912, чтобы тот выдал NACK вместо очередного ACK.

Насколько я понял из ироничного ответа zltigo, байт 0x06 как раз служит для отправки ASK, а для отправки NASK нужно что-то другое.
К сожалению, я не могу проверить что-же все таки отправляется на самом деле, т.к. не имею осцилографа

1. ASK и NASK - ведомы ТОЛЬКО Вам.
2. То,о чем речь, это ACK 0x06 и NAK(NotACK) 0x15. Все это смотрится с любой таблице ASCII кодов.

ЭЭЭЭээээ
Вы там буковок в теме "I2C" не заметили?
И то, что сокращение ASK может обозначать не только символ из таблицы но и удержание линии в нулевом состоянии в течении периода клока, а NASK удержание линии данных в "1" состоянии.
К символам это отношения не имеет.
ASK это всего лишь сокращение для Acknowledge, а
NASK для Not Acknowledge.
И если вам это не ведомо, это говорит, что вам не ведом протокол I2C

Нет, к контроллеру это не имеет отношения. Это информационные байты.
По крайней мере я так понял.
Если же речь идет о I2C протоколе, там STOP все кончается после ответа на последний ACK. NAK, как такового в протоколе нет, разве только выдачу ACK автоматом можно отключить.


Мне неведомы БЕЗГРАМОТНЫЕ ASK и NASK вместо ACK и NAK. Понятно?

Ах вот вы к чему придрались! )
К сожалению, страдаю дизграфией. Совершенно спокойно могу написать "влот" вместо "флот". Кто-то не может нормально говорить, у меня проблемы с письмом.
NACK и ACK в I2C протколе имеется. Но это совсем не БАЙТ. Ну как ACK может быть байтом если передается течении одного такта, а байт передается в течении 8 тактов?

В общем, проблема решена. Все работает. Темература успешно отображатеся на LCD

В терминологии Philips - владельцев патента на I2C сокращения ACK и NACK не используются.
Есть четкое понятие "Acknowledge Flag". Он может присутствовать/передаваться или просто отсутствовать. Отсутствие флага не значит, что было передано неподтверждение, поскольку устройство может просто отсутствовать. Посему "Передавать NACK" термин по отношению к I2C некорректный. Правильно - "Ну устанавливать ACK Flag"("Не передавать ACK").

Что вы говорите.....
Берем первый попавшийся пример с сайта филипса и читаем

;* acknowledge bit. If NACK is received, the NO_ACK bit is *
;* set. If arbitration is lost or an error occurs during *
;* I2C_TRX_BYTE the function is exit with the I2C_ERR bit *
;* set. *
....
MOV I2DAT,#80H ;send NACK

Т.е. и филипс использует сокрашение NACK и его (NAСK) можно "передать" или "принять".

Что еще придумаем?

А зачем "первый попавшийся"? Есть вполне официальные документы, а не какие-то комментарии из двух слов к неким исходникам в АN писанные какими-то программистами. В спецификации I2C и в базирующихся на ней документах на контроллеры Philips понятия Negative ACK (NAK/NACK) отсутствует.
В документации на STR912, естественно, отсутствуют тоже. Есть Acknowledge и Non-Acknowledge.
Собственно Ваши проблемы и начались с того, что Вы захотели "Послать неподтверждение", вместо того, что бы "Не посылать подтверждение". Что совсем не одно и тоже и поскольку "Послать неподтверждение" принципиально не возможно на I2C, то этого действия Вы в документации на контроллер и не нашли. А я соответственно совсем не понял вопрос, о чем и написал в первом-же своем посте.

Это Вы сами c собой разговариваете?

Он нашел, потому так и спросил.
В STR91x это приблизительно так и выглядит. Надо явно установить бит посылки подтверждений и явно этот бит сбросить перед приемом последнего байта.
Но только фокус в том, что сбросить его надо еще когда начинаем принимать предпоследний байт.
Доку на STR91x пишут какие-то чурки из Туниса, так что удивляться не приходится.

Только не в доке не STR - она в части интерфейса I2C не отступает от канонического варианта. А в доке на Maxim, вот там действительно чурки писали и разрабатывали, кстати, тоже.

Также я его нашел в примерах кода на этом сайте, на других сайтах. На сайте филипса.
Не надо путать термин используемый в спецификации и сокращение, которое ШИРОКО используется при программировании. В том числе и в сочетании со словом SEND

Что совершенно не означает правильности и правомерности его использования.

Я все-таки хотел получить совет о том как что-то сделать, а не о допустимости использования отдельных нестандартных терминов при общении на форуме. Те, кто в теме меня прекрасно поняли.

"Прекрасное понимание" отражено в переписке . Как только к посту №9 Вас стало возможным понять, я в следующем №10 ответил про отключение выдачи ACK (что Вы и сделали) и отсутствие Negative ACK в I2C.