Нужно сделать сеть 1 Мбит, до 20-30 устройств. Топология шина, длинна не более 15м.
Думал сначала почти однозначно RS485, но есть и другие идеи =)

Т.к. сеть не большая, хотелось бы обойтись без драйвера одной токовой петлей и, предположим, АТмегой на внутреннем РЦ генераторе 8 МГц. В связи с этим есть идея сделать нечто на СИНХРОННОМ уарте. Использовать шлейф IDC с разьемами в нужных местах, , типа как в ПК шлейф IDE, питание тоже по нему на слейвы подавать.
Теперь вопрос =)
Нужно ли оно? Какие могут быть проблемы-сложности?
Может лучше сделать стандартный рс 485 с витой парой и драйверами и кварцами на слейвах?

Вроде все. Спасибо за внимание )

А где сетка будет эксплуатироваться? В каких условиях? Если для промышленного применения (где-нибудь в цеху), то IMHO "другие идеи" лучше сразу отбросить. Сделать на RS485, желательно с гальванической развязкой.

В жилых/нежилых помещениях. Впринципе могут поблизости быть эл. двигатели до пары кВт =)

Все-таки интересно было бы узнать как себя ведет синхронная передача на небольших длинах и почему ее не используют на больших длинах...

Можно еще CAN сделать, на такой длинне.

Можно. А какие преимущества?
Вообще программная реализация будет не стандартная. Поэтому вопрос чисто по физическому уровню..
ОЧЕНЬ хотелось бы использовать вместо витой пары шлейф, даже если рс 485. Опять-же хотелось бы обойтись без драйверов на слейвах или вообще синхронным уартом.
И интересует чем это может быть плохо) Или хорошо. А то что можно много всего сделать это понятно конечно =)

Резкое уменьшение трафика из-за отсутствия ведущего. Т.е. все будут посылать сообщения только если у них произошло к.л. событие. В RS485 обычно 90% сообщений типа таких: Ведущий: Ведомый N17, у тебя что-нибудь случилось? Ведомый N17: У меня всё в поряде.

Тогда сделайте USART с драйверами от CAN. Недостатков, в вашем случае, по сравнению с RS485 нет (кроме цены драйверов), а преимущества есть, и немалые. Поищите по форуму - такой вариан рассматривался.

Не понял. Мегабит без драйверов на 15 метров?

Ну это мне не актуально т.к. опрос будет идти постоянно и чем чаще тем лучше.
Считаем что данные меняются постоянно.



Да =) Считаете, что не выйдет? С синхронной передачей?
Хотя поставить 485й драйвер я уже пожалуй не против.

А скажите плз насколько в моем случае принципиально использовать витую пару
по сравнению с шлейфом под IDC(шаг 1.27мм)?(Если таки окончательно решусь делать РС485)

Сообщение отредактировал overloaded - Mar 3 2009, 18:01

И совсем не обязательно организовывать обмен именно таким образом. Можно, например, так: свободна линия и есть, что передавать - передаем, занята - ждем. В посылке можно указывать адрес получателя. Физический уровень RS485 это, вполне, позволяет. В отличие, например, от сдвоенных линий RS422 или прямых соединений UART. И физический конфликт на шине (одновременная передача многими) для RS485, как правило, не приводит к катастрофическим последствиям - выходу из строя драйверов. А вот в случае прямого объединения UART - это не гарантировано.
Потом, все таки, RS-485 - стандартное решение, есть готовые драверы... А вот способен ли UART МК "прокачать" 15-ти метровую линию на 1МГц - большой вопрос. И не "собрать" при этом все возможные помехи и наводки.... В общем, на физическом уровне, я бы выбрал RS485, как оптимальный вариант для небольших скоростей обмена по соотношению цена/качество. Конечно, я не совсем объективен, так как, в основном, занимаюсь промэлектроникой.
А на программном уровне - останется полная свобода действий. Почему обязательно асинхронный обмен? Можно и синхронный, если есть такое желание. Единственное ограничение - полудуплексный режим обмена...

Это не есть недостаток. Ведомый сообщает, что он работоспособен, а не завис, например. И ведущий к тому же "знает", что линия связи до ведомого не повреждена. А вот если по-вашему делать, то в случае когда будет глобальный абзац (пропало питание на одном из ведомых или группе ведомых), то ведущий узнает об этом лишь постфактум. Когда электричество уже починят и ведомые всей толпой враз попытаются сообщить о том, что у них проблемы были. Или вообще не узнает, если линию обрежут. Постоянный циклический опрос всех ведомых, например, в системах диспетчеризации это типовое/стандартное/необходимое для нормальной работы решение.
Угу. Сразу же возникает ограничение, для 1 Мегабит - длина линии CAN не более 25 метров.

Конечно, Вы правы. Но когда количество ведомых переваливает за сотню, то полный цикл их опроса может занять несколько секунд, или минут... Тогда имеет смысл оставить "окна" в траффике, чтобы любое устройство могло самостоятельно обратиться к ведущему в экстренном порядке... То есть, оптимальное решение - как всегда, компромисное... Но это уже несколько другой уровень проектирования системы... Самое важное, что RS485 позволяет все это реализовать...

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

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

Конечно, такая система сложнее в реализации, но имеет полное право на существование.

PS Наглядный пример - пожарная сигнализация, соответствующая стандарту EN54. Время реакции на сигнал "Пожар" не должно превышать 10 секунд, на неисправность - 100. Как раз идеальный случай для приоритетных событий, передаваемых инициативно. С другой стороны, если из девайсов постоянно выгребаются какие-то данные типа уровней постоянно меняющегося аналогового сигнала, инициативная передача особого выигрыша не даст, проще выполнять банальный циклический опрос. Кстати, именно по этому надо стараться переносить обработку в девайсы, и гонять по каналам связи как можно меньше информации

Можно добавить в систему аварийное сообщение от "слейва" мастеру. Начало - более 9 нулей. CAN (под uart) в этом случае весьма полезен - все передатчики слушают эхо и в случае чего затыкаются.
В общем, если нет проблем с ценой драйверов и длинна 15 метров - CAN (полный или только физически) лучше. В остальных случаях я (бы) выбрал RS422 и объединение всех концов в хабе. Для исходных параметров драйвер обязан быть, витая пара весьма желательна, терминировать концы (485/422) необязательно.

У меня всегда одно из событии, случившихса у ведомого, называется "я жив" - подаётся например каждую секунду или так "я жив уже 156.6 секунд". Я как-то забыл об этом написать. Но когда у ведомого случаются более приоритетные события он говорит о них, и при этом считается, что он жив (ватчдог его жизни взводится). В случае CAN - сообщение "я жив" обладает низким приоритетом и совершенно не мешает другим сообщениям. При скорости 125 кбод (а не 1 мбод, как у топикстартера) 64 девайса посылающие сообщения "я жив" каждые 100 милисекунд совершенно не мешают друг-другу. Вообще-то они самоограничивают частоту своих событий, т.е. говорят о них не чаще, чем раз в 20 милисекунд (кроме редких сверхприоритетных). Но такое самоограничение всегда полезно.
К тому-же если в данный момент в сети только 3 устройства, ведущий не будет тратить время на опрос остальных 60-ти. И в сети ОДНОВРЕМЕННО могут находится 64 девайса, а всего их м.б. много больше. Да и за счёт отсутствия собственно пакетов запроса и ожидания (безрезультатного) ответа на них (а м.б. пакет от ведущего был просто повреждён и нужно повторить запрос) ещё трафик уменьшается. Т.е. кругом сплошные преимущества.
Кстати мне кажется, что у топикстартера 1 мбод - это многовато. Возможно это как-раз из-за опроса?

Для USART с драйверами CAN длина будет побольше, т.к. там поменьше требования к самоприёму. Практически можно использовать те-же значения, что и у RS485.

2 @Ark
А вот с драйверами RS485 мультимастерность крайне ограничена (из-за неинформативности самоприёма). Я бы даже сказал губительна для реалтайма, т.к. пока девайс не выдаст ВЕСЬ свой пакет он не узнает, что была коллизия. Да и восстановление после коллизий может затянуться. Пример - эзернет.

Подредактировал. Извините за повторы. Около 0.00 всегда интернет затыкается.

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

Кроме того, эзернет на общей шине давно мертв.

На этом наверное и остановлюсь. Под синхронным я имел ввиду не обмен, а сам физ уровень тоесть клок+дата =) Но уже от этого отказался.



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

Кстати спасибо всем ответившим =)



Можно поподробнее про конци и хаб? ) Зачем это нужно и что куда обьединять?

Сообщение отредактировал overloaded - Mar 4 2009, 11:45