Помогите определиться с интерфейсом, или вероятнее что-то полу-свое? ) Опции

[overloaded]

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

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

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

[Guest_@Ark_*]

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

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

[overloaded]

.... В общем, на физическом уровне, я бы выбрал RS485, как оптимальный вариант для небольших скоростей обмена по соотношению цена/качество. Конечно, я не совсем объективен, так как, в основном, занимаюсь промэлектроникой.
А на программном уровне - останется полная свобода действий. Почему обязательно асинхронный обмен? Можно и синхронный, если есть такое желание. Единственное ограничение - полудуплексный режим обмена...

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

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

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

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

В остальных случаях я (бы) выбрал RS422 и объединение всех концов в хабе. Для исходных параметров драйвер обязан быть, витая пара весьма желательна, терминировать концы (485/422) необязательно.

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

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

[galjoen]

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

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

Согласен. Я плохо знаю эзернет. Давным-давно попробовал и понял, что реалтайма от эзернета добится не получится, с тех пор и забросил т.к. все задачи у меня с жёстким реалтаймом связаны. А вот насчёт общей шины я не знал... Я считал, что до сих пор хабы пакеты во все стороны передают. Раньше ведь так было? Т.е. хоть шина и не общая, но везде кол-во пакетов одинаковое. Разве не так? Кстати не подскажете где бы про нынешнее состояние эзернета почитать?
Простите за оффтоп.
Но вот в случае мультимастерности на RS485 смысла в преамбулах я не вижу. Т.е. я имел ввиду, что сам пакет (он д.б. достаточно коротким) будет играть роль преамбулы.

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

"Ожидания не будет т.к. ждётся следующий" - несколько противоречиво...
1. Что будет делать ведущий RS485 после того, как он отправил ведомому пакет?
2. По каким признакам ведущий сможет узнать был-ли пакет отброшен ведомым т.к. CRC не совпало или ведомый просто сдох?
3. Если один из ведомых на некоторое время сдох, а потом опять заработал (например ватчдог перезапустил его процессор) восстановится ли связь с ним в вашем случае?

[overloaded]

"Ожидания не будет т.к. ждётся следующий" - несколько противоречиво...
1. Что будет делать ведущий RS485 после того, как он отправил ведомому пакет?
2. По каким признакам ведущий сможет узнать был-ли пакет отброшен ведомым т.к. CRC не совпало или ведомый просто сдох?
3. Если один из ведомых на некоторое время сдох, а потом опять заработал (например ватчдог перезапустил его процессор) восстановится ли связь с ним в вашем случае?

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

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

3. Ну а что ей мешает восстановиться? Скорость общего опроса конечно упадет за счет таймаутов пока проц будет заново инициализироваться, но это же не нормальный режим работы а просто как крайний вариант - сброс по вачдогу и постоянно он не должен срабатывать..