roboforum.ru

После некоторого опыта работы с контроллерами AVR встала задача объединять эти контроллеры в группы, т.к. зачастую несколько блоков устройства собраны на разных контроллерах.

Было принято решение объединять контроллеры через интерфейс UART.

Итак, задача:
1. Выработать методику объединения нескольких контроллеров одну систему, при этом разработав некое универсальное типовое решение.
2. Обеспечить по возможности максимальную нагрузку на контроллеры, с целью повышения быстродействия.

Первое, что приходит в голову - это общая шина. Тоже вариант...
Принцип работы очень прост, например мы с главного компьютера передаем команду в которой содержится идентификатор устройства назначения. Все контроллеры приняв команду смотрят, если команда адресована ему, то выполняет и посылает ответ. Схема выглядит действительно просто.
Приведем некоторые недостатки этой схемы:
1. В решении задачи задействован только один контроллер. Это происходит из-за невозможности делить линию передачи данных от контроллеров - к управляющей ЭВМ.
2. Даже при введении некой системы избежания коллизий в лини передачи данных, то мы никуда не деваемся от необходимости каждым контроллером анализировать _все_ принятые команды, в т.ч. адресованные к другому контроллеру.

Таким образом я делаю вывод о необходимости устройства коммутации и распределения команд.
Могу предложить следующую схему (я не уверен в правомерности установки диодов).

Кратко опишу как это должно работать. Рассморим пару Блок Управления (БУ) и Периферийное Устройство (ПУ).
Как видно из схемы, БУ может воздействовать на ПУ внешним прерыванием INT0, а также переключать свою линию передачи данных между внутренним, и внешним "сегментом сети" (для этого стоят транзисторы).
Теперь рассмотрим, как это должно работать....

Работа БУ:
1. Получить команду (или группу команд) от Главной ЭВМ (ГЭВМ)
2. Разбирая команду(ы) определить адресата(ов) и составить их список.
3. Переключиться во внутренний сегмент.
4. Установить INT0 ПУ адресата в 1. (Реакцию ПУ смотри ниже)
5. Передать команду для ПУ.
6. Проделать п.4 и п.5 со всеми адресатами, если их несколько.
7 Переключиться во внешний сегмент.
8. Установить INT0 ПУ адресата в 0. (Реакцию ПУ смотри ниже)
9. Получить ответ, или сигнал "не готов".
10. Если "не готов", то тогда установить INT0 ПУ адресата в 1(Реакцию ПУ смотри ниже) и переходим к п.8 сменив адресата на следующего из списка если их несколько.
11. Если  "готов", то тогда вычеркнуть этого адресата из списка, запомнить ответ и перейти к п.8 сменив адресата на следующего из списка если их несколько, а если адресатов больше нет, то тогда сформировать ответ(ы).
12. Отправить ответы на ГЭВМ.

Работа ПУ (реакция на INT0):
-при появлении 1:
1. Если "не готов", то выйти.
2. Включить UART.
3. Считать команду.
4. Выключить UART.
5. Отправить команду на выполнение.
-при появлении 0:
1. Включить UART.
2. Если "не готов", то  тогда сообщить об этом.
3. Если "готов" то отправить ответ.
4. Выключть UART.

Вот те достоинства которые увидел я:
1. Мы по возможности решаем нашу задачку, дав возможность контроллерам работать больше времени, чем принимать команды..
2. На основе этого блока можно сделать систему индикации робота, состояния его устройств.

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

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

В файлике - схемка + текст.
ВНИМАНИЕ! В схеме ошибка, у двух самых правх транзисторов нужно коллектор и эмиттер поменять местами.

Давайте думать.
1. Программная реализация это конечно хорошо, но это забивает и без того маленькую память маленького контроллера (ведь их обычно вешают на периферию)
2. Я не видел этих реализаций, но, могу предположить, что там идет постоянный опрос каких-либо ног, а это драгоценное процессорное время. (Нет, нет я не из тех маньяков которые считают каждый такт =) )

Хочу задать вопрос, каким образом в этих протоколах борятся с коллизиями в линиях? С попытками одновременной передачи? С помехами наконец? А ведь у UART есть "похехо-фильтр".

В своей конструкции решил ничего не менять т.к. у меня уже есть один из модулей и работает он через RS232.
Вот в "железе" что у меня получается (ПО еще не дописано).
Нужно сказать, что у меня есть еще один модуль (готов полностью), который и стоит на роботе в данный момент, он тоже будет подключен к системе.

Digit писал(а):В МК AVR i2c этот протокол реализован на железном уровне...

Интересная мысль ... Народ, кто имеет информацию по поводу соответствия интерфейса последовательного программирования SPI в контроллерах AVR стандарту i2c ???

Объясняю почему именно RS232. Просто у меня есть готовый модуль который и работает с RS232. Против i2c ничего не имею, разве что, для связи с компьютером лучше все-таки RS232 =)

Виталий писал(а):Против i2c ничего не имею, разве что, для связи с компьютером лучше все-таки RS232 =)

Кстати, народ делает переходнички для COM-порта и есть библиотеки. Подключаешь шину i2c через переходничок к компу, а софт пишешь с помощью библиотеки, реализующей i2c через COM-порт. Вот и все дела... Тоже классная штука!

Виталий писал(а):Про Линукс: Надо начинать дружить...

Да я и рад бы... Чувствую, подружусь сним скоро, коли не найду под винду информации.
А про радиоканал - полностью поддерживаю. Для такого варианта реализации связь PC <-> робот лучше по RS232. Но зачем применять его "внутри" робота? Или для единообразия? (кстати, тоже немаловажный момент)

Digit писал(а):Я почему так уверенно про TWI говорю...
У меня та же задача, что и у Виталия стоит. Мне надо объединить несколько "интеллектуальных серв" (самодельные сервы с МК ATtiny26) в единое целое так, чтоб и управлять ими можно было в широких пределах и обратную связь иметь.... и иметь возможность потом еще фичи прикручивать, если понадобится (что по-умному называется масштабируемость ).  Собственно ATtiny26 выбирался именно из-за наличия i2c, PWM и достаточного числа выводов.

Боюсь вас разочаровать но в ATtiny26 нет интерфейса TWI из всего модельного ряда AVR он имеется лишь у следующих контроллеров:

ATmega128
ATmega128L
ATmega16L
ATmega8535L
ATmega16
ATmega32
ATmega32L
ATmega64
ATmega64L
ATmega8535
ATmega8L
ATmega8
ATmega645
ATmega3250
ATmega6450
ATmega168
ATmega165
ATmega165V
ATmega325
ATmega48
ATmega88

Это ещё один + в пользу rs232

P.S. по данным производителя, информация взята здесь