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

[Larzuk]

Всем привет! Есть задача создать сеть микроконтроллеров с односторонней передачей (от главного устройства к ведомым).
Как я это вижу - должен быть некий протокол в котором будетет передаваться номер устройства (2 байта) и данные (команда для принимающего устройства) 3 байта. Кабель для соединения желательно UTP, но можно и другой.
Задача усложняется тем что контроллеров в сети может быть от 1 до 2048 а расстояния между ними от 0 до 300 метров. Данные с главного контроллера будут передаваться примерно один раз в 0.01 - 0.1 секунду. Еще раз уточню что сеть однонаправленная, то есть опрашивать ничего не нужно, только передавать коммманды в ведомые контроллеры.
Быб бы рад любым советам и рекомндациям по разработке такого устройства. Спасибо!

[codenamehawk]

А как узнаете, что устройство приняло команду, вдруг сбой передачи, помеха.

[masmax]

ТОже аналогичный вопрос задал в соседней теме: http://radiokot.ru/forum/viewtopic.php? ... 0#p1515840

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

Всё это должно быть соединенно одной шиной. МК в этой сети разные: Atmel128 или Atmel8535. Другие редко уже встречаются. Ну и комп простой. В данный момент МК соединены между собой по RS-485. С компом - RS-232 (или USB).

Но в последнее время появляется передавать по шинам большие объемы данных (как правило текстовые строки пока). И 485 немного притормаживает и частично перекрывает другие пакеты, которые там тикают постоянно. Поэтому хотелось бы более скоростное решение. Плюс надежность нужна, так как условия проводки иногда уличные и на расстояния до 100 м. Тут 485 справляется с трудом. Устройства не очень массовые, сборка почти ручная.

В какую сторону копать и развиваться? Имеет ли смысл смотреть на шину CAN, например? Хочется иметь универсальный провод на всех устройствах. А то заказчики при сборке иногда путуют разъем от пульта управления и от индикатора (оба RS-485) и потом спрашивают почему не работает.

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

[Larzuk]

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

[Larzuk]

ТОже аналогичный вопрос задал в соседней теме: http://radiokot.ru/forum/viewtopic.php? ... 0#p1515840

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

вот! мне почти тоже самое нужно, только контроллер вероятнее будет тини2313.

[masmax]

А как узнаете, что устройство приняло команду, вдруг сбой передачи, помеха.

Ответ посылать? Это правда сильно затормозит передачу.

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

[masmax]

ТОже аналогичный вопрос задал в соседней теме: http://radiokot.ru/forum/viewtopic.php? ... 0#p1515840

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

вот! мне почти тоже самое нужно, только контроллер вероятнее будет тини2313.

Начни с изучения протокола UART и интерфейса RS-485. Составь свой протокол обмена. Грубо говоря команда будет примерно такая:
FE FF 04 ca 30 31 33
Где первые два байта (FE FF) - идентификатор пакета (увидев в линии их мы читаем дальше), 04 - длина пакета (сколько байт после него читать). Ну а следующие байты делай как хочешь. У меня "ca" - код команды (придумывай сам какой код - какая команда), а остальное данные.

[menzoda]

Нельзя просто так назначить некоторую последовательность символов в качестве какого бы то ни было идентификатора или флага. Необходимо гарантировать, что в теле пакета не встретится такая последовательность.

[s64]

Начни с изучения протокола UART и интерфейса RS-485. Составь свой протокол обмена. Грубо говоря команда будет примерно такая:
FE FF 04 ca 30 31 33
Где первые два байта (FE FF) - идентификатор пакета (увидев в линии их мы читаем дальше), 04 - длина пакета (сколько байт после него читать). Ну а следующие байты делай как хочешь. У меня "ca" - код команды (придумывай сам какой код - какая команда), а остальное данные.

RS-485 не поддерживает 2048 слейвов, нужно что то хитрить.

[orinoko]

можно использовать усилители. самодельные

[Jack_A]

Ничего хитрить не надо -- задача поставлена явно невыполнимая. Простая арифметика : пусть передача одного пакета займет 1мс. Пакеты заведомо тупые - без контрольных сумм, да и зачем КС, если отклика не будет ? В итоге получаем 0,001 * 2048 = 2, 048с. О каких 100 раз в секунду речь идет ?! Да и таймаутов никаких - как пакеты разделять будете ?
В общем, ТЗ из области фантастики срисовано с потолка. Фантазировать -- так уж с размахом : пусть система кроме сбора информации еще музыку сочиняет и деньги печатает.
А если серьезно и если это действительно кому-нибудь нужно, в чем я категорически очень сомневаюсь, то я бы поставил промежуточные узлы на МК, в которые закачивалась бы сжатая инфа, а уж эти управляющие узлы параллельно и одновременно рассылали подчиненным дивайсам команды, контролировали отклики, при необходимости повторяли команду и по запросу выдавали главному компу опять же в сжатом виде предварительно обработанную инфу.
Ну и вдобавок, чтоб служба медом не казалась - для задач реального времени на компе должна крутиться не винда общего пользования, а система реального времени, какая-нить QNX, за которую жадные буржуи много килобаксов требуют.
В общем, задача не для мальчика Пети из детского технического кружка ( это абстрактно, ничего личного ) .

[menzoda]

Видится мне Jack_A чушь написал...
Вот посмотрел не подумав, какие-то цифры увидел, и все! Давай непонятные расчеты строить и выводы делать. Какие к черту 2000 секунд? Какая сжатая инфа? Какая, в конце концов, QNX?

Через каждый N-ый интервал времени мастер выплевывает пакет, адресованный какому-либо устройству. Вот автору надо 100 миллисекунд. Пожалуйста - каждые 100 миллисекунд мастер будет отправлять пакет одному из устройств. Нигде не говорится, что необходимо каждый раз отправлять две тысячи разных пакетов - по отдельному для каждого устройства, ибо это априори полный бред (ну не бред, а задача иного уровня). Можно немного подумать и самостоятельно дойти до этого, а не кричать раньше времени. Если я не прав, в чем я сильно сомневаюсь, то извини, я - мудак, а ты - самый лучший.

А если по делу, то для начала давайте все-таки подберем автору физический уровень. Мне кажется RS-485 самое простое и верное. Однако, википедия говорит о максимальном для RS-485 количестве узлов, намного меньшим, чем требуется. Я не электронщик, поэтому понятия не имею, можно ли это обойти, и если можно, то как.

[vitalik_1984]

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

[menzoda]

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