Какой интерфейс (физический) выбрать?

[ALEX__A]

Все ниправильно блин.. ни rs232 ни I2C в чистом виде не дают достоверности данных
а вот у CAN у него аппаратная CRC это усложняет дело и удорожает ус-во
потому что нужно применять контроллеры с поддержкой CAN или что-то
вроде того что было только опять огород получаеться Можно конечно
по RS232 соединить , но это только соединение а вот протокол устраняющий ошибки
и обрабатывающий приоритеты и адреса -Это писать долго
Встречал многие фирмы которые потратили на это- они говорят -у нас свой протокол
Но мне кажется что сейчас когда появились контроллеры с поддержкой CAN а
их просто раннее было очень мало, смысла нет городить огород

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

С уважением, Алексей.

[Gnider]

почитайте условие задачи

Спасибо почитал.

[int4880053]

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

Так было давным давно, когда деревья были большими
Самый нижний уровень протокола, а его мы обычно называли транспортным как раз и занимался не только прокачиванием блоков данных но и исправлением ошибок при неверной CRC В зависимости
от полинома можно исправить отдельно выпадающие биты, если нет
то команда на повтор блока данных Так в режиме проталкивания
блок за блоком. Помехоустойчивое кодирование конечно улучшает
дело смотря какой алгоритм Есть такие которые не предусматривают
повторов потому что данные исправляются сразу в процессе приема
но длинна кода избыточности очень велика (но это все математика)
В данном случае достаточно определить ошибку по неверной CRC
даже если передаем 1 символ
Если с I2C переходить на RS232 то обмен должен быть буферезированным
по прерыванию
а это означает что все равно как-то контроллер ввиде моста ставить все равно надо
и адресацию и режимы работ то-же придется дописывать и контроль сбоев и нештатные
ситуации
В протоколе CAN все это уже есть Там есть все необходимые пакеты управления для
реализации задач управления устройствами на любой вкус

[E-Male]

Во-первых, мастер всегда только мастер (инициатор передачи) а Slave всегда только ждут. Если устройства могут по своему усмотрению становится тем и другим, это уже сеть с равноправными абонентами. Со всеми вытекающими последствиями: коллизиями передачи и т.д.
Достоверность передачи можно обеспечивать двумя способами: заведомо надежной линией связи (SPI, I2C), и коррекцией ошибок на ненадежной линии (CAN, Ethernet). Либо сочетанием их в случае критических данных (команда на включение двигателя например).
При длине линии в метры и более на линию уже действует слишком много факторов, чтобы ее считать заведомо надежной для высокоскоростной передачи данных. Я занимаюсь телеграфией и здесь на скорости в 50 Бод можно считать надежными линии длиной даже в километры, так что все в конечном итоге зависит от нужной скорости. В вашем случае я так понял, что устраивает скорость 100кбит при длине линии 0,5м. В этом варианте вполне реально устроить надежную линию. Я бы выбрал SPI, т.к. там можно играть скоростью.
Из рабочих проектов:
SPI, скорость 160кбит/сек. 1 мастер около 30 слейвов.
На входе каждого приемника (все CS, MOSI и CLKу slave и 1 MISO у мастера) стоит ФНЧ - RC 220 Ом+100 пф. Он обрезает всю гадость, что лезет с линии, и за ее фактическое качество и согласование можно не волноваться.
Можете исходить из этого и дальше глядеть по обстановке с помехами - скорость можно уменьшить вместе с понижением ФНЧ. Либо увеличить если требуется.

[E-Male]

Добавлю:
фильтры на входах приемников обязательны. Просто понизить частоту SPI недостаточно. Я сам мучился с одним расширителем портов - не работает и все. Скорость выставляй хоть 1кГц. Потом допер - слейв был расcчитан на частоты до 50МГц, поэтому имел сверхбыстрые входы, и даже малая помеха могла ему включить CS или добавить лишний такт на Сlock.
И еще совет - если все же нужна проверка на ошибки передачи. Чтобы не заморачиваться с помехоустойчивым кодированием, используйте трехкратную посылку. Приемник сравнивает три посылки побайтно. В случае несовпадения одной - считать истинными остальные две. В случае всех разных - считать передачу неуспешной (если такое повторяется часто, с линией надо поработать).

[bsvk]

Из личного опыта.
Для связи в условиях помех между двумя блоками хорошо подходит обычная токовая петля, нагруженная на оптопару (даже если гальваническая изоляция и не нужна) скорость на обычных оптопарах до 19200 (9600 вообще элементарно), для большей скорости нужны быстродействующие оптроны.
Если дистанция небольшая - можно любым интерфейсом, просто грузите его резисторами обильно, так что бы суммарное сопротивление было бы 100-500 Ом, Правда придется поставить транзисторы на выходные каскады, но думаю это не проблема.
В целом:
1. Правильно сказано диф. интерфейс сильно надежнее несимметричной линии связи.
2. Чем меньше сопротивление нагрузки линии - тем более мощной должна быть помеха что бы исказить сигнал. (грузить надо оба конца линии)
3. Передача током (так как она нагружена сильно) существенно защищенее чем передача напряжением.
4. Использование в приемнике элементов (например оптопар) которые физически не могут реагировать на ВЧ помеху сильно упрощает дело.
5. И пожалуй самое важное - грамотная прокладка проводов и дорожек, отсутствие "петель" земли и питания помогает в десятки раз уменьшить помехи в устройстве.

[Boba_spb]

При использовании GSM модемов ( они работают по RS232) помех на линии вроде как не наблюдалось, а вот сюрпризов от провйдера - отгребете .. Крепитесь ...

[E-Male]

Да, я тоже забыл добавить про GSM модемы.
Можно считать, что модем имеет несущую 1ГГц при мощности передачи около 1Вт максимум. Это во-первых. Вы физически не сможете уменьшить емкость вашей линии передачи настолько, чтобы по ней смогли ходить а тем более мешать вам гигагерцовые сигналы. Проще говоря - сигнал моментально потухнет в вашей стандартной линии. Для уверенности посмотрите емкость входов ваших приемников на линии. Если больше 10пФ - считайте гигагерцы им уже не страшны.
А вот теперь о главном - намного страшнее чем модем будет самый родной блок питания вашего устройства. Он скорее всего будет импульсный. Это и будет устройство мощностью я предполагаю до пары десятков Вт, работающее на частоте несколько десятков килогерц, то есть сравнимо с частотой интерфейса. Расположен он будет очевидно близко к устройству, и соответственно близко к интерфейсу. Советую быть повнимательнее с расположением импульсных приборов близко к линиям передачи.

[tihon.d]

Я советую юзать RS485, так как:
1) он достаточно помехозащищенный, особенно на низких скоростях;
2) он простой в реализации и отладке;
3) если понадобится, можно будет легко присоединить к компу;
4) его реализация не требует больших финансовых затрат.

На счет протокола - сначала определитесь, что конкретно будут передавать Ваши устройства, как часто необходим обмен информацией, как часто устройства будут присоединятся/отсоединятся от сети.
Потом поэкспериментируйте с вариантами протоколов без CRC и подобного без источника помех и только потом, если конечно появится необходимость, экспериментируйте с защитой от потерь информации.
Я имею опыт построения подобных сетей, буду рад помочь. Моё мыло: [email protected] . Пишите.
Удачи!

[vasenik]

А вы все забываете ещё об одном пункте ТЗ:

По специфики программного интерфейса. Каждое устройство может быть как Master так и Slave. При необходимости передачи устройство переходит в режим Master и инициирует передачу. В остальных случаях находится в режиме Slave.

RS-485 этого не сможет предоставить, т.к. в нем не реализовано на физ.уровне выправление коллизии. А вот в CAN это как раз и реализовано, истинно сказано:

Такой давно приидуман и называется CAN , предназначен для соединения
различных устройсв между собой и применяется в автомобильной
электронике потом его стали с успехом применять в робототехнике

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