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

[Diusha]

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

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

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

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

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

[Diusha]

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

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

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

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

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

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

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

[rezident]

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

Это вы так думаете. "Человек предполагает, а Господь располагает" Я с ходу могу предложить ситуацию в которой будет коллизия, которую разрулить будет весьма сложно. Представьте, что на контролируемом объекте произошла авария и все устройства с этого объекта пытаются одновременно передать информацию об аварийном событии.

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

"Быстро" это не технический термин. Укажите скорость обмена, количество передаваемой информации, количество узлов и максимально допустимое время отклика.