Баллада О Передаче Данных

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

Стандартные интерфейсы передачи информации — это здорово, но для моих нужд они не обеспечивают достаточную (или почти) передачу данных.

Постараюсь внести некоторые дополнения, чтобы довести его до состояния, которое меня устраивает. На достаточно большом расстоянии (1-100 метров) находятся 2 и более устройств, между которыми необходимо передавать данные.

Изучив некоторые интерфейсы (rs232/422/485, I2C, Ethernet) я пришел к выводу, что они либо не гарантируют однозначную передачу данных, также мне не понравилось много проводов, они не дают ответа, что информация был получен.

За основу решил взять интерфейс RS485 - одно из его преимуществ - он может "идти далеко", 2 провода, можно одновременно подключить кучу устройств, все просто, (UART) есть практически на любом контроллер.

В моем случае мне подходит классическая схема 1 мастер а остальные слейвы.

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

Баллада о передаче данных

Один цикл обмена.

Чтобы удовлетворить мои потребности в передаче данных, необходимо решить только две проблемы.

Вопрос первый: проверка передаваемого байта осуществляется на основе самого интерфейса RS-485, но она не гарантирует надежно переданного байта - если в самом интерфейсе обнаруживается поврежденный байт, он выбрасывается из полученных данных, но он еще можно передать неправильный байт - если в нем изменилось (испорчено) чётное количество бит в байте.

те.

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

Вопрос второй: получение ответного сообщения на переданное.

По первому вопросу: предлагается следующая схема: стартовый байт, количественный байт. передаваемые символы во всем сообщении, что-то еще, байт контрольной суммы (BCS), конечный байт.

Баллада о передаче данных

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

В этом случае возможны варианты, когда поврежденное сообщение доходит до слейва и он на него не отвечает, либо сообщение доходит до него и он отправляет ответ, но ответ испорчен и лидер его игнорирует. Чтобы это исправить, было решено: если ответ не приходит (или приходит, но ненадежно), то повторить текущий цикл обмена еще раз (без маразма несколько раз).

Здесь может возникнуть следующая ошибка.

Допустим, мы отправляем команду, сообщающую устройству, что нам нужно увеличить громкость на +1 единицу.

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

В результате при поступлении команды на ведомой стороне громкость будет увеличена уже на +2 единицы.

Чтобы избежать этого явления, принято вводить идентификатор (NS — номер сообщения) для разницы между сообщениями.

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

Сюда же ввожу еще 2 параметра - это номер (код) устройства, на которое передаются данные и номер (субкод), указывающий, какую команду следует выполнить (или какие данные находятся внутри сообщения).

Баллада о передаче данных

В итоге соберу все воедино и пройдусь по алгоритму на примере увеличения значения порога температурного реле на 5 градусов Цельсия и снятия текущих показаний температуры с ведомого устройства за 1 цикл обмена: Генерирую передаваемые данные от лидера:

Баллада о передаче данных

При получении сообщения слейв смотрит 2 байта, где количество отправленных байт, если количество отправленных байт равно количеству полученных байт, то сообщение не потеряло ни одного байта, тогда смотрим начальные байт (символ), если он = '$', а также конечный байт (символ), если он = '#' - то это сообщение от мастера к слейву.

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

Оговорюсь, что из 3-х значений параметров я буду считать 2 и 3 правильными, т.е.

при совпадении 2-х из 3-х возможных параметров я считаю сообщение валидным.

1. начальный байт = '$', количество полученных байт = 7 (количество отправленных байт = 7), конечный байт не равен '#'; 2. начальный байт не равен '$', количество полученных байт = 7 (количество отправленных байт = 7), конечный байт = '#'; 3. начальный байт = '$', количество полученных байт = 7 (количество отправленных байт = 7, количество байт не равно 7), конечный байт = '#'.

Далее вычисляем контрольную сумму оставшихся 3-х байт (байты 3, 4, 5), если она совпадает с BCS, продолжаем парсить данные, смотрим, относятся ли эти данные к этому устройству и что с ними нужно сделать, в нашем случае код ведомого устройства 55 и субкод 2 говорит о том, что нужно добавить еще 5 градусов к порогу срабатывания реле и отправить текущие данные о температуре в ответном сообщении.

Проверяю НС, если он не равен номеру предыдущего сообщения, то выполняю команду и добавляю 5 градусов к текущему значению порога срабатывания реле.

Если они равны (NS), то указанные действия не выполняю, то приступаю к формированию ответного сообщения.

использование схемы ['$'][количество отправленных/полученных байт][.

]['#'] - с большой вероятностью гарантирует, что такая комбинация не может быть найдена в передаваемых данных и не спровоцирует ложное сообщение.

Генерирую передаваемые данные от слейва на основе полученного сообщения:

Баллада о передаче данных

Принцип обработки следующий: смотрим 2 байта, где указано количество отправленных байт, если количество отправленных байт равно количеству полученных байт, а также начальный байт = '@' и конечный байт = '&' - тогда это сообщение от слейва мастеру.

При необходимости использую механизм 2 из 3, аналогичный описанному выше, только для ответного сообщения (для символов «@» и «&»).

При получении этого сообщения мастер анализирует контрольную сумму 9 (с 3-го по 11-й) байт; если контрольная сумма совпадает, данные в сообщении считаются достоверными и дальнейший анализ данных продолжается.

Если код, субкод и NS отправленного и полученного сообщения совпадают, продолжаем анализировать ответ на сообщение, отправленное лидером.

Далее идет анализ полученных данных, в моем случае в 6-м байте значение 1 говорит о том, что команда на добавление 5 градусов к порогу реле выполнена успешно, остальные 5 байт обозначают текущие показания температуры, 7-й байт - это флаг, указывающий достоверность передаваемой температуры (т.е.

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

Использование 2-х контрольных символов в начале и конце сообщения скорее всего гарантирует в случае ошибки не перепутать сообщения от ведомого и ведущего устройства.

Также случайные (не случайные) данные в канале не испортят обмен.

Немного о передаче данных от слейва к слейву и централизованном сообщении всем слейвам от мастера.

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

присвоить устройству код 254 и по этому коду 3 или 4 устройства получат сообщение, остальные его проигнорируют, естественно часть по отправке ответов от ведомых устройств здесь работать не должна - т.е.

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

Опять же нет никакой гарантии однозначной доставки сообщения от слэйва1 к слэйву2, это надо учитывать! Возможности интерфейса Количество теоретически подключаемых устройств — около 250, типов команд/данных — до 248 для каждого устройства, длина полезной информации в сообщении — до 250 байт. Давайте поговорим о подводных камнях: Вся передача данных рассчитана на временной принцип, т.е.

должны соблюдаться определенные задержки между сообщениями.

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

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

Отдельно хотелось бы выделить вопрос временной синхронизации устройств - следует учитывать, что временная синхронизация ведомого устройства при приеме сообщения требует учета временных задержек отправки данных в канал (на скорости 9600 , сообщение размером 10 байт будет передано примерно за 11 мс) и момент срабатывания прерывания в конце важен при получении данных на ведомой стороне, если прерывания нет, то стоит учитывать время его требуется для проверки поступления данных в буфер устройства и т.д. Также стоит отметить, что повторная отправка цикла сообщений тоже добавляет нюансов; Рекомендую использовать синхронизацию времени, чтобы отправлять сообщения без повторов, и генерировать сообщения с новым NS. P.S. У меня есть сомнения, что я открыл здесь что-то новое; все это в той или иной степени используется где-то в разных интерфейсах! С легкой руки автора данной статьи и использования данного протокола в своих разработках я хочу дать этому протоколу передачи данных название «SRDB2».

Теги: #Электроника для начинающих #программирование #разработка #интерфейсы #Профессиональная литература #сделай сам #rs485