Связь RS485 Multimaster с предотвращением столкновений

Предотвращение столкновений — сложная тема. Полностью избежать столкновений невозможно. Всё, что можно сделать, — это научиться а) обнаруживать их и б) восстанавливаться после них.

Существует множество различных способов сделать это, и то, как вы это реализуете, во многом зависит от возможностей вашего оборудования и того, как вы фактически используете протокол.

Лучший способ обнаружения коллизий — организовать так, чтобы ведущее устройство постоянно считывало данные с шины, даже во время передачи. Для этого требуются отдельные приёмный и передающий модули, чтобы при отправке байта на шину вы также пытались принять его. Если байт не принимается или принимается неверный байт, происходит коллизия.

Это 100% гарантированный способ обнаружения коллизии в момент её возникновения. Если вы знаете, что отправленный вами пакет не дошёл до сети должным образом, значит, произошла коллизия.

Более простой способ — наблюдать за автобусом перед отправкой. Если в течение определённого времени нет никаких признаков движения, можно предположить, что автобус в данный момент тихий. Затем можно попробовать отправить данные. Однако вы не знаете, дошли ли данные успешно, поскольку что-то другое могло решить, что автобус достаточно долго был тихим, чтобы отправить данные.

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

Что делать при обнаружении коллизии (или отсутствии подтверждения) тоже довольно сложно. Приходится подождать и повторить отправку. Но если два устройства ждут повторной отправки, как можно быть уверенным, что они не будут ждать одновременно и не столкнутся снова?

Необходимо убедиться, что оба устройства задерживаются на случайный период, и что этот период действительно является случайным. Использование функции random() по умолчанию, если только вы не можете использовать для её создания действительно случайный источник энтропии, сгенерирует одинаковую последовательность чисел для всех устройств, так что каждое устройство получит одно и то же «случайное» число. Это приводит к коллизиям.

Так что, как видите, вы не можете просто взять и взять любую библиотеку и сказать: «Эта библиотека предотвратит коллизии». Лучшее, что вы можете сказать: «Эта библиотека поможет уменьшить количество коллизий, обнаружить их, когда они происходят, и корректно восстановиться после них».

Похоже, что библиотека, на которую вы ссылаетесь, пытается реализовать последнюю систему:

• Предотвращение коллизий реализуется путём назначения приоритета сообщениям. Узел не начнёт передачу, пока шина не будет простаивать в течение времени, определяемого приоритетом. Обратите внимание, что наивысший приоритет присваивается сообщениям с наименьшим номером приоритета.

• Обнаружение коллизий реализовано по принципу «чтение-проверка-запись», то есть все записанные данные проверяются «на лету» на корректность эхо-ответа. Если программа обнаруживает ошибку кадра или несоответствие данных при получении эхо-символа, она отключает передачу по RS485 и отмечает состояние коллизии. Встроенная функция управления транзакциями повторно отправит сообщение после того, как шина снова станет свободной.

Он ждет, пока шина освободится от трафика в течение определенного периода времени (время варьируется в зависимости от приоритета сообщения), и ожидает, что сообщение будет отправлено обратно в форме ACK.

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