Ситуация такая.

Есть три устройства, расположены на расстоянии 3-х метров друг от друга, одно master, два slave. Все три на ATMega446. Необходимо периодически обмениваться данными между мастером и слейвами. Размер пакета - 10 байт, скорость обмена - около 30 пакетов в секунду. Смотрел в сторону TWI- вроде бы он идеально подходит для моей задачи.

Проблема только одна - питания всех трех устройств гальванически развязаны друг от друга. А TWI вроде бы работает только в том случае, когда питание у всех МК общее.

Подскажите, как лучше решить эту проблему?

UART отпадает, это точка-точка, SPI можно но в данном случае избыточно, TWI он же I2C идеально подходит, питание у них не обязательно должно быть общее главное чтобы общий провод был общим, этот интерфейс требует внешней подтяжки резистором к питанию так как драйвера выполнены по схеме открытый коллектор или открытый исток.

У каждого устройства своя подтяжка к своиму питанию. Нада еще поставить защитные диоды на случай перекосов напряжений и т.д.

RS485 не годится? И модбас на нем и тогда, если в будущем, понадобиться, то можно без переделок сделать и 10, и 30 метров расстояние. Можно и развязать его при желании, хотя сейчас есть драйверы которые позволяют работать при перекосах питания до 70в. И еще один плюс - надо всего 2 провода, землю тянуть не придется.

MALLOY2, я правильно Вас понял, что вместо вот такого (из даташита):

Нажмите для просмотра прикрепленного файла

можно использовать вот такое:

Нажмите для просмотра прикрепленного файла

При этом Vcc1, Vcc2, Vcc3 - это всё местные питания, друг с другом не связанные. И ещё соединить землю питаний всех трех устройств вместе. Я правильно понял?

Не обязательно, можно соединить tx мастера с rxами слэйвов, а txы слэйвов через диоды (оптопары с ОК) на rx мастера, говорить одновременно и мешать друг другу они не будут.
и UART тут развязывать проще, линии однонаправленные.

ну а лучше конечно RS485.

Если питания развязаны, то развязаны и земли, и сигнальные линии. Иначе какой в этой развязке смысл ? А если земли у всех общие, то это и не развязка, и незачем тогда развязывать питания. Что-то я вопроса не понял. И вообще, зачем развязка, если между устройствами три метра ? Они что, от разных подстанций питаются ? Уточнили бы задачу, а то не совсем понятно, что, от чего и как питается. А так, первое, что приходит на ум - в мастере сделать два УАРТА, программных или аппаратных, и соединить их со слэйвами с помощью той же опторазвязанной токовой петли (Current Loop). Тогда действительно можно отвязать все и от всего, и расположить слэйвы хоть за 500м от мастера ...

Примеры развязок (CL):
http://www.kron.com.ua/conv/docs/T232-CL20%20S%20V4.pdf

Да, только если напряжения питания одинаковые, иначе нужно будет согласовывать.



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

Еще раз повторю для тех кто в бронепоезде UART это точка точка, если хотите UART много UARTов это уже RS-422 или RS-485, но тут может получится что затраты на драйвера будут лишними.

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

Слова про мастера и слэйвов в исходном посте и i2c как один из вариантов как бы намекают на отсутствие асинхронности.
и во всех остальных случаях разве адресация не нужна?


UART это никакая не "точка-точка", а всего лишь способ синхронизации для передачи данных по одной линии без клоков, а вот уж как будет сделан физический уровень 232, 422 (который, кстати, точка-точка в основном), 485 или просто выходы OK оптопар в качестве драйвера линии - это совсем другой вопрос.

MALLOY2, да, напряжения питания одинаковые, просто разные источники питания. Объединить их нельзя. Спасибо за совет!

_pv, Вы идете против бритвы Оккама ) Да вообще, мне субъективно TWI больше нравится. Я прочтя соответствующий даташита с перовго раза там все понял, прочтя то же самое по UART - не понял, осталось много вопросов. Вот этот факт и определил мой выбор. Никакой цели организовать гальваноразвязку между устройствами у меня нет - она и так уже есть, это развязка, т.к. источники питания разные. Не было бы её - было бы проще жить на свете.

Выбрав UART вы сможете спокойно отладить обмен устройств независимо друг от друга.
UART это сколько угодно slavov. Вся промышленность так работает.

Если у Вас земля общая - значит гальваноразвязки нет.
Если земля развязана - без доп. геморроя I2C сделать не получится.
В похожей ситуации (только слэйвов побольше) использовали UART+драйверы RS-485 - и все очень здорово получилось.
P.S. На 3 метрах I2C ничего не наловит?

Да, вопрос так поставлен, что ничего не понять. Гальваноразвязки у автора действительно и в помине нет. И для чего она ему нужна на трех метрах - тоже понять трудно. Разве что нужно связать между собой, например, несколько высоковольтных блоков. Например, человеку нужен управляемый источник высокого напряжения ...


Вы заблуждаетесь. На практике применить и запрограммировать UART на порядок проще, чем TWI. Чего только стоит одна обработка ошибок приема/передачи на TWI. Хотя это дело хозяйское. Пробуйте сами ...

И чего такого особенного она стоит?

По сравнению с UART она выглядит заметно сложнее, как, впрочем, и сам TWI ...

SPI избыточно? Вы хотите сказать что SPI сложнее чем I2C? Да это самый простой из всех этих интерфейсов, нужно не морочить никому голову, а делать на нем.



А как их адресовать?

Весьма самоуверенное заявление.


Может там сделать каждому свое питание легче, чем тащить к каждому устройству 5В. Развязывать земли при расстоянии 3 метра нет никакого смысла, а вот 5-вольтовое питание передавать на такое расснояние я бы не стал.


Правильно. А SPI на порядок проще чем UART. Ну хорошо, на пол-порядка Зато с адресацией слейвов никаких проблем.

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. Пришлось постараться, но получилось хорошо, я доволен. Выбор за вами ...

Если вдвое снизить частоту опроса, то подойдет. Что-то мне подсказывает, что это возможно.

По поводу SPI - последовательный периферийный интерфейс. Т.е. использоваться должен для работы с периферийными устройствами, такими как внешняя EEPROM, REAL TIME CLOCK и т.д. Покрайней мере я его так использую, а если кому то нравиться извращаться это его дело. А в рассматриваемом случае надо использовать RS485, без вариантов.

Пользовать UART через драйвер RS485.

SPI и TWI совершенно негодятся - т.к. это интерфейсы комуникаций между микросхемами, а не между устройствами - они как правило используются в пределах одного устройства.

Ещё лучше использовать CAN драйверы. Принцип тот же, цена та же, но нет состояния неоднозначности на выходе приёмника при ненагруженной линии.

Скорее это можно сформулировать как интерфейсы для связи интеллектуального мастера (МК) с неинтеллектуальными слейвами (память, часы, АЦП, ЦАП, ...). Но это не догма, а, скорее, более частая практика. Я в своё время реализовывал сети МК на всех трёх интерфейсах (плюс CAN), в том числе и развязанные. Никаких особых сложностей.