Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: I2C
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Интерфейсы
esaulenka
Имеем два контроллера - LPC213x и ATmega, сопряжённые по I2C.

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

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

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

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

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

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

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

Вот только никак не соображу, что надо сделать с регистрами TWI, чтобы такого добиться.
Махинации с soft-I2C мне не очень нравятся...
rezident
Не силен в атемловских TWI, но обычно при отсутствии данных в буфере передатчика во время передачи I2C слейв либо автоматом дает NAK, либо держит SCL в нуле на время ACK до тех пор, пока данные не поступят в буфер, либо пока автомат I2C не сбросят записью в какой-нибудь управляющий регистр. Есть ли такой(ие) режим(ы) в AVR и если есть, то как именно он(и) настраивается, я не в курсе. laughing.gif
=AK=
Цитата(esaulenka @ May 20 2010, 22:41) *
Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.
Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).

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

Разглядывание даташитов на ATmega, на LPC и спецификации на шину не прояснило, почему нельзя "задерживать" отправку stop.
=AK=
Цитата(esaulenka @ May 21 2010, 16:56) *
Разглядывание ... спецификации на шину не прояснило, почему нельзя "задерживать" отправку stop.


Да можно, наверное, и STOP задержать. Просто задержка ответа после приема команды "read", как я предлагал, в точности соответствует Fig.6 спецификации шины. Тут уж не ошибешься, и другим объяснить легче: ткнул носом в доку - и все, пусть читают.
777777
Цитата(esaulenka @ May 20 2010, 17:11) *
Есть мысль на период обработки команды подвешивать шину - прижимать SCL к земле. То, что в этот момент вешается обмен с остальными устройствами, нас не волнует - мастер всё равно ждёт ответ от атмеги.

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

Как я понял, мастер всегда передает команду, после чего читает ответ от атмеги. Следовательно, передача будет комбинированной: сначала мастер передает адрес со сброшенным седьмым битом (запись), затем передает один или несколько байт команды, затем передается рестарт, после него опять передается тот же адрес, но с установленным седьмым битом (чтение), после чего мастер выдает клоки пытаясь прочитать байт от слейва. Вот тут-то его и надо тормозить.
Цитата(esaulenka @ May 20 2010, 17:11) *
По приёму последнего байта посылки (состояние TWSR 0x80) я не сбрасываю бит TWINT - нога SCL в нуле.

Именно таким способом. Когда данные будут готовы, записываете их в TWDR и сбрасываете TWINT - атмега отпускает SCL и начинает передачу.
777777
Цитата(777777 @ May 29 2010, 20:06) *
Именно таким способом. Когда данные будут готовы, записываете их в TWDR и сбрасываете TWINT - атмега отпускает SCL и начинает передачу.

То есть, не совсем так. Не сбрасывать TWINT надо по состоянию 0xA8: Own SLA+R has been received
ReAl
Цитата(=AK= @ May 21 2010, 12:38) *
Просто задержка ответа после приема команды "read", как я предлагал, в точности соответствует Fig.6 спецификации шины. Тут уж не ошибешься, и другим объяснить легче: ткнул носом в доку - и все, пусть читают.
А заодно больше соответствует логике работы.

Цитата
мастер отправляет команду
И не нужно его тормозить в конце отправки. Пока
Цитата
слейв её обрабатывает, кладёт ответ в буфер
он может чем-то полезнм заняться, не сейчас, так при модификации программы. А если ему нечего делать, то сразу
Цитата
мастер считывает ответ
и вот тут, если слейв не готов, он задерживает. Или не задерживает, если за время (STOP+START или RESTART) + передача адреса он уже успел всё сделать.

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