Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры Atmega AVR
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.62/50: Рейтинг темы: голосов - 50, средняя оценка - 4.62
otkymoy
0 / 0 / 0
Регистрация: 26.05.2011
Сообщений: 15
1

Сеть контроллеров

30.05.2011, 00:04. Просмотров 9063. Ответов 25
Метки нет (Все метки)

Всем трям.
Есть такой вопрос.
Есть несколько устройств и блок управления. Везде используются АВР (мега). На данный момент данные между устройствами и пультом управления передаются в виде дискретных сигналов, каждый по своему проводу. Стоит задача наладить информационный обмен.
Сразу о требованиях. Скорости будут невысокие, до 1200 бод. Топология - звезда (каждое устройство работает в опасных условиях и может быть потеряно вместе с кабелем, то есть шина не подходит). Количество устройств - до 8. Режим работы - запрос-ответ (команда-ответ), ведет блок управления. Команды-ответы многобайтовые (до 5).

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

Какие варианты рассматриваю:
1. Програмный UART. Хорош тем, что можно навешать сколько угодно устройств. Не нравится сложностью реализации и загрузкой контроллера блока управления.
2. Коммутация одного UART в блоке управления на разные устройства. Подключил одно устройства, послал запрос, дождался ответа, подключился к другому. Из минусов - пока невнятно себе представляю арбитраж по времени - например, запрос послал, а пришла только часть ответа. Или не пришло вообще ничего. Или поймал кусок старого ответа....
3. Смотрел в сторону Хмеги - но пока не готов ее осваивать.

Может кто что еще подсказать может?
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
30.05.2011, 00:04
Ответы с готовыми решениями:

MP9011 Программирование контроллеров
У меня проблема не могу прошить не один контроллер с помощью MP9011 соединяю...

Синхронизация двух контроллеров.
Здравствуйте. Возникла необходимость синхронизировать два контроллера с...

Связь двух контроллеров по SPI.
у меня есть драйвер на Miko168. мне понадобилось связать две платы вместе. из...

Совместимость архитектур мобильных контроллеров и AVR
Здравствуйте! Хотел бы спросить - похожи ли архитектуры тех микропроцессоров,...

Смена прошивки AVR контроллеров с Андроид устройств по BT
Привет, хлопцы! Кто нибудь видел бутлоадеры, умеющие работать с софтом,...

25
dsodir
0 / 0 / 0
Регистрация: 28.09.2010
Сообщений: 4,284
30.05.2011, 00:22 2
В некоторых AVR в UART есть режим Multi-processor Communication Mode.
Вот: http://we.iosyitistromyss.ru/AVR/vremya ... -mode.html
0
otkymoy
0 / 0 / 0
Регистрация: 26.05.2011
Сообщений: 15
30.05.2011, 00:26 3
спасибо, почитаю. пока только не понимаю физического соединения - разослать всем слушателям от одного вещателя можно, а вот как собрать ответы от кучи слушателей в один порт вещателя? Если тут речь идет про шину - увы, не подходит мне....
0
Bokris
0 / 0 / 0
Регистрация: 27.08.2010
Сообщений: 77
30.05.2011, 00:56 4
RS485 + напиши свой протокол.
Что-то типа:
Ведущий: "1".
Все ведомые приняли.
Ведомый1: "1".
Ведущий: "100".
Ведомый1: "5 твоих байт".

Ведущий: "2".
Все ведомые приняли.
Ведомый2: "2".
Ведущий: "100".
Ведомый2: "5 твоих байт".

И т.д.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
30.05.2011, 01:09 5
Звезда - это расположение проводов. Внутри вполне может быть и шина. Просто шина сходится в одну точку ))

Если потеря устройства - это гарантированно обрыв, то хоть тот же УАРТ использовать - все ТХ звездой на RX и наоборот.
0
otkymoy
0 / 0 / 0
Регистрация: 26.05.2011
Сообщений: 15
30.05.2011, 01:42 6
Цитата Сообщение от Stiit.mi
Звезда - это расположение проводов. Внутри вполне может быть и шина. Просто шина сходится в одну точку ))
Если потеря устройства - это гарантированно обрыв, то хоть тот же УАРТ использовать - все ТХ звездой на RX и наоборот.
потеря устройства - это может быть все, что угодно: обрыв, кз, какое то сопротивление между парами, между сигналом и землей, питание. Все что угодно. Устройство зажарилось и ведет себя неадекватно. Вот только передачи хаотичной быть не может :)
А звезда. Звезда - это топология, а не расположение проводников. Я бы тоже сделал шину, если бы не потеря устройств, которая весьма весьма велика и не должна сказаться на работе других устройств... Так что должна быть возможность именно раздельного, изолированного приема и передачи.

Multi-processor Communication Mode очень хорошо подходит для общения с устройствами в направлении от модуля управления. Вот теперь что придумать для обратного?
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
30.05.2011, 02:01 7
Для обратного все точно так же. Там выше Bokris написал.

Центральное устройство (ЦУ) посылает команду - раб №2, не спать
раб №2 (Р2): не сплю
ЦУ: лови пакет
Р2: поймал
ЦУ: ниче в ответ сказать не хочешь?
Р2: неа, отбой

ЦУ: раб №3, не спать
Р3: не сплю
ЦУ: пакета тебе нет, обломись
Р3: понял
ЦУ: сказать ниче не хочешь?
Р3: хочу и говорю
ЦУ: понял, отбой
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
30.05.2011, 02:15 8
Цитата Сообщение от otkymoy
А звезда. Звезда - это топология, а не расположение проводников.
топология чего? Надо уточнять уровни абстракции )
Ну а по большому счету, если требуется настолько изолировать устройства друг от друга, то кроме мультиплексора по входу и драйвера по выходу ничего в голову и не приходит. Ну и развязка оптронами, есессно.
0
vostomy
0 / 0 / 0
Регистрация: 11.02.2011
Сообщений: 187
30.05.2011, 09:10 9
Цитата Сообщение от otkymoy
Может кто что еще подсказать может?
может, конечно, только все зависит от тебя и твоих способностей в плане опыта и я бы сказал анализа твоего ТЗ!
Если не пугает "свое решение" и "свой протокол заточенный ПОД ЗАДАЧУ", рекомендую хорошенько перечитать и вдуматься в мои посты ТУТ дабы не дублировать здесь идейный подход, логику и решение проблем...
Все что изложено там реально пройдено практически и работатет включая исходники
0
drvtos
1 / 1 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
30.05.2011, 09:48 10
Цитата Сообщение от otkymoy
Так что должна быть возможность именно раздельного, изолированного приема и передачи.
У тебя действительно немного смешано в кучу - физический и логический протокол. Давай сначала про ТЗ.

1) Хочешь ли ты однозначно, чтобы любое (разумное) повреждение линии связи с Девайсом 1 не сказалось на работе с Девайсом 2? Например, к.з. на линии связи с Д1 - это жопа для работы на этой физической линии. Так? Это ты имеешь в виду, когда пишешь "не-не, только не шина"?

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

2) Теперь о лирике работе контроллера с N каналами. У нас нет сколько последовательных портов в одном МК. Так? Значит, должна быть коммутация. Просто на аппаратном уровне. Как - вопрос другой. Сначала давай убедимся, что я верно излагаю твое ТЗ.

3) Если решен вопрос с коммутацией, то нужно придумать и логический протокол работы последовательного порта МК с N изолированными каналами. Тут следующий вопрос: А твои девайсы как себя ведут по жизни? Они согласны работать в режиме Мастер-Слейв, или требуется, чтобы они без запроса от контроллера порождали сообщения?
Если система Мастер-Слейв - так ВААЩЕ все просто. Контроллер переключил на линиию Д1, послал запрос, отработал ответ (пусть даже таймаут, по которому определил, что девайс сдох), переключился на следующий. Туту уж тебе решать, повторять потом обращение к неудачнику или поставить на нем жирный крест. Всякие там хвосты, остатки сообщений - на фиг! Ты же девайсы тоже создаешь? Значит, натренируй их, чтобы никогда от него не шло ничего, если от запроса прошло больше времени, чем контроллер выделил на таймаут.
Если же твои часто мрущие девайсы еще и инициируют обмен... Ну, батенька, тогда так и заявите. Будем думать. Но не сейчас. Я предпочитаю переваривать неприятности по мере их поступления :)
0
ptoop
0 / 0 / 0
Регистрация: 19.09.2010
Сообщений: 1,761
30.05.2011, 10:34 11
3) Если решен вопрос с коммутацией, то нужно придумать и логический протокол работы последовательного порта МК с N изолированными каналами. Тут следующий вопрос: А твои девайсы как себя ведут по жизни? Они согласны работать в режиме Мастер-Слейв, или требуется, чтобы они без запроса от контроллера порождали сообщения?
Согласен со всем, а по этому пункту возникает вопрос: если девайсы так же разрабатываются вместе с ЦУ, то смысл искать себе геморрой? Мастер-слейв идеальное решение.
Логически подумать: если устройству необходимо инициировать сообщение, то он передаст его во время опроса мастером и всё. Если надо очень срочно передать - повышаем частоту опроса до разумных пределов, делов-то...

Если же твои часто мрущие девайсы
Представил себе рабов на урановых рудниках :))))
0
Bokris
0 / 0 / 0
Регистрация: 27.08.2010
Сообщений: 77
30.05.2011, 14:01 12
Если у тебя ведомые будут выходить из строя... Х-м... Больше всего это похоже на автоматическое минное поле. :)
Есть дешевый способ это реализовать, на один UART ведущего цепляешь параллельно драйверы RS485 (ADM485 например) по количеству ведомых. Нужный канал выбираешь, путем подачи с ножек МК лог. "1","0" на лапы RE,DE нужного драйвера. Протокол значительно упрощается. При КЗ любой линии остальные работоспособны. UART всех МК защищены. ADM485 стоит копейки.
0
Sporkir
0 / 0 / 0
Регистрация: 27.01.2010
Сообщений: 619
30.05.2011, 14:14 13
Еще могут подойти беспроводные сети по стандарту IEEE 802.15.4. Плюсы:
1.Низкое энергопотребление.
2.Поддержка разных топологий, в т.ч. "звезда".
3.Центральный контроллер, работающий координатором и находящийся в "центре звезды", может организовывать сеть, добавляя и удаляя другие устройства => можно легко подключить(и отключать) новые устройства к главному контроллеру.

Минусы:
1.Надо купить недешевые трансиверы.
2.Невысокая скорость обмена данными.

Хотя это, конечно, не очень подходит: нужно будет серьезно менять программу и много чего еще.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
30.05.2011, 14:27 14
Этак мы до инфракрасной связи доберемся ))
0
otkymoy
0 / 0 / 0
Регистрация: 26.05.2011
Сообщений: 15
30.05.2011, 14:30 15
Спасибо за советы.

Про рабов :) система работает в жестких условиях, часто возникают выбросы горячего продукта, которые выводят из строя датчики/линии связи. Ну вот такое уж ТЗ :) Так что устройств есть вагончик, их периодически меняют.

"...стояли звери около двери, в них стреляли, они умирали..."

По условиям.
1. Работа мастер-слэйв. То есть само устройство по своей инициативе ничего в блок управления не посылает, только отвечает по запросу.
2. Любое повреждение конкретной линии/устройства не должно сказываться на работе других.
3. По топологии соединения - звезда имелось ввиду, что к каждому устройству идет отдельная, изолированная от других физическая линия. В качестве физики работы - смотрю на старый добрый 485, мне он нравится помехозащищенностью.
4. Радиоинтерфейсы не подойдут - дорого, ненадежно, захламлять эфир.....

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

Разработка своего не пугает - в принципе в голове уже есть некая целостная картина, просто хотел обсудить - вдруг кто что интересное подскажет.

По логике работы блока управления.
Длина сообщений фиксирована, 4-6 байт (точнее определимся чуть позже). Алгоритм вижу такой:
1. Подключил линию, выплюнул в нее команду, завел таймер.
2. Первый байт ответа должен прийти с признаком первого байта (скажем, бит7 = 1). Все остальные - без признака (бит7 = 0).
3. Принимаю байтики. Пока не получу байт с битом первого байта - все пропускаю. Получил - начинаю считать число принятых байтиков.
4. Досчитал до нужного числа - стоп прием, коммутацию канала отключил, посылку на обработку.
5. Если сработал таймер - значит, за заданное время не пришел ответ. Все принятое (если есть) обнуляю, линию отключаю, выставил ошибку.

Вот примерно так.
0
drvtos
1 / 1 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
30.05.2011, 14:39 16
Цитата Сообщение от otkymoy
Как я уже писал в начале, один из рассматриваемых вариантов - это коммутация нескольких разных каналов на один уарт контроллера в модуле управления
Вот и правильно. Нормально должно работать.

А протокол - вещь вообще не принципиальная. Ведь в каждый момент контроллер работает с одним единственным слейвом. Никаких тебе адресов на линию, никаких конфликтов. Поэтому делай, как удобнее. Можно вообще первый байт не выделять. Первое, что получено в ответ - это и есть первый байт. Отсчитываешь положенное количество и прекращаешь прием ("у меня обэд"). Если сработал таймаут - все в корзину.
Очень просто. И не стоит усложнять.
0
otkymoy
0 / 0 / 0
Регистрация: 26.05.2011
Сообщений: 15
30.05.2011, 14:43 17
Цитата Сообщение от drvtos
Очень просто. И не стоит усложнять.
Та да... не стоит умножать число сущностей сверх необходимости.

Спасибо всем за участие :)
0
Uttrym
0 / 0 / 0
Регистрация: 19.10.2010
Сообщений: 219
01.06.2011, 00:31 18
Исходя из тз желательно развязать каждый луч звезды для надежности.
0
drvtos
1 / 1 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
01.06.2011, 00:40 19
Ну, ты уже из его слейвов делаешь каких-то смертников. То, что они умирают, не означает, что они подрывают при этом центральный контроллер :)
0
Uttrym
0 / 0 / 0
Регистрация: 19.10.2010
Сообщений: 219
01.06.2011, 00:48 20
Просто коммутацию можно реализовывать по разному. Если физически будет рваться линия - то может и не надо развязку, а можно широковещательную передачу с мастера давать а получать ответ с нужного слэйва. Или как уже предлагали - 485 использовать. Вот в этих случаях лучше развязать. Чтоб линия не умирала и не блокировала остальные линии
0
01.06.2011, 00:48
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
01.06.2011, 00:48

Проекты контроллеров стиральных машин
Ребят, такое дело, нужны исходники AVR и WMLAB проекта "Управление стиральной...

Возможно ли программирование контроллеров на высокоуровневом языке?
Здравствуйте! Знаком с радиоэлектроникой и языком C#. C и Assembler не знаю....

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


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru