I2C, некоторые тонкости Опции

[esaulenka]

Имеем два контроллера - LPC213x и ATmega, сопряжённые по I2C.

LPC - мастер, мега - слейв. Для простоты будем считать, что других устройств на шине нету (могут быть ещё слейвы, но пока - без них).

Протокол обмена:
мастер отправляет команду
слейв её обрабатывает, кладёт ответ в буфер
мастер считывает ответ

Есть мысль на период обработки команды подвешивать шину - прижимать SCL к земле. То, что в этот момент вешается обмен с остальными устройствами, нас не волнует - мастер всё равно ждёт ответ от атмеги.

Вопрос: когда бы это по хорошему сделать?

По приёму последнего байта посылки (состояние TWSR 0x80) я не сбрасываю бит TWINT - нога SCL в нуле.

Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.
Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).
Только на старте чтения мастер осознаёт, что что-то пошло не так, и долго выставляет SI на условие передачи старта.

Так вот, вопрос: это нормально для LPC, что он не видит этого "растянутого" обмена?
В документации сказано, что данный приём можно использовать как для каждого бита, так и после передачи всего байта. Вот интересно, отправленный ACK - это "after complete byte transfer" или нет?

[rezident]

Растягивать низкий уровень на SCL можно только во время передачи слейвом бита ACK, а не после него. После передачи ACK тянуть SCL уже не имеет смысла.

[esaulenka]

Насколько я понимаю, правильней говорить "перед передачей ACK", т.к. в момент этого ACK SCL должен быть в единице.

Вот только никак не соображу, что надо сделать с регистрами TWI, чтобы такого добиться.
Махинации с soft-I2C мне не очень нравятся...

[rezident]

Не силен в атемловских TWI, но обычно при отсутствии данных в буфере передатчика во время передачи I2C слейв либо автоматом дает NAK, либо держит SCL в нуле на время ACK до тех пор, пока данные не поступят в буфер, либо пока автомат I2C не сбросят записью в какой-нибудь управляющий регистр. Есть ли такой(ие) режим(ы) в AVR и если есть, то как именно он(и) настраивается, я не в курсе.

[=AK=]

Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.
Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).

Дальше мастер должен послать ре-START (или STOP+START, без разницы) и начать чтение. А Мега после приема команды на чтение должна притянуть SCL к нулю, пока не будет готов ответ. После этого мастер "подвиснет" на выдаче первого клока в первом читаемом байте.

[esaulenka]

Спасибо за ответы.
С практикой понятно. Теперь осталось подтянуть теорию

Разглядывание даташитов на ATmega, на LPC и спецификации на шину не прояснило, почему нельзя "задерживать" отправку stop.

[=AK=]

Разглядывание ... спецификации на шину не прояснило, почему нельзя "задерживать" отправку stop.

Да можно, наверное, и STOP задержать. Просто задержка ответа после приема команды "read", как я предлагал, в точности соответствует Fig.6 спецификации шины. Тут уж не ошибешься, и другим объяснить легче: ткнул носом в доку - и все, пусть читают.

[777777]

Есть мысль на период обработки команды подвешивать шину - прижимать SCL к земле. То, что в этот момент вешается обмен с остальными устройствами, нас не волнует - мастер всё равно ждёт ответ от атмеги.

Вопрос: когда бы это по хорошему сделать?

Как я понял, мастер всегда передает команду, после чего читает ответ от атмеги. Следовательно, передача будет комбинированной: сначала мастер передает адрес со сброшенным седьмым битом (запись), затем передает один или несколько байт команды, затем передается рестарт, после него опять передается тот же адрес, но с установленным седьмым битом (чтение), после чего мастер выдает клоки пытаясь прочитать байт от слейва. Вот тут-то его и надо тормозить.

По приёму последнего байта посылки (состояние TWSR 0x80) я не сбрасываю бит TWINT - нога SCL в нуле.

Именно таким способом. Когда данные будут готовы, записываете их в TWDR и сбрасываете TWINT - атмега отпускает SCL и начинает передачу.

[777777]

Именно таким способом. Когда данные будут готовы, записываете их в TWDR и сбрасываете TWINT - атмега отпускает SCL и начинает передачу.

То есть, не совсем так. Не сбрасывать TWINT надо по состоянию 0xA8: Own SLA+R has been received

[ReAl]

Просто задержка ответа после приема команды "read", как я предлагал, в точности соответствует Fig.6 спецификации шины. Тут уж не ошибешься, и другим объяснить легче: ткнул носом в доку - и все, пусть читают.

А заодно больше соответствует логике работы.

мастер отправляет команду

И не нужно его тормозить в конце отправки. Пока

слейв её обрабатывает, кладёт ответ в буфер

он может чем-то полезнм заняться, не сейчас, так при модификации программы. А если ему нечего делать, то сразу

мастер считывает ответ

и вот тут, если слейв не готов, он задерживает. Или не задерживает, если за время (STOP+START или RESTART) + передача адреса он уже успел всё сделать.

Кстати, тут по соседству обсуждаются другие проблемы, но решение тут может быть таким же -- вообще уйти от операции чтения на шине.
http://electronix.ru/forum/index.php?s=&am...st&p=765090