Arduino.ru

Если передавать состояния флагов (вкл/выкл) то обойтись оптопарами, если много - расширить регистрами (74hc595 у передатчика, 74hc165 у приёмников). Если нужно в обе стороны и не лень отвязывать землю и данные - RS485, самый ходовой трансивер называется SN75176, самый навороченный - ADM485. Если лень - то по радио, например nRF24L01+, или если много стен между ардуинами - то nRF905, его можно настроить на более низкую частоту (сигнал лучше стены пробивает). У 905 есть минус - 50 кбит/с это его максимум. Впрочем и 485й будет работать не быстрее сериала, то есть максимум 112 кбит/с, а реально 56.

Варианты с TCP/UDP сетью думаю не заинтересуют (дороже чем радио, раза в 4).

а можно подробнее про "Если нужно в обе стороны и не лень отвязывать землю и данные - RS485"?

Мне тоже нужен двусторонний обмен между МК на расстоянии до 15 м. Все найденные примеры - это Master-->Slave.
Насколько я знаю, линии A и B в RS485 развязаны от питания, т.е. можно не заморачиваться и на каждой стороне городить свое питание МК.
 

Теоретически есть библиотека под RS-485, обеспечивающая разрешение коллизий - лежит у меня где-то, пока так и не опробовал. Автор - majenko, искать по "majenko icsc" в гугле.

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

Я обычно в таких случаях использую аппаратную часть от CAN интерфейса, то есть CAN драйвер, работает со многими протоколами (естественно использую другой протокол мы не получим таких скоростей и расстояний, как в CAN, но основные преимущества сохранятся, а именно высокая скорость, расстояние до нескольких десятков, а то и сотен метров, возможность объединять множество устройств в одну сеть, защита от выхода из строя драйвера при одновременной передаче несколькими устройствами), в самом простом случае с UART (то есть аппаратная часть от CAN, протокол - от UART), если полудуплекс - то по одному драйверу с каждой стороны, если дуплекс - по два драйвера с каждой стороны, кстати если использовать, например в качестве протокола UART, то можно много устройств объединить в одну сеть (в отличие от RS-232, где это в лучшем случае проблематично), причем если все будет правильно подключено, то данной системе не страшны ситуации когда несколько устройств начнут передачу одновременно (у RS-485 есть такая проблема, поэтому там надо избегать таких ситуаций или ставить защищенные от коротких замыканий драйвера), но возникновение подобных ситуаций надо отслеживать во избежании повреждения данных. Также можно использовать и другие интерфейсы, например SPI, но это усложнит конструкцию (по 4 драйвера с каждой стороны), но увеличит скорость и помехоустойчивость.

Что касается самих драйверов, тут как вам больше нравится или какие требования к устройству, есть большое количество неизолированных драйверов, например, PCA82C250, PCA82C251, есть изолированные (гальванически изолированные) драйвера, например, ISO1050, есть изолированные драйвера со встроенным DC-DC преобразователем, например ADM3053.

В RS485 всё замечательно и можно много устройств подключить, но оно полудуплекс и есть неприятный кадр тишины 0.3с для синхронизации. Ethernet модуль на уровне MAC избавит от этого, не сложнее сериала и не особо дороже. Хаб можно сделать на резисторах.

Ну RS-485, то полудуплекс, а RS-422 - то же самое, но дуплекс (правда и количество проводов увеличится).

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

Я сделал сеть на 21 устройство через RS485. Одно главное, 11 первого уровня, 9 вспомогательные. Протокол придумал свой собственный, т.к. готовые не годились. Пришлось немного повозиться, но в итоге все работает, чего и всем желаю.

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

Если два начнут вещать одновременно, КЗ не будет?

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

А как коллизия может грозить КЗ? По моему там полярность у всех одинаковая, максимум что случится - белиберда, которую никто не поймет.

а пакет данных строковый или байтовый?

| 00 | 0 | 0 | 0010 |
  |    |   |     |
  |    |   |     Номер порта, с которым что то делаем
  |    |   Бит действия, GET / SET
  |    Режим порта HIGH / LOW
  Еще что либо

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

Слушают все в кольцевой буфер принимая туда данные побайтно и проверяя на старт/стоп и адрес, после чего проверяют КС, и есть все ОК, то принимаем команду к исполнению. 

Вы описали далее RS-485. Cам т.с. RS-485 ничего подобного не делает, он обычный по сути ком-порт, кодирующий передачу байта. :) А описанное Вами, это уже работа протокола. И это не обязательно мастер-подчинённый. Может быть и несколько мастеров, может быть токен-ринг, и этот, как его (забыл) в телефонии использоался...

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