http://www.analog.com/en/interface/rs-485/...ts/product.html
Изолированный 485 со своим питанием. Удобно и надёжно.

+1

Поверьте, люди Вам дело говорят.
Реализовать протокол, например, MODBUS, хотя бы в самом урезаном варианте, не сложно, во всяком случае, не сложнее TWI. И привыкайте, пока на грабли не наступили, что шнурок, который соединен с ногами камня и выходит наружу устройства - это не просто сборщик мусора вместо данных, а и источник зависаний всего устройства (если конечно это хозяйство не лежит на рабочем столе у вас дома). Это - во-первых, а во-вторых, развязать гальванически двунаправленный TWI сложнее, чем UART.

Кстати, уверен на 90 процентов, что реализованый сегодня MODBUS, в будущем пригодится Вам неоднократно.

Тем не менее, если у мастера уже есть интерфейс с PC, то для связи между устройствами можно выбрать и TWI, а гальваноразвязка легко делается на ADUM1250/1251.

Спасибо всем за ответы! Действительно, посмотрю в сторону 485...

нет не сложнее, а избыточнее в данном случае. Скорость нужна низкая I2C хватает, но I2C всего 3 провода, а у SPI сколько будет ?

Прошу прощения, ошибся. http://www.analog.com/en/interface/rs-485/...ts/product.html <- этот со своим интегрированным питанием. Если вопрос бюджета не стоит остро - очень удобное решение.

А ты не ел устриц не знаешь SPI? А что ж тогда заявляешь что I2C однозначно лучше? У SPI 2 провода, плюс по одному проводу для выбора ведомого. То есть адресация ведомых существенно проще, а в обработке состояний I2C свихнуться можно.

Дядя идите учить мат часть SPI interface



теперь считаем

1) GND
2) MISO
3) MOSI
4) SCK
5) CS for Slave 1
6) CS for Slave 2

Итого 6 проводов, против:

1) GND
2) SCL
3) SDA



Мне что I2C, что SPI, что UART не вызывает ни каких трудностей, все это примитивщина.

Если выход может переключаться в Z-состояние, то MOSI и MISO допустимо объединять.
Тут немного другое стоит учитывать. Самое важное в интерфейсах передачи данных это достоверность передаваемых данных. I2C и SPI на аппаратном уровне не дают информации о достоверности передаваемых данных. В UART с помощью передачи бита Parity можно обнаруживать искажение единичных бит. При использовании же программного протокола, который "ложится" поверх аппаратного интерфейса, достоверность передачи данных значительно увеличивается.

А попробуйте опторазвязанный I2C. Там все построено с ОК, так что PC817 вполне подойдет. Линия у Вас будет развязана относительно питающих и сигнальных цепей. Кажись то, что надо.

Не подойдет. Во времянках проблема. Если бы все было так просто, то гальваноразвязку к I2C прикрутили еще бы 10 лет назад.

«вы будете смеяться», но её и прикрутили 10+ лет назад
http://www.eetimes.com/design/embedded/402...-of-the-I2C-Bus
там под первой картинкой 1998 год указан.
Вот тут у NXP тоже кое-что на эту тему
http://ics.nxp.com/support/documents/inter...pdf/an10364.pdf
Странно, что дата апноты совсем свежая, там много картинок со статьёй совпадает.

http://www.nxp.com/documents/application_note/AN255.pdf

Да, про клок забыл...

Количество проводов - не самое страшное в жизни. Управлять I2C на порядок сложнее, а если еще делать полную обработку ошибок (а не надеяться что их не будет), то можно свихнуться.

Про эту статью я знаю. Читал года три-четыре назад. Только там в дате статьи 2004 год указан. И PC817 в схемах не наблюдается. А там где 6N36 указана частота всего 5кГц. Полнофункциональные изоляторы I2C (до 1МБит/с) появились совсем недавно - ADuM125x, ADuM225x.

Согласен почти на все 100. Недавно пытался реализовать обработку ошибок на AT91SAM9XE512. Это капец. Сама по себе обработка ошибок довольно сложна, а тут еще и TWI в этом МК сделан так, что нормальную обработку сделать крайне трудно. Так и не удалось как полагается обработать все ошибочные ситуации. С AVR попроще. Делал нечто подобное на ATMEGA88. Пришлось постараться, но получилось хорошо, я доволен. Выбор за вами ...