Дано:
1. 20-30 Ведомых устройств в сети, над ними один Ведущий. Таким образом, логическая топология сети-звезда.
2. Физическая топология сети - один луч витая пара, на луче сидят Ведомые.
3. Время реакции Ведущего на события у Ведомых допустимо до 0,5 с, и наоборот - до 0,5с.
4. Сеть раскидана по площади примерно с квартиру, помехообстановка тоже соответствует примерно жилому помещению.
5. Ведомые питаются от своих SMPS от одной силовой сети 220В.

Инфооборот по этой сети мал:
1. Ведущий спрашивает Ведомого жив или нет.
2. Спрашивает состояние Ведомого(8 бит - максимум).
3. Даёт команду Ведомому(8 бит - максимум).

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

Итак, вопросы:
1. CAN или RS485?
2. Нужна ли в данной физической обстановке опторазвязка Ведомых от витой пары-луча?
3. Какие IC-приёмопередатчики CAN/RS485 <-> UART посоветуете?
4. Я правильно понимаю, что в такой сети можно обойтись RS485 с тайм-слотом в сотню-другую миллисекунд? и чем лучше будет применение CAN?
5. Какие-то наработки из MODBUS тут применимы? при условии, что всё фирмваре я буду делать на ассемблере? система-закрытая, не будет общаться с вне.

Ну, и, обладаю бюджетом, готов рассмотреть готовое решение Сеть<->GPIO, чтобы не делать самому. других дел хватает. Предложения рассмотрю, шлите их, пожалуйста, в личку. но здесь обсуждать не буду. Здесь я хочу обсудить, что быстро, "на коленках", можно сваять мне самому.

1-2. изолированный 485-й
3. те что есть в местном магазине
4. не регламентировано. ка напишете так и будет.
5. с MODBUS вам легче будет вести документацию - как минимум через год протокол вспоминать не надо. Есть библиотеки. Если купить какой-нибудь пром.контроллер с MODBUS сможете всё это объединить.


ключевые слова: MODBUS(если надо), GPIO, DIN-рейка.

имел дело с RS485, могу сказать, почему применил бы его
1. Число ведомых до 32 нагруженных, как подсказывает википедия
2. Опторазвязка никогда лишней не будет, я имел дело с преобразователями RS485<>232 MAX1480, если правильно вспомнил. Древние, дорогие, но с трансформатоной развязкой по питанию и опторазвязкой по передаче данных. Ещё они дубовые, т.е. надёжные.
3. Помехоустойчивость такая, что даже при расположении витой пары вдоль шин питания мегаваттных двигателей с частотным регулированием картина не портилась. Сам осциллографом смотрел.

Трансивер CAN умеет автоматическое переключение направления обмена, а трансивер RS485 - нет. CANOpen умеет PDO, а Modbus - нет. Если подчиненные - датчики, то CAN предпочтительней. Но CANOpen сложнее Modbus.
Видимо пакет управления длиной 8 бит - очень оптимистично. 8 бит - это 8 портов GPIO?

8 бит это байт, пересылаемый по сети.
чую, что надо бы на CAN всё это сделать, дабы было сделано. На 485 там всё ручками просто делается, вроде. MODBUS не нужен, просто навязывается заказчиком и я не понимаю, почему. Там в мире модбасов тьма, накой в эти релизы мне вникать, мне дело сделать надо и потом делать другие дела.

Для "дёргать ножками" в квартире CAN сверхизбыточен. А PDO в данном случае - это процесс ради процесса.


хм, как вариант
7 - всегда один(типа синхронизация)
6 - "0" - запрос состояния, "1" - установка состояния
при установке состояния:
5 - новое лог. сост. GPIO
4-2 - номер GPIO

используем два стоп-бита и контроль чётности.
Получаем ещё два свободных бита. Нехватает для адресации 30 устройств. Да, 8 бит - это оптимистично.
--------------

в данном свете рекомендую просто купить готовое оборудование.

ок, спасибо


продайте, куплю.

Про байт понятно Непонятно назначение этого байта. Байты же сами собой по сети не ходят. Вообще, если не секрет, какое назначение у подчиненных устройств?
Modbus RTU - неформальный стандарт для всякого АСУТП.

Это и есть АСУТП с быстродействием в полсекунды.
Информации в данной сети передавать надо мало, достаточно байта туда-сюда от каждой точки раз в полсекунды.

ну, то есть, что достаточно слота 100мс на 9600 на всёпровсё. 485 и не парицо.

Времена всегда одни и те же?

на 9600 1 байт передается ~1 мс, но у вас будет не 1 байт. Посмотрите описание CAN, либо Modbus. В кадрах для канального уровня присутствует синхронизация и контроль целостности, для сетевого уровня - адрес.
Опять же скорость обмена определяется "задумчивостью" при обработке запроса подчиненным и ответа мастером, таймаутами. Поэтому времена в общем случае будут разные.
А еще для "самодельной" сети существует проблема распределения адресов между подчиненными.

Если хотите чтобы датчики сами (без их опроса со стороны мастера) начинали передачу по какому либо событию, то модбас не подойдет.

Так старый добрый X10 чем не устраивает? И никаких лишних проводов, все по силовой
Получится 100 бит/с, пример реализации на PIC у Микрочипа пылится уже ковырнадцать лет

Ведомые будут передавать по запросу от Ведущего как только "услышат" свой адрес в сети. тайминги, да. Адресов мало, штук 30, остальная часть байта будет командой Ведомому, что передать обратно и что исполнить. Таким образом, достаточно байта для логического обмена(пять бит - адрес 0-31, и три бита - команда 0-7, что достаточно для моего применения)
Конфигурироваться сеть будет "ручками", адреса будут физически прописываться в Ведомые, в прошивки их процессоров.
Я правильно понимаю сей процесс?

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

спасибо за советы.

физическая раскладка сети. сегодня побывал на объекте, позырил, и с "лучём" витой пары вырисовалась такая ситуёвина: луч длиной метров 150-200, подключиться к лучу можно в десятке мест примерно(это уже данность, не изменишь). подключения будут длиной до метров 3-х "звёздочки" такие, мдя.

тут вижу два варианта для себя.

1. на доступном месте разрез луча с установкой розеток на концах, и далее подключаюсь в петлю и сохраняю топологию линии но увеличиваю число контактов в сети.
2. для нужной мне скорости 9600 не морочиться и подключать поинты к точке луча тупо звёздочкой, ибо лишние контакты в электронике - есть зло.

что посоветуете, бывалые в этой теме?

Мнение, мое личное.
1. Только RS-485. CAN значительно менее устойчивый при использовании непонятно как соединенных линий, вплоть до полной неработоспособности. RS-485 в этом смысле неубиваем. И на низких скоростях (ну, скажем, до 19200) работоспособен и без терминаторов и на длинной линии любого качества (не обязательно на витой паре) и на линии любой топологии.
2. Гальваноразвязка обязательна. не дай Бог на разные фазы подключат Ваши датчики, огребете по полной. Дополнительно понадобятся три оптрона и DCDC. Кстати, это позволит не тянуть GND между устройствами, то есть действительно только одна витая пара(два провода). Любой сбой из-за отсутствия гальваноразвязки стоит дороже.
3. Использовать готовый протокол и не изобретать свой с нуля. Это также позволит Вам использовать и средства отладки, которых, например для Модбаса, доступно множество. Плюсов использования ощеизвестного протокола множество, не буду перечислять.
4. протокол для RS485: полудуплексный MODBUS, RTU или ASCII. Мне больше RTU нравится, все сети на нем строю. Но (теоретически) ASCII лучше, если могут возникать непредвиденные задержки в передаче или в приеме (например, при использовании компьютера). На практике оба отлично работают с Виндоусом.
5. Драйвер RS485: любой который понравится, со стандартной промышленной распиновкой 8-пинового корпуса. Только обратите внимание на ток потребления в режиме "без нагрузки"("No load supply current"): есть серии, у которых он десятки миллиампер (например, SN65176B - около 30 мА), лучше использовать с током около 1 мА (ST485, ADM485 и т.д)
6. Про ограничение в 32 устройства в сети- это для драйверов со стандартным сопротивлением приемника (12 кОм). Сейчас есть очень много микросхем драйверов, позволяющих расширить сеть до 256 устройств (но тут уже может ограничивать используемый протокол).
7. Про прошивку адреса: если есть место и возможность, заложите джамперы для возможности конфигурирования адреса вручную. Эксплуатационщики Вам за это спасибо скажут. Или ну хоть один джампер, при установке которого устройство будет в дефолтном состоянии (ну, например, адрес 1, скорость 9600).

Большое спасибо. Особенно ценно для меня замечание №1.