Зависание TWI в atmega48

winso · 08.12.2010, 00:30

Реализовал в Си аппноты по twi - AVR311 и AVR315
Задача - адресный обмен мастера с кучей адресуемых слейвов. Куча - это штук 20. Отлаживается пока на atmega48-20PU на встроенном генераторе, на 1Мгц, 3.3в. На 5 в кстати тоже самое наблюдается.
Подтяжка линии 1к.
Отлаживается на дип корпусе - потому как на макетную плату проще напихать их.

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

Наблюдается такая фигня - если искуственно внести проблему на линию - то есть тупо коротнуть SCL-SDA, обмен в дальнейшем периодически виснет.

цикл ожидания аппнота
while ( TWI_Transceiver_Busy() );
заменен на цикл с таймаутом
void TWI_WAIT(void)
{
unsigned char delay=0;
while ( TWI_Transceiver_Busy() && (delay‹200))
{
delay++;
delay_us(20);
}
}

Без таймаута сам мастер наглухо вис или слетал по ватчдогу. Теперь всегда работает.

Но. Нарушается связь между блоками. То есть с вероятностью 15% после снятия проблем с шины - обмен не восстанавливается. Решение - только последовательный ресет всех процессоров в связке, пока линию не отпустит и процесс не возобновится. (ну или выключение-включение всей схемы)
Стенд отлаживается на простейшей программке. На мастере крутится ряд диодов, их показания передаются на слейвы, они их повторяют. То есть видно - на мастере мигают, на слейвах повторяются. 20 миганий на 1-м слейве, 20-на другом и так далее.
Коротнул шину - картинка на слейвах встала. Отпустил - снова побежали. Но иногда перестают бежать. И намертво.

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

Я про TWI обсуждение ранее видел, но не увидел решения.
шо делать?
Может ли данная проблема уйти сама если пустить на обновленных atmega48pa?

Cybermaker · 08.12.2010, 01:28

Сообщение от winso

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

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

Сообщение от winso

Как сделать, чтобы обмен восстанавливался гарантированно?

Напишите софтово. Не такой уж сложный интерфейс.

winso · 08.12.2010, 03:01

Сообщение от Cybermaker

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

Напишите софтово. Не такой уж сложный интерфейс.

Хм... Написать I2C софтовый несложно. Но вот в чем вопрос - а нахуа тогда аппаратный встроенный?
Я чувствую - придется дописывать что то типа "если связь была, а потом пропала - ждем секунды 2, а потом ресетимся" - и так в каждом блоке...
И про промежуточные буферы... А поможет? Ведь вопрос в том - что из за некого глюка на шине шина иногда виснет. И это иногда достижимо даже в обозримых временем интервалах - раз 5 дернул шину помехами - взяла и повисла...

Cybermaker · 08.12.2010, 03:14

Ну TWI он же I2C, он же Inter IC Communication никогда не разрабатывался как интерфейс для сопряжения устройств за пределами одной платы. Понятно что помехозащищенность у него - никакая. Виснет у вас скорее всего на моменте ожидания Start или Stop Condition.

Сообщение от winso

И про промежуточные буферы... А поможет?

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

По предъявляемым вами требованиям интерфейс выбран не совсем удачно.

winso · 08.12.2010, 03:32

Сообщение от Cybermaker

Ну TWI он же I2C, он же Inter IC Communication никогда не разрабатывался как интерфейс для сопряжения устройств за пределами одной платы. Понятно что помехозащищенность у него - никакая. Виснет у вас скорее всего на моменте ожидания Start или Stop Condition.

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

По предъявляемым вами требованиям интерфейс выбран не совсем удачно.

Ок - варианты интерфейса?
Основное требование - общая шина, адресное обращение к блокам + "general call" - всем сразу.
Скорость обмена практически не важна - весь обмен - одно-двухбайтовые команды управления, блок возвращает одно - двухбайтовые статусные сообщения. Блоков - до 40. Горячая замена на самом деле не так важна - от нее можно отказаться, но! Связь с блоками должна поддерживаться очень надежно и восстанавливаться в случае сбоев за доли секунды. расстояние до блоков - 30-50 см. Разводка шины - по печатной плате, то есть без лишней экранировки.
Интерфейс выбирался из того что доступно в АВР. Плюс еще звучало достаточно заманчиво возможность вывода процессора из сна по адресному запросу TWI. У меня аккумуляторные задачи, и энергию приходится экономить.
Мое "тыканье в шину" - это искуственное создание аварийной ситуации, система должна отрабатывать и в этих условиях. Видеть ошибку, как ошибка ушла - самовосстанавливаться.
Принцип работы - при старте мастер опрашивает весь диапазон адресов, какие откликаются - вносит в таблицу и в дальнейшем ведет с ними двусторонний обмен. Адрес блока задается автоматически - установкой блока в определенный слот (формируется на коннекторе фиксированными перемычками). Изначально все блоки абсолютно одинаковы, адрес получают после установки в слот.

Cybermaker · 08.12.2010, 03:55

Ну если длинна не больше полуметра, то действительно хватит и I2C. Извините, подумал что задача связать разнесенные блоки. Реализуйте протокол программно.

Еще вариант - реализовать 1-wire. Там с ошибками попроще будет.

Сообщение от winso

Плюс еще звучало достаточно заманчиво возможность вывода процессора из сна по адресному запросу TWI

Врядли будет работать корректно. Особенно с возможными ошибками на шине.

niXto · 08.12.2010, 08:56

Используйте ЮСАРТ а еще лучше RS485

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

winso · 08.12.2010, 09:18

Сообщение от niXto

Используйте ЮСАРТ а еще лучше RS485

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

реализовывать самому адресность и так далее... на юсарте то... И опять же - программно. Данная реализация выписана на атмега 48, на самом деле это я алгоритмы вылизываю, конечная точка - атмега644па мастер, атмеги 48 ведомые. А на атмеге 644 оба аппаратных уарта используются. один на обмен с писи, второй на обмен с внешней длинной периферией по 485. там в частности адресность то и реализована. Но попроще.
Да и программно выписывать все на 48... места не хватит, там еще другого кода хватает. А на 88 или 168 переходить пока не хочется.
И про задержки. Везде где есть бесконечные циклы ожидания while - введен счетчик циклов - таймаут. Программа то крутится нормально. Виснет сам аппаратный TWI. В нем где задержку то поставить? Только и остается похоже ресетится.

winso · 08.12.2010, 09:30

Сообщение от Cybermaker

Ну если длинна не больше полуметра, то действительно хватит и I2C. Извините, подумал что задача связать разнесенные блоки. Реализуйте протокол программно.

Еще вариант - реализовать 1-wire. Там с ошибками попроще будет.

Врядли будет работать корректно. Особенно с возможными ошибками на шине.

Задача - иметь возможность локально набить в устройство определенное количество исполнительных блоков и иметь возможность общаться с ними отдельно. Притом сделать это так, что - проснулся процессор - о, да у меня 15 блоков, щас мы их... А в другой раз проснулся - хм, 25, ну и их тоже... Он опрашивает каждый блок примерно раз в секунду, типа - как ты там, жив, здоров? Здоров - ок, нездоров - а что можно с тобой сделать, ничего? - ну, тогда отключим его, сообщим куда надо, а с остальными поработаем. И в определенный момент времени выдаем на все сразу определенную команду - чтобы все отработали как один, а уже потом можно вяло опросить каждый - ну как ты там, отработал?
Несущая частота - 25 кгц, никаких 400 мне не нужно

Ошибки на шине - еще раз. шина как раз чистая. Но я моделирую ситуацию - а вдруг возникнут. Блок например один рыпнется. Сотовый рядом заработает. Или еще что. И тогда моя замечательная связка блоков просто развалится в воздухе, и некому будет прийти ее развесить, а работать то нужно, а некому.

winso · 08.12.2010, 11:11

Сообщение от Cybermaker

Еще вариант - реализовать 1-wire. Там с ошибками попроще будет.

Внимательно посмотрел 1-вир. Не, слишком тяжелый для камня протокол. Я специально живу на 1Мгц для экономии энергии, а на этой частоте если 1-вирь делать - вообще это маловероятно во первых и больше ничем не сможет процессор заняться во вторых, ИМХО.
Так что не вариант