[esaulenka 7]

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

 

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

 

Протокол обмена:

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

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

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

 

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

 

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

 

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

 

Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.

Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).

Только на старте чтения мастер осознаёт, что что-то пошло не так, и долго выставляет SI на условие передачи старта.

 

Так вот, вопрос: это нормально для LPC, что он не видит этого "растянутого" обмена?

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

[rezident 0]

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

[esaulenka 7]

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

 

Вот только никак не соображу, что надо сделать с регистрами TWI, чтобы такого добиться.

Махинации с soft-I2C мне не очень нравятся...

[rezident 0]

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

[=AK= 12]

Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.

Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).

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

[esaulenka 7]

Спасибо за ответы.

С практикой понятно. Теперь осталось подтянуть теорию :)

 

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

[=AK= 12]

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

 

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

[777777 0]

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

 

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

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

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

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

[777777 0]

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

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

[ReAl 0]

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

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

 

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

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

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

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

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

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

 

Кстати, тут по соседству обсуждаются другие проблемы, но решение тут может быть таким же -- вообще уйти от операции чтения на шине.

http://electronix.ru/forum/index.php?s=&am...st&p=765090