реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> I2C, некоторые тонкости
esaulenka
сообщение May 20 2010, 13:11
Сообщение #1


Профессионал
*****

Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877



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

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

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

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

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

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

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

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


--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
Go to the top of the page
 
+Quote Post
rezident
сообщение May 20 2010, 14:33
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Растягивать низкий уровень на SCL можно только во время передачи слейвом бита ACK, а не после него. После передачи ACK тянуть SCL уже не имеет смысла.
Go to the top of the page
 
+Quote Post
esaulenka
сообщение May 20 2010, 15:03
Сообщение #3


Профессионал
*****

Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877



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

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


--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
Go to the top of the page
 
+Quote Post
rezident
сообщение May 20 2010, 21:45
Сообщение #4


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Не силен в атемловских TWI, но обычно при отсутствии данных в буфере передатчика во время передачи I2C слейв либо автоматом дает NAK, либо держит SCL в нуле на время ACK до тех пор, пока данные не поступят в буфер, либо пока автомат I2C не сбросят записью в какой-нибудь управляющий регистр. Есть ли такой(ие) режим(ы) в AVR и если есть, то как именно он(и) настраивается, я не в курсе. laughing.gif
Go to the top of the page
 
+Quote Post
=AK=
сообщение May 20 2010, 23:53
Сообщение #5


pontificator
******

Группа: Свой
Сообщений: 3 055
Регистрация: 8-02-05
Из: страны Оз
Пользователь №: 2 483



Цитата(esaulenka @ May 20 2010, 22:41) *
Проблема в том, что мастер видит, что байт приняли, ACK ответили, и выставляет флаг SI, что всё нормально.
Дальше также спокойно мы можем отправить стоп (хотя лучше не отправлять, пожалуй).

Дальше мастер должен послать ре-START (или STOP+START, без разницы) и начать чтение. А Мега после приема команды на чтение должна притянуть SCL к нулю, пока не будет готов ответ. После этого мастер "подвиснет" на выдаче первого клока в первом читаемом байте.
Go to the top of the page
 
+Quote Post
esaulenka
сообщение May 21 2010, 07:26
Сообщение #6


Профессионал
*****

Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877



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

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


--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
Go to the top of the page
 
+Quote Post
=AK=
сообщение May 21 2010, 09:38
Сообщение #7


pontificator
******

Группа: Свой
Сообщений: 3 055
Регистрация: 8-02-05
Из: страны Оз
Пользователь №: 2 483



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


Да можно, наверное, и STOP задержать. Просто задержка ответа после приема команды "read", как я предлагал, в точности соответствует Fig.6 спецификации шины. Тут уж не ошибешься, и другим объяснить легче: ткнул носом в доку - и все, пусть читают.
Go to the top of the page
 
+Quote Post
777777
сообщение May 29 2010, 16:06
Сообщение #8


Профессионал
*****

Группа: Участник
Сообщений: 1 091
Регистрация: 25-07-07
Из: Саратов
Пользователь №: 29 357



Цитата(esaulenka @ May 20 2010, 17:11) *
Есть мысль на период обработки команды подвешивать шину - прижимать SCL к земле. То, что в этот момент вешается обмен с остальными устройствами, нас не волнует - мастер всё равно ждёт ответ от атмеги.

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

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

Именно таким способом. Когда данные будут готовы, записываете их в TWDR и сбрасываете TWINT - атмега отпускает SCL и начинает передачу.
Go to the top of the page
 
+Quote Post
777777
сообщение May 29 2010, 17:39
Сообщение #9


Профессионал
*****

Группа: Участник
Сообщений: 1 091
Регистрация: 25-07-07
Из: Саратов
Пользователь №: 29 357



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

То есть, не совсем так. Не сбрасывать TWINT надо по состоянию 0xA8: Own SLA+R has been received
Go to the top of the page
 
+Quote Post
ReAl
сообщение May 29 2010, 20:55
Сообщение #10


Нечётный пользователь.
******

Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417



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

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

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


--------------------
Ну, я пошёл… Если что – звоните…
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st July 2025 - 10:02
Рейтинг@Mail.ru


Страница сгенерированна за 0.01422 секунд с 7
ELECTRONIX ©2004-2016