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. На основе этого блока можно сделать систему индикации робота, состояния его устройств.

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

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

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

Так теперь давайте думать все вместе.

имеет ли смысл применять интерфейс rs232 меж контроллерами.
или  может остановить свой выбор над программно реализованными i2c , dallas 1wire , twi ...

в данной схеме мы получаем единую шину с сигналом выборки кристалла, итого 3 провода ( -3 ноги).

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

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

Немного подумав, пришел к некоторым выводам:
1. Связь коммутатора и ГЭВМ следует производить по протоколу RS232 т.к. на его основе легче построить радиоканал.
2. Возможно использование I2C внутри коммутатора (возможно это даже лучше).

Когда разберусь с I2C скажу, сможем ли мы убрать третий синхронизирующий провод....
Хотя может вы мне в этом подскажете

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

А чем не нравится шина i2c без всяких примочек? Ведь i2c поддерживает и адресацию, и разрешение конфликтов, на шине может быть несколько мастеров и ведомых... В МК AVR i2c этот протокол реализован на железном уровне...
Или я что-то не понял?

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

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

setar, все немножко не так! SPI - это SPI (т.е. там три провода и все такое). Там свой протокол, про который не могу ничего конкретного сказать.
А у AVR i2c есть ни что иное как TWI (Two Wire Interface). Почему они так обозвали i2c - я не знаю. Может, чтоб лицензионные дела с Philips'ом не решать?  :roll:  Но то, что TWI и I2C - близнецы-братья, вернее даже одинаковы, как оригинал и отражение, - это однозначно!
Посему, не заморачивайтесь и используйте AVR! (не сочтите за рекламу  :) )
Насколько я знаю, чипы AVR и дресацию по i2c поддерживают... причем и расширенную (10bit) тоже.
Единственное, что может мешать - скорость передачи данных... По шине i2c много не передашь. А вот управляющие последовательности - это легко!

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

Я почему так уверенно про TWI говорю...
У меня та же задача, что и у Виталия стоит. Мне надо объединить несколько "интеллектуальных серв" (самодельные сервы с МК ATtiny26) в единое целое так, чтоб и управлять ими можно было в широких пределах и обратную связь иметь.... и иметь возможность потом еще фичи прикручивать, если понадобится (что по-умному называется масштабируемость ).  Собственно ATtiny26 выбирался именно из-за наличия i2c, PWM и достаточного числа выводов.
Только до реализации пока не дошел... Ведь всем этим добром должен рулить кто-то главный... Хочу строить все на базе PC (via epia-m). Там можно подрубиться к SMBus, которая является частным случаем i2c. Но только у меня сейчас затык: не знаю как из-под винды на C++ к девайсам на этой шине висящим обратиться... В нете много чего нашел, но там все из-под линукса, с которым я как-то не дружу...
Кстати, у меня предложение есть: давайте обсудим, каким кому видится общение наших "умных устройств" по i2c?
Например, есть шина i2c, на которой сидят:
главный мозг (ГМ), управляющий всем добром на высоком уровне;
левое колесо (ЛК), точнее управляемый по i2c блок вращения колеса;
правое колесо (ПК), - аналогичная штука;
три ИК-датчика (ИК1, ИК2, ИК3), - тоже блоки со связью по i2c
...ну и так далее.
Каков будет протокол обмена служебной и управляющей информацией по шине?

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

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

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

Я немного про другой аспект...
Имхо конечно, но построить радоканал между компьютером и роботом проще через RS232 из-за большей его "аналоговости", а точнее из-за того, что там нет отдельной синхронизирующей линии.

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

Надо начинать дружить...

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

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

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

Дело в том, что у меня есть один модуль, он налажен и работает через 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. по данным производителя, информация взята здесь