Чтобы на дальнем конце МК безо всяких Eth мог принять несколько байт, что- то обратно переслать. т.е. RX TX полноценный сделать. Что- то может из готового использовать? SPI читал, не тянет дальность, I2C тоже. 1-wire? Может проще свое что-то сделать? Скорость не нужна, в принципе. Кто- нибудь сталкивался?

Скорость какая? Хотя, если i2c устраивает, то RS485 в качестве интерфейса скорее всего подойдёт.
Протокол зависит от задачи. Принять несколько байт - не задача. Задача - это то, для чего эти несколько байт передаются, как они будут использоваться, насколько это должно быть надёжно. Балансный или небалансный канал связи, и т.д.

Если скорость никакая, то физика RS485 хорошо ложится, если пара одна, то особенно хорошо. Далее UART и над ним надо добавить протокол переключения направления. Это уже зависит от того, что и как Вам требуется передавать. Проще всего, если один прибор главный, передает условно команду, другой принимает и передает что-то в ответ. Разруливать все на таймаутах. Хуже, если оба могут в произвольный момент времени что-то захотеть передать друг-другу.

Это не хуже. Это просто надо решить. Точнее даже выбрать протокол, в котором это решение уже есть и реализовать. В общем, тривиальная инженерная задача.

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

Пробую для себя на даче сделать освещение умное. Т.е. один проц, он имеет одну общую шину, на которой висят до 100 девайсов. Мастер может послать команду кому- нибудь включить свет. Тот должен ответить ОК. Может спросить датчик о состоянии. Получить ответ. Если где-то включили выключатель, он шлет команду, что его включили. На смартфоне должно загореться включено. Если два одновременно включили- как бы они не забодались на одной шине?

адресация на такой шине очень полезна, и никакой "демократии" - вопросы должен задавать только мастер

Типовая задача для пром. автоматики. Так что RS-485 + MODBUS (или свой аналог).

Да, RS-485 через UART для такой задачи будет самое то. Именно один мастер и много слейвов. Без адресации тут вообще никак.
И когда будете подбирать драйвера RS-485, имейте ввиду, что стандартный драйвер имеет входное сопротивление 12 кОм и рассчитан на 32 устройства на шине. Так что ищите драйвера с высоким сопротивлением, чтобы можно было подключать 128 или 256 устройств.
И скорость при 100 метрах большую не делайте, не более 19200, а лучше еще меньше.

MODBUS- это что?
А микросхемки RS-485 на вскидку подскажете проверенные?
Почитал про RS-485- это тот же UART, только физика RS-485

Т.е. мое решение- именно RS-485? Это получается, стандартное решение для подобных задач?

Не только стандартное, но и разумное из практических соображений. Для "более простых" - 1-Wire, I2C - будут проблемы на практике на расстояния 100м (тут вам придется верить или не верить советчикам), которые вряд ли кому желательны.

Стандарт протокола логического уровня. Исключительно, чтобы не придумывать свой, но можете и по-проще придумать.
А если MODBUS, то смотрите википедию MODBUS RTU - там инфы хватит.


Любые. Открываете каталог своего поставщика и выбираете любые на нужное питание (3В или 5В) и кол-во узлов >=128


Именно так

микросхемы и протоколы работы посоветуйте тоже.
Протокол мне самому выдумывать или тоже взять стандартный?

Одновременно с коллегой написали) Он ответил, спасибо.

не надо 485, юзайте can, чтобы ничего не выдумывать

новый поворот в деле)
Посмотрим на него.

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

RS-485
Любой МК с UART. Логический уровень (целиком) - любой. Но, невозможен побитный арбитраж при наличии коллизий.
Достаточно знаний работы UART

CAN
МК с CAN контроллером или внешний CAN контроллер который аппаратно поддерживает нижний пакетный уровень протокола
с арбитражем коллизий. Верхний логический уровень любой.
Сложность работы с CAN заметно выше.

Решать вам
Для пром.автоматики - однозначно CAN
Для умного дома начального уровня - RS-485 гораздо проще.

как раз can намного проще- пакетная передача , нет коллизий, есть контроль и переповтор

в чем сложность ? поясните?

спасибо Че за развернутый ответ.
А по стоимости? can микросхемы по чем? И чем они управляются?
Один мастер и остальные слейвы- подходит. Так же прекрасно знаю UART. Все в пользу 485. Про can придется изучать заново все.

Спрошу здесь же- чтобы в каждом выключателе не делать БП 220- 12V, получится по витой паре UTP по свободным проводникам запитать систему? Реле при 12В потребляет 30 мА. Возьмем 64 максимум. Порядка 2А. Или реле на 24В, ток меньше в 2 раза. Суммарно 1А по витухе. Думаю, метров 50 максимум у меня будет длина луча одного.

Я имел ввиду начальную сложность освоения и сравнительную сложность аппаратной части.


Ну, цены сами посмотрите
А вообще, мне кажется, что мелких контроллеров с CAN не так много и цена будет больше, чем просто с УАРТ.
Изучавшие этот вопрос пусть поправят, если это не так.
Тем более, что вы замахнулись на 100 слейвов.


Думаю получится, питание лучше 24В тянуть. Делали на таком принципе систему в 16-и этажке, тянули кабель по шахтам "ввышину" дома.
Работало нормально, правда там реле не было.
Мастер был в подвале в центре шины. И два луча на две шахты по метров 40. Суммарно 100м шина и была.

для arm все драйвера написаны . только скорость задаешь и читаешь передаешь пакеты
а про аппаратную сложность что вы имеете ввиду? два резистора с конденсатором на концах линии - так она проще чем у rs с ее подтяжками и ломовым током и 3 состояниями в шине? микросхема она и есть микросхема. can намного проще и в аппаратном и в программистком плане.
не нужно париться ни о какой синхронизации и сложности передачи пакетов !!
это большой шаг по сравнению с убогим 485

По деньгам без разницы. Разве что контроллер будет больше. UART есть даже в восьминогих крохах. А про изучать заново - это же плюс. Тем более, что ничего сверхсложного там нет. Хотя для этой задачи RS-485 подходит лучше, ИМХО.


Можно до 48 поднять, как в PoE. А вот про длину луча подробней. RS-485 не предназначен для "звезды". Хотя на 50 метров работать будет, скорее всего.

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

Про can- хотите сказать, что никаких внешних преобразователей уровней там нет? Просто ногой +3.3 и дергать? Беру драйвер готовый и всё?
Можно посмотреть на эти драйвера? Где почитать про них?
И так и не понял- в can шине только команды ходят? Вроде что-то читал, что еще и питание.

То, что это "большой шаг" я не спорю

А про сложность имел ввиду сложность самого CAN контроллера в виде периферийного блока.
Можно конечно вообще не париться, применять готовые драйвера как черные ящики.
Но я как то привык хоть немного разбираться во внутренностях тех черных ящиков, что я применяю.
И времени на это у меня иногда изрядно уходит...

тогда уж и ethernet
но вот если говорим умный дом, то должно быть нечто, передающее по силовым проводам

нужно в выключатели встроить мою платку. Проводку еще не сделал- планирую заниматься сейчас ей.
Eth- дорого и не нравится он мне в МК. Готов проложить доп. кабель витуху- не так это накладно. Модем по силовым цепям, думаю, дороже решение. Да и гадить сеть помехами не хочу. HI-FI слушаю.

Для справки- умный свет от топового поставщика- около ляма решение. И это только свет. Так что можно чуть подзапариться мне и сделать проект для себя.

Данные по силовым цепям гоняют (пытаются) исключительно из безысходности экономии, когда проводка уже есть
Конечно, если есть возможность проложить выделенную линию, она будет работать гораздо лучше.
Только не прокладывайте UTP, он же вдоль силы будет идти, не поскупитесь на экранированный.

хорошо, что подсказали. Надо экранированный и чтобы сопротивление малое было- для питания. А то читал, что есть с большим сопротивлением.
Я так и не понял- can шина- сразу с МК выход беру, или нужна еще микруха- преобразователь? Типа как в RS-485

А я бы для управления освещением все ж подумал бы о X10. Хотя медленно, конечно....

пока про can читаю. Есть STM32 с кан на борту. Осталось выяснить- сразу его в линию запускать или еще что-то надо для согласования.

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

Делаю для себя. Не на продажу. Хочу красиво, грамотно. Изучаю STM32 c can.

Да нужно, конечно, примерно такой же драйвер, как и для RS-485. Физика примерно та же, нюансы сильно другие.
Если МК без CAN, можно взять внешний CAN контроллер с драйвером, но это будет дороже.

Вот вам комиксы с картинками:
http://ww1.microchip.com/downloads/en/AppNotes/00228a.pdf

з.ы. А если ТС захочет продать свой дом целиком с такой системой, то думаю, проблем у него не будет

для себя дешевле покупать (



драйвер can и подключить его к uart`у так же, как и 485
разница будет в отсутствии "перетягивания каната" при коллизиях

Сам по себе голый CAN особого смысла не имеет, равно как голый RS485. Если CAN, то надо какой-то протокол поверх него. Сразу напрашивается CANopen, фриверная реализация - CanFestival, вот тогда будет красиво и грамотно. А это, по-моему, намного сложнее в освоении, чем RS485 c Modbus RTU, что тоже красиво и грамотно, если достаточно иметь обмен мастер-слэйв и нет амбиций на обмен по принципу producer-consumer и распределенные объекты, как в CANopen. Особенно для человека, который вообще впервые обо всем этом слышит.

нужен внешний драйвер еще

и еще если вы собрались звезду делать то вам не 485 не can не подойдет

ничего кривее, надеюсь, уже не придумают

жаркие споры начались)
Про can я, действительно, первый раз слышу и не работал с ним.

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

Я вживую имел дело с несколькими протоколами, сделанными на порядок хуже, чем Модбас РТУ. Не потому, что их сложнее было реализовать, наоборот, они были намного проще, самопал. Только работали криво, сбоили при помехах. А чего-либо более помехоустойчивого, чем Модбас, для RS485 - не, вживую не встречал. Растопыренных пальцев и голословия на форумах видел много, это да.


Отражения от концов. Лечится снижением скорости до 5..10 kbps и частичным согласованием в центре звезды. Бельгийский VelBus, сделанный на CAN-е, обещает, что кабель можно укладывать вообще как угодно ("свободная топология"), суммарная длина может превышать 1 км. Про скорость у них трудно что-то внятное найти, но наверняка ниже 20 kbps. Свободная топология с кабелями 1 км разрешена в шинах EIB/KNX (9600 бод) и C-bus (5000 бод).

Да тут вообще-то CAN никчему, пмсм. Может даже Dallas 1-Wire подойдёт, но лучше RS-485. Спорить ни с кем не буду.

а некий terminal bus в конце шины установить?
Так звездой получится реализовать у меня? Или крутить петлю по всему дому?
Изучаю modbus.

Если Вы не видите разницы между проколами одии из которых УЖЕ обеспечивает передачу фрейма и адресацию не говоря уже о разрешении коллизий, а второй только передачу одинокого байта и вообще БЕЗ хоть какой-то возможности разрешать коллизии, то это крайне печально. CAN сам по себе обладает самодостаточностью и МНОГО превосходит практически все, что можно натянуть на RS485 в качестве следующих уровней.



Внешним драйвером для CAN контролера может служить все, что угодно, лишь бы доминантный 0 обеспечивало. В пределе, хоть любой "TTL" буфер с третьим состоянием.



Сделать что то еще хуже, несомненно можно. Но хуже Modbus RTU, это уже надо хоть немного, но постараться


Вообще-то Вам наверняка нужна не шина и не звезда. Вам для дома нужно дерево.

В любом случае, сейчас стоит задача прокладки проводов и заложить туда сигнальный кабель.
Думаю, от выключателей вести слаботочный провод сразу к GPIO МК. А сам приемник ставить непосредственно в люстре. Раньше думал в распределительную коробку его встраивать.
Пока просто будет- нажал возвратный выключатель- посадил GPIO на землю, реле включило лампочку. Дальше уже блочок около люстры перешью на что надо. Это чтобы сразу работало, а не ждало меня, пока созрею.
Архитектура построения- дерево- это точно. MODBUS и can поддерживают ее?

Если использовать can- нашел STM32 недорогой с can на борту. Хотите сказать, что 3,3 В уровень сигнала в шине будет достаточно для работы? Это если просто буфер на выход МК поставить.

Вопрос не в протоколе. Вопрос в физике интрефейса. Все зависит от скорости, которую хотите получить. По хорошему, конечно, в узлах сети нужны активные ответвители. Если делать на 485, то цена вопроса активного ответвителя, который может испоьзоваться и как регенератор, - один дополнительный чип приемопередатчика.

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

скорость 19200- просто опрос датчиков и включен ли свет?
длина проводов- 50 метров от центрального щитка. Не думаю, что всё-же дерево будет. Скорее, хотел бы сделать так:
От щитка веду шину к одному контроллеру, от него же к другому, от второго к третьему. Все сидят параллельно.
Дайте практический совет- реально без глюков получить систему подобную, или что поменять надо будет?
Лучше все-же на кан ставить спец. драйвер. Посоветуйте какой под мою задачу.

Ставите обычные 485. На такой скорости и на таких расстояниях можете соединять все как попало.

еще раз- Вы рекомендуете мне RS-485 или can?
Или can, но драйвера 485?

я в шоке от таких утверждений
даже ничего не могу сказать

Для максимально дубового варианта с минимум функций и малой скорости - 485.

CAN не может нормально работать с 485 драйверами. Наоборот, наоборот может.

ок, смотрим и делаем CAN. Мк с поддержкой CAN есть. Чуть позже выложу схему реализации, прокомментируете, и буду проводку закладывать.

не забудьте про гальваническую развязку !!