Как лучше организовать протокол (логический) для RS-485 Опции

[Diusha]

На главный блок должна стекаться инфа с нескольких периферийных.
Есть такие варианты:
1) Каждый периферийный посылает данные (по мере их готовности) и в теч. нек. времени ждет подтверждение от главного. Если подтверждения нет, посылает еще раз. Если случайно 2 периферийных пошлют одновременно, то контрольная сумма не совпадет -> не будет подтверждения -> повтор.
2) Главный постоянно периферийным шлет запросы. Если у периферийного данные готовы, то он посылает.

Вроде оба варианта имеют право на существование, но чего-то не нравятся. Может предложите получше варианты или есть решения, проверенные временем?

[Сергей Борщ]

1) Каждый периферийный посылает данные (по мере их готовности) и в теч. нек. времени ждет подтверждение от главного. Если подтверждения нет, посылает еще раз. Если случайно 2 периферийных пошлют одновременно, то контрольная сумма не совпадет -> не будет подтверждения -> повтор.

А как он узнает, что в этот момент канал свободен и он своей передачей никому не помешает?

[Diusha]

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

А как он узнает, что в этот момент канал свободен и он своей передачей никому не помешает?

Если случайно 2 периферийных пошлют одновременно, то контрольная сумма не совпадет -> не будет подтверждения -> повтор.

Дело в том, что передачи относительно редки => вероятность коллизии невысока. Коллизии разрулятся с помощью контрольной суммы. Прослушивать ничего не надо.
2-й вариант смущает тем, что линию придется держать занятой на несколько порядков бóльшее время (лишние помехи), т.к. главный должен получить данные быстро => запросы придется слать с большой частотой.

Если вам нужен именно первый вариант, то переходите на CAN.

САN - в следующий раз, сейчас железо сделано под 485

Какие будут советы в свете моих уточнений? Может есть еще какой-нибудь 3-й вариант?

[Сергей Борщ]

Дело в том, что передачи относительно редки => вероятность коллизии невысока. Коллизии разрулятся с помощью контрольной суммы.

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

[Ruslan1]

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

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной.

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

так что производители гарантируют.

[Сергей Борщ]

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной.

У Sipex в даташитах специфицирован только ток КЗ по выходу и макс. рассеиваимая мощность корпуса. Про коллизию не нашел ни в одном даташите. Есть защита от КЗ, но это как бы совсем не коллизия.
Обходите.

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

так что производители гарантируют.

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

[Diusha]

включите драйвера RS-485 так, чтобы они только 0 передавали, а 1 за счёт резисторных растяжек формировалась.

А не знаете, нет ли микосхемки, совместимой по выводам с МАХ485, только с открытым коллектором?

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной.

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

Из портянки на МАХ485:
"Drivers are short-circuit current limited and are protected against excessive power dissipation by thermal shutdown circuit"
Провел эксперимент: замкнул А и В. Секунд через 7 микросхема (в ДИПе) нагрелась градусов до 45, дальше температура не росла; thermal shutdown не было; ток 100 мА.
Не лучший вариант...

Из той же портянки:
"The receiver input has a fail-safe feature that guarantees a logic-high output if the input is open circuit."
Я правильно понял, имеется в виду, что если линия болтается в воздухе, то "фича гарантирует", что на выходе приемника болтанки не будет? Но тогда непонятно, как фича догадается, что это наводки, а не сигнал?

[galjoen]

А не знаете, нет ли микосхемки, совместимой по выводам с МАХ485, только с открытым коллектором?

Это стандартный драйвер CAN. Насчёт совместимости по ногам - смотрите сами. Но так-то ничего не мешает использовать его вместо драйверов RS-485. Всё будет работать абсолютно так-же, только терминаторы в этом случае обязательны. Ещё можно приёмником USART слушать линию во время передачи, и если принятое будет отличаться от переданного - коллизия. Собственно всё так же, как при включении драйверов RS-485 по стандарту J1708 - CAN оттуда и произошёл. Кстати, не удивлюсь, если и модбас оттуда - и протокол и времянки то очень похожи. Только модбас не мультимастерный.

А вообще, закладывать модбас в новую разработку, ИМХО это не есть гуд.