Как лучше организовать протокол (логический) для 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 оттуда и произошёл. Кстати, не удивлюсь, если и модбас оттуда - и протокол и времянки то очень похожи. Только модбас не мультимастерный.

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

[Itch]

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

чем не угодил модбас?
для простых устройств самое то, любой студент напишет его на любом контроллере.

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

Терминаторы да, обязательны. Нетерминированый отрезок кабеля в 50м намертво убивал передачу на 19200.