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