вопрос по работе TWI Опции

[zoddy]

Всем доброго времени суток! Суть темы такая. Имеется небольшая отладочная макетная плата, на которой установлено два контроллера. Есть необходимость связать их по TWI. Линии TWI подтянуты к питанию через 10К резисторы. Для пробы для обоих контроллеров написаны простенькие программки ведущего и ведомого, с помощью которых происходит пересылка данных по 2-3 байта от ведущего к ведомому и обратно. Суть проблемы: наблюдается неустойчивая работа связи по TWI на больших скоростях, а на более низких скоростях обмен происходит нормально. Подскажите пожалуйста, как решить эту проблему?

[ARV]

Всем доброго времени суток! Суть темы такая. Имеется небольшая отладочная макетная плата, на которой установлено два контроллера. Есть необходимость связать их по TWI. Линии TWI подтянуты к питанию через 10К резисторы. Для пробы для обоих контроллеров написаны простенькие программки ведущего и ведомого, с помощью которых происходит пересылка данных по 2-3 байта от ведущего к ведомому и обратно. Суть проблемы: наблюдается неустойчивая работа связи по TWI на больших скоростях, а на более низких скоростях обмен происходит нормально. Подскажите пожалуйста, как решить эту проблему?

а разве по стандарту i2c подтяжки делаются 10-килоомными? и что вы подразумеваете под "большими" и "низкими" скоростями? стандартом i2c определено 2 скорости - 100 кбит/с и 400 кбит/с

[zoddy]

а разве по стандарту i2c подтяжки делаются 10-килоомными? и что вы подразумеваете под "большими" и "низкими" скоростями? стандартом i2c определено 2 скорости - 100 кбит/с и 400 кбит/с

Согласно мануалу... в модуле TWI имеется Bit Rate Generator задающий период следования импульсов по линии SCL. В mege16, к примеру, частота этого генератора задается значениями регистра TWBR и битами TWPS1:TWPS0. Соответственно меняя значение этого регистра, я так понимаю, можно регулировать скорость передачи. В моем случае, при тактовой частоте обоих контроллеров 4МГц, стабильно данные начинают передаваться при TWBR>0x3f, а на меньших значениях происходит потеря некоторых байт. Мне в моем проекте необходимо передавать информацию с максимально возможной для этого интерфейса скоростью, поэтому этот вопрос весьма интересен :-)

[demiurg_spb]

Чем выше скорость тем резче должны быть фронты. Надо смотреть осциллографом что у Вас творится.
По законам физики для поднятия переднего фронта надо уменьшать сопротивления подтягивающих резисторов, а для поднятия заднего - увеличивать. Вам остаётся посмотреть на ситуацию и принять решение...

[Maik-vs]

... В моем случае, при тактовой частоте обоих контроллеров 4МГц, стабильно данные начинают передаваться при TWBR>0x3f, а на меньших значениях происходит потеря некоторых байт.

Напомнило советский плакат: "В прошлом году собрали 29 центнеров с гектара, в этом - 13000 пудов по краю, в следующем - на 15% больше!"
Какая частота при значении 3F? Частота клока меньшается или увеличивается "при TWBR>0x3f"? Там ещё есть ограничение по частоте контроллера от частоты SCL. Дальше. Если "потеря некоторых байт" то надо смотреть программу выдёргивания байт из потока, может пока идёт операция с байтом на АСК уже опоздали... Клок стретчинг предусмотрен?

Сообщение отредактировал Maik-vs - Feb 18 2009, 10:21

[zoddy]

Напомнило советский плакат: "В прошлом году собрали 29 центнеров с гектара, в этом - 13000 пудов по краю, в следующем - на 15% больше!"
Какая частота при значении 3F? Частота клока меньшается или увеличивается "при TWBR>0x3f"? Там ещё есть ограничение по частоте контроллера от частоты SCL. Дальше. Если "потеря некоторых байт" то надо смотреть программу выдёргивания байт из потока, может пока идёт операция с байтом на АСК уже опоздали... Клок стретчинг предусмотрен?

Гм... Если Вы, многоуважаемый, хоть раз читали мануал по контроллерам AVR, то вполне бы наткнулись там на формулу
Fscl=Fclk/(16*TWBR*4^TWPS)...как вы думаете, что происходит с частотой?....:-)

А вообще ситуация обстоит в следующем... сперва ведущий отправляет SLA+R и читает несколько байт, затем после задержки в несколько тактов процессора отправляет SLA+W и скидывает на ведомый несколько байт, затем опять повторяем операцию чтения(читаем те же байты которые до этого отправляли)... и тут самое интересное... эти байты считываются неправильно!!!

Если же частоту понижаем, выставив значение TWBR>0x3F то обмен происходит без потерь.

З.Ы. Для программы ведущего используется атмеловский драйвер(описан в AVR315), для ведомого написана небольшая программка на асме.

[IgorKossak]

zoddy, Вам уже напоминали о резисторах подтяжки. 10К - этого даже для 400кГц слишком много. Я в последнем случае ставлю 2.7К, на бОльших скоростях нужно ставить ещё меньше.

[zoddy]

zoddy, Вам уже напоминали о резисторах подтяжки. 10К - этого даже для 400кГц слишком много. Я в последнем случае ставлю 2.7К, на бОльших скоростях нужно ставить ещё меньше.

Спасибо за дельный совет. После замены резисторов на 1К и небольшой корекции программы ведомого обмен идет без сбоев даже на максимальной Fscl для выбранной тактовой частоты

[Maik-vs]

Гм... Если Вы, многоуважаемый, хоть раз читали мануал по контроллерам AVR, то вполне бы наткнулись там на формулу
Fscl=Fclk/(16*TWBR*4^TWPS)...как вы думаете, что происходит с частотой?....:-)

А вообще ситуация обстоит в следующем... сперва ведущий отправляет SLA+R и читает несколько байт, затем после задержки в несколько тактов процессора отправляет SLA+W и скидывает на ведомый несколько байт, затем опять повторяем операцию чтения(читаем те же байты которые до этого отправляли)... и тут самое интересное... эти байты считываются неправильно!!!

Если же частоту понижаем, выставив значение TWBR>0x3F то обмен происходит без потерь.

Вы, я вижу, уже решили проблему резисторами (на этой длине линии).
Но в этом посте напрягает "после задержки в несколько тактов процессора". Возможно, Вам, многоуважаемый, стоит более внимательно отнестись к параметру tbuf, приведённом на рис. 27 фирменного руководства по I2C.

Сообщение отредактировал Maik-vs - Feb 19 2009, 10:21

[zoddy]

Вы, я вижу, уже решили проблему резисторами (на этой длине линии).
Но в этом посте напрягает "после задержки в несколько тактов процессора". Возможно, Вам, многоуважаемый, стоит более внимательно отнестись к параметру tbuf, приведённом на рис. 27 фирменного руководства по I2C.

Да не напрягайтесь Вы так, право же.. это лишнее!!! :-)
Все когда-нибудь бывает в первый раз, в том числе и изучение интерфейсов навроде i2c, и не всегда под рукой бывает "фирменное руководство... с рисунком 27". И именно для этого создаются подобные форумы, чтобы была возможность получить дельный совет, консультацию и т.п. ,а не "подколки" и чьи-либо "напряжения"... так что... если нечего посоветовать, то лучше оставляйте свои размышления при себе... поэкономьте здоровье и время :-)

[haker_fox]

Все когда-нибудь бывает в первый раз, в том числе и изучение интерфейсов навроде i2c, и не всегда под рукой бывает "фирменное руководство... с рисунком 27".

Позволю себе заметить, что чтение документации не отменялось. Ведь на форуме не могут же изложить все содержимое даташита на I2C. А порой даже прочтение его 50% дает ответы на многие вопросы.

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

После ответов в таком стиле обычно что самое хорошее, так это вообще не отвечать вопрошающему. Человек просит помощи, а потом говорит

лучше оставляйте свои размышления при себе... поэкономьте здоровье и время :-)

[defunct]

После ответов в таком стиле обычно что самое хорошее, так это вообще не отвечать вопрошающему. Человек просит помощи, а потом говорит

Я тоже было порывался выступить с негодованием!
Но потом понял что - тут все в порядке. Плюс с юмором ;>

Просто задайтесь вопросом как бы Вы искали некий tbuf на рисунке N27 "фирменного руководства"?

Позволю себе заметить, что чтение документации не отменялось.

Автор нигде не дал повода полагать обратное. С документацией по TWI модулю он ознакомился.
Возможно Вы удивитесь, но даже слова I2C в Atmel'овском даташите, например, на M16 Вы не найдете!!

Теперь представим гипотетическую ситуацию - не знакомы даже со словом "I2C", читаем док на AVR и находим, что TWI интерфейс как раз то, что надо для связи парочки МК. Пишем программу, но она работает нестабильно на высоких частотах. Приходим на форум, задаем вопрос по TWI (насколько можно настолько точно описав что делаем и как подключаем), а тут пишут - с места в карьер - а tbuf на рисунке фирменной документации I2C учел? Ну и... хоть стой, хоть падай - глобальный конфуз

[VladimirYU]

.... но даже слова I2C в Atmel'овском даташите, например, на M16 Вы не найдете!!

Теперь представим гипотетическую ситуацию - не знакомы даже со словом "I2C", читаем док на AVR и находим, что TWI интерфейс как раз то, что надо для связи парочки МК. Пишем программу, но она работает нестабильно на высоких частотах. Приходим на форум, задаем вопрос по TWI (насколько можно настолько точно описав что делаем и как подключаем), а тут пишут - с места в карьер - а tbuf на рисунке фирменной документации I2C учел? Ну и... хоть стой, хоть падай - глобальный конфуз

Может я пользуюсь, не "фирменной", а "левой" или устаревшей документацией, но на Fig. 27 не углядел никакого Tbuf. Поддерживаю подход defunct, не влом было бы присоеденить файлик или ссылку на "фирменную" документацию, а не надувать щеки.

Прикрепленные файлы

 I2C_BUS.pdf ( 279.86 килобайт ) Кол-во скачиваний: 81
 I2C_RP.PDF ( 267.43 килобайт ) Кол-во скачиваний: 64

 

[zoddy]

Может я пользуюсь, не "фирменной", а "левой" или устаревшей документацией, но на Fig. 27 не углядел никакого Tbuf. Поддерживаю подход defunct, не влом было бы присоеденить файлик или ссылку на "фирменную" документацию, а не надувать щеки.

Огромное спасибо за ссылочки на документацию! Вот это я понимаю, конструктивный подход!

А что касается моего ответа товарисчу Maik VS... ничего личного, но если уж даешь совет, то пиши конкретно и корректно, а не "важничай"... в конце концов, когда начинаешь что-то с нуля... даже имея документацию... можно отловить хороших граблей... поэтому не стоит смотреть свысока на людей, которые возможно заблуждаются и делают ошибки... людям вообще свойственно ошибаться... так что... как говорится:" Можешь- помоги, не можешь - не мешай!"

[haker_fox]

Огромное спасибо за ссылочки на документацию! Вот это я понимаю, конструктивный подход!

А что касается моего ответа товарисчу Maik VS... ничего личного, но если уж даешь совет, то пиши конкретно и корректно, а не "важничай"... в конце концов, когда начинаешь что-то с нуля... даже имея документацию... можно отловить хороших граблей... поэтому не стоит смотреть свысока на людей, которые возможно заблуждаются и делают ошибки... людям вообще свойственно ошибаться... так что... как говорится:" Можешь- помоги, не можешь - не мешай!"

А я в свою очередь осознаю, что был несправедлив, когда писал предыдущий пост!
zoddy, не держите зла, пожалуйста, и извините!

[Maik-vs]

Рад, что мой пост так оживил тему!
Собственно, мне нетрудно было дать и ссылку, и объяснить всё простыми словами. Но вот товарищ zoddy мне пишет: "Если Вы, многоуважаемый, хоть раз читали мануал ... " ну вот я и не стал напрягать не менее многоуважаемого, а если бы он хоть раз читал руководство по I2C ... ну, понятно. Вместо этого огребаю пост №10...
Кстати, VladimirVU, пресловутый Tbuf находится в I2C_BUS.pdf просто на раз, во многих местах. Хотя я предпочитаю пользоваться документацией от разработчика стандарта, есть такой документ UM10204 на сайте NXP.
Моему советчику Zoddy только могу процитировать его же, с небольшой поправкой: "ничего личного, но если уж даешь совет задаёшь вопрос, то пиши конкретно и корректно, а не "важничай"..."
Удачи всем.

[VladimirYU]

Рад, что мой пост так оживил тему!
Собственно, мне нетрудно было дать и ссылку, и объяснить всё простыми словами...
Кстати, VladimirVU, пресловутый Tbuf находится в I2C_BUS.pdf просто на раз, во многих местах. Хотя я предпочитаю пользоваться документацией от разработчика стандарта, есть такой документ UM10204 на сайте NXP.Удачи всем.

Да никто же с этим не спорит, это по поводу Tbuf. Речь ведь о другом, ссылаясь в посте на документ неплохо дать ссылку на него, или хотя бы дать информацию о том где и как его найти. Это, кстати, Вы сейчас и сделали. Мне, например, тоже интересно появились ли там изменения. Хотя не думаю, что NXP "родительское наследство" станет менять. Но жизнь не стоит на месте.
Взаимно, удачи всем.

[ReAl]

Автор нигде не дал повода полагать обратное. С документацией по TWI модулю он ознакомился.
...
Пишем программу, но она работает нестабильно на высоких частотах. Приходим на форум, задаем вопрос по TWI (насколько можно настолько точно описав что делаем и как подключаем), а тут пишут - с места в карьер - а tbuf на рисунке фирменной документации I2C учел? Ну и... хоть стой, хоть падай - глобальный конфуз

Я, как это часто бывает, позанудничаю.
С одной стороны оно так. А с другой...
Если "с документацией по TWI модулю ознакомился", то должен был видеть в ней параметр t_BUF "Bus free time between a STOP and START condition".
Раздел Electrical Characterisitcs, подраздел 2-wire Serial Interface Characteristics.
Для меги168 это таблица 28-5 на странице 309 и картинка 28-4 на следующей странице. (версия документа 2545M).

На мой взгляд, тема, поднятая не в "для начинающих", предполагает предарительное внимательное прочтение хотя бы "док на AVR". А уже потом "Плюс с юмором ;>" обижаться на то, что подсказали название параметра, который был в этой "док на AVR", но до него читалка недочитала.

[defunct]

Я, как это часто бывает, позанудничаю.
С одной стороны оно так. А с другой...
...
А уже потом "Плюс с юмором ;>" обижаться на то, что подсказали название параметра

Попытаюсь обратить Ваше внимание на то, что название параметра всплыло, к сожалению, только после того как вопрос был решен.
Если бы он всплыл "до".... А так, право же, нет повода для занудствования

который был в этой "док на AVR", но до него читалка недочитала

Резисторы решили проблему - значит автор учел упомянутый "Bus free time between a STOP and START condition" сразу, стало быть читалка дочитала?

[ReAl]

Резисторы решили проблему - значит автор учел упомянутый "Bus free time between a STOP and START condition" сразу, стало быть читалка дочитала?

Ах, извините, значит читалка недочитала про резисторы.
Что тоже довольно странно - на всех картинках номиналы не даны, так что можно было бы и задуматься - так какие же нужны?
И полезть в ту же таблицу, где про t_BUF и прочесть допустимые границы изменения сопротивления этих резисторов - минимум исходя из V_CC и допустимого тока, максимум - исходя из характерных времён для класса частоты шины и C_b - ёмкости шины.
Так чта... Извиниться могу только за неправильно указанное "до чего" читалка недочитала.

Впрочем, недочитывающие читалки достаточно распространены, часто именно про резисторы.

[defunct]

Что тоже довольно странно - на всех картинках номиналы не даны, так что можно было бы и задуматься - так какие же нужны?
И полезть в ту же таблицу, где про t_BUF и прочесть допустимые границы изменения сопротивления этих резисторов - минимум исходя из V_CC и допустимого тока, максимум - исходя из характерных времён для класса частоты шины и C_b - ёмкости шины.

Согласен, вопрос правильный. Но это уже (IMHO) не читалка, а думалка и опыт. Логика думалки ведь может быть и такой: раз не даны - значит любые.
А форум как раз и создан для того чтобы помогать направлять думалку в нужную сторону.

[ReAl]

Согласен, вопрос правильный. Но это уже (IMHO) не читалка, а думалка и опыт. Логика думалки ведь может быть и такой: раз не даны - значит любые.
А форум как раз и создан для того чтобы помогать направлять думалку в нужную сторону.

Так даны! В таблицах допустимых параметров, причём даже в том же документе, а не в отдельном. Только читалка таки недочитала до того места, потому думалка и думает, что не даны.
О том же и я толкую - надо направлять в нужную сторону. Только читалку перед думалкой. Или думалку учить сначала пинать свою читалку. Иначе думалка скоро начнёт думать, что номиналы резисторов и всё такое прочее - это из области чёрной магии и прочего тайного знания, читать документацию внимательно и всю нет смысла, всё равно ответ может быть только от посвящённых, имеющих другие источники знаний.
Либо просто читалка заявит думалке "а нафига читать, проще на форуме спросить" - так тогда и думалка атрофируется, только другой дорогой.

(сейчас уже поутихло, а лет пять-семь назад мне сравнительо часто приходили письма с просьбой выслать те документы, по которым я присал avreal - так вот это начинается с вот таких резисторов)

[DS]

Господа знатоки ATMeg !

Есть ли способ вывести из зависа slave TWI atmega48 ?

Симптом такой - вдруг на SLA+W выдает NACK, потом SDA (или оба сигнала) залипает в 0. Импульсы по SCL не помогают - SDA переходит в 1, но после включения мастера SCL снова сваливается в 0 - сразу. Мастер не виноват - если slave сбросить, работа восстанавливается.

Cама 48 продолжает работать во время зависа, просто не видит аварии на порту - нет прерывания.

Причина повисания - spike на шине. Установлено почти достоверно.

Есть ли возможность изнутри 48 выяснить факт аварии на шине, и что-нибудь сделать ? Снаружи, как я понимаю, ничего ее не проймет.

[defunct]

Есть ли способ вывести из зависа slave TWI atmega48 ?

Сбросить TWI модуль:
TWCR = (1 << TWINT);

и заново инициализировать через некоторое время (сам инициализирую через 1ms после сброса).

Есть ли возможность изнутри 48 выяснить факт аварии на шине, и что-нибудь сделать ?

Должно было быть прерывание со статусом 0.
Но если его действительно нет, можно привязаться к таймауту.

[DS]

Сбросить TWI модуль:

TWCR = (1 << TWINT);


Должно было быть прерывание со статусом 0.
Но если его действительно нет, можно привязаться к таймауту.

Чтобы сбросить, надо узнать, что есть проблема. А прерывание не вырабатывается, я так и этак проверял, похоже статус остается F8. Таймаут не от чего отсчитывать - он же не реагирует на SLA+W, соответственно, не знает, что к нему обратились.
Разве что мониторить состояния пинов, но тут тоже возникает сложность - а если мастер просто шину для себя придержал ?

[defunct]

Таймаут не от чего отсчитывать - он же не реагирует на SLA+W, соответственно, не знает, что к нему обратились.

Таймаут можно считать от последнего прерывания, и от инициализации TWI.

а если мастер просто шину для себя придержал ?

то сброс TWI модуля этого slave никак не повлияет на текущую транзакцию к другому slave'у.

[DS]

Таймаут можно считать от последнего прерывания, и от инициализации TWI.

А как узнать, что интерфейс в раскоряченном состоянии ? Обращения непереодичные, поэтому понять внутри 48, что он начал пропускать что-то, нет возможности.

[defunct]

А как узнать, что интерфейс в раскоряченном состоянии ? Обращения непереодичные, поэтому понять внутри 48, что он начал пропускать что-то, нет возможности.

В случае если нет прерывания со статусом 0 - "сбой шины" - никак , кроме монитора линии через GPIO..
На шине один slave или несколько? Есть возможность к этому слейву протянуть от мастера еще один провод?
Периодически отключать/включать модуль (с поправкой на текущую транзакцию) не пойдет?

[DS]

В случае если нет прерывания со статусом 0 - "сбой шины" - никак , кроме монитора линии через GPIO..
На шине один slave или несколько? Есть возможность к этому слейву протянуть от мастера еще один провод?
Периодически отключать/включать модуль (с поправкой на текущую транзакцию) не пойдет?

Не ждали мы такого скотства от Atmel.
Лишний провод не годится, а про переодический перезапуск при неправильном состоянии шины буду думать.

[singlskv]

Господа знатоки ATMeg !

Есть ли способ вывести из зависа slave TWI atmega48 ?

Симптом такой - вдруг на SLA+W выдает NACK, потом SDA (или оба сигнала) залипает в 0. Импульсы по SCL не помогают - SDA переходит в 1, но после включения мастера SCL снова сваливается в 0 - сразу. Мастер не виноват - если slave сбросить, работа восстанавливается.

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

[DS]

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

Вот так повисает. Мастер - mega128.
С прерыванием и прочим все нормально - проблема именно в становлении раком модуля в 48.

На первой - нормальный цикл. На последней картинке - попытка recovery.

Эскизы прикрепленных изображений

 

[singlskv]

Вот так повисает. Мастер - mega128.
С прерыванием и прочим все нормально - проблема именно в становлении раком модуля в 48.

На первой - нормальный цикл. На последней картинке - попытка recovery.

Картинки странные конечно,
но если бы слейв подвисал с удержанием SCL то на последней картинке (попытка recovery)
тактирования не было бы совсем, а оно там есть...
так что еще не факт что слейв SCL держит

не видя Ваш код могу только предложить добавить на слейве если чего не хватает:

Код

  BYTE twsr=TWSR & 0xF8;              // Статус с учетом маски допустимых состояний

  switch (twsr)                // Разбор состояний i2c
  {
..............  <-- обрабатываемые состояния
..............
..............
    case (I2C_BUS_ERROR):              // 0x00 ---- ошибка на шине ------------
      TWCR;
      TWCR=(1<<TWINT)|(1<<TWSTO)|(1<<TWEA)|(1<<TWEN);
      return;

    case (I2C_RECV_ARB_LOST_ADR_ACK):  // 0x68 ---- Arbitration lost & General Calls
    case (I2C_RECV_GC_ADR_ACK):        // 0x70
    case (I2C_RECV_ARB_LOST_GC_ADR_ACK)://0x78
    case (I2C_RECV_GC_DATA_ACK):       // 0x90
      TWCR;
      TWCR=(1<<TWINT)|(1<<TWEN);       // отвечаем NAK
      return;

    case (I2C_RECV_DATA_STOP):         // 0xA0 ---- конец приема --------------

    case (I2C_RECV_DATA_NACK):         // 0x88 ---- если отвечали NAK ---------
    case (I2C_RECV_GC_DATA_NACK):      // 0x98

    case (I2C_SEND_DATA_NACK):         // 0xC0 ---- конец передачи пакета -----
    case (I2C_SEND_LAST_DATA_ACK):     // 0xC8

    default:                           // недопустимое состояние
      TWCR;
      TWCR=(1<<TWINT)|(1<<TWEA)|(1<<TWEN);

  }

[DS]

Картинки странные конечно,
но если бы слейв подвисал с удержанием SCL то на последней картинке (попытка recovery)
тактирования не было бы совсем, а оно там есть...
так что еще не факт что слейв SCL держит

не видя Ваш код могу только предложить добавить на слейве если чего не хватает:

Слэйв держит, но выходы ATmeg имеют ограничение по току в режиме TWI, поэтому нога в стандартном режиме его перебарывает. Как только выход переходит в 3 состояние, "слабый" выход устанавливает шину в 0. Если отключить разъем от модуля, шина оживает.
В тиньке, кстати, ограничения по току нет, там такое КЗ на осциллограмме хорошо видно.

В обработчике, если что-то происходит не в очередь, или статус не соответствует ожидаемому, сразу выполняется STOP. Хотя, конечно, вариант "сам дурак" не исключен, только не из-за того, что забыли какие-то состояния обработать, а из-за какой-то более хитрой программной ошибки.

[singlskv]

Слэйв держит, но выходы ATmeg имеют ограничение по току в режиме TWI, поэтому нога в стандартном режиме его перебарывает. Как только выход переходит в 3 состояние, "слабый" выход устанавливает шину в 0. Если отключить разъем от модуля, шина оживает.

У меня были сомнения по картине N3 что там перетягивание на шине, но какое-то слабое перетягивание...

Но если нет сомнения что держит слейв, то нужно все-таки по состояниям twi разбираться.

Код

В обработчике, если что-то происходит не в очередь, или статус не соответствует ожидаемому, сразу выполняется STOP. Хотя, конечно, вариант "сам дурак" не исключен, только не в лоб, а из-за какой-то более хитрой программной ошибки.

STOP нужен только если пришло состояние I2C_BUS_ERROR

я на своей реализации проверял закороткой SCL и SDA, все восстанавливалось.

STOP в смысле TWCR=(1<<TWINT)|(1<<TWSTO)|(1<<TWEA)|(1<<TWEN); конечно

[DS]

А не может ли вызывать завис изменение режима SPI в момент работы модуля TWI ? Я обнаружил, что после изменения режима SPI первый байт передается рваным - сначала 4 или 5 бит, потом пауза различной длины, потом оставшиеся 3 бита. Я хотел попользоваться изменением скорости SPI "на лету", да видать нельзя. Только вот в datasheet не нашел ничего про такое ограничение. Может, невнимательно смотрел ?

После того, как я перестал трогать SPCR, перестал виснуть TWI (т.е. пока не повис за тот промежуток времени, за который раньше вис с гарантией).

[defunct]

А не может ли вызывать завис изменение режима SPI в момент работы модуля TWI ?

Не должно, но если наблюдается корреляция между изменением режима SPI и подвисанием TWI, то причина может быть в несвоевременной реакции на TWI прерывание.

[DS]

Не должно, но если наблюдается корреляция между изменением режима SPI и подвисанием TWI, то причина может быть в несвоевременной реакции на TWI прерывание.

Да похоже, что именно с совпадением во времени промежутка между out spcr и out spdr и приходом пакета на TWI.

Где-нибудь в документации отражено, что первый байт, переданный по SPI после смены режима, искажается ? Я не нашел. А это факт, я на осциллографе это пронаблюдал и экспериментировал, как и что меняется при разных сменах режима.

Несвоевременную реакцию я тоже моделировал задержками до секунд, и в начале, и в середине пакета - не сбивается.

Сейчас работает без сбоев - отличие только в отсутствии команд out spcr в программе. Реакция на TWI даже несколько замедлилась - раньше я переключал spi между 2.5 Мгц и 10 Мгц, что позволяло сэкономить время,на которое прерывания необходимо запрещать.

[DS]

Вот код, который вызывает неадекватное поведение 48

Код

        ldi r31, $2e
        out ddrb,r31            
        ldi r31,$14
        out portb,r31
        ldi r31, $f
        out ddrc, r31
        ldi r31, $0
        out portc, r31
        ldi r31, $b
        out ddrd,r31            
        ldi r31,$fb
        out portd,r31

        ldi r25, 1
        out SPSR, r25

        ldi r25, $50
bbb:         out spcr, r25
        cbi portd, 3
        out SPDR, r25
        nop
        nop
        nop
        nop
        nop
        nop
        nop
        nop

        nop
        nop


        in r1, SPSR
        sbi portd, 3

clr r16
bb: dec r16
brne bb
        rjmp bbb

А вот осциллограммы - синий - PD3, желтый - PB5 (SCK).

Дергать именно PD3 - важно, при замене на что-нибудь другое все нормально работает. Важна также задержка от записи SPDR до чтения SPSR и минимальная длительность после чтения SPSR - при загрузке в r16 числа, меньшего 64, сбоев нет.
Частота такта 20 Мгц. Кадры на осциллографе сняты в произвольный момент времени - форма сбоев непостоянна.


Какие будут комментарии ?

Эскизы прикрепленных изображений

 

[DS]

Блин, классическое "сам дурак" - Наводки в шлейфике программирования от AVreal (15 cм) на тактовый генератор, приводящие к его сбою. Для получения нужной для сбоя амлитуды как раз не хватало в момент переключения SPI дергануть ногой PD3, расположенной рядышком с выводами генератора.

Так и рождаются нездоровые сенсации.

[SasaVitebsk]

Так и рождаются нездоровые сенсации.

Так попало в благодатную почву.

Здесь уже несколько раз проскакивали сообщения про "зависания" TWI в слэйве.

У меня, к примеру, всё прекрасно работает, причём годами, причём паралельно 24c512 сидят и обмен идёт очень плотный. Правда скорость не очень высокая.

Отличный интерфейс выдумали филипы.