Позавчера, скоротал время и дорабатывал устройства домашней автоматики. Конкретно, этот проект.
В данном проекте, такие устройства, как пульты управления, главный модуль и исполнительные модули, подсоединены паралельно одной общей шины питания/управления, состоящей из трех проводов (+, -, данные).
Питаются устройства от проводников питания с нестабилизированным напряжение 12V ... 15V. По третьему проводу передается информация, по типу как шина 1-wire. Протокол самописный, но в плане тактирования шины и последовательного выставления уровней в проводе очень похож на 1-wire. Только тактирование на порядок реже, импульсы десятикратно длительней, сделано, чтоб не ставить кварцы в исполнительные устройства и МК успл. устр. справлялся с длительностью импульсов.
Напряжение в информационном проводе так же, нестабильно, притянуто к плюсу общего питания.
Поставил контроль достоверности данных методом дублирования и сверки данных. При передаче, устройство передатчик повторяет одни и теже данные дважды, а устройство приемник данные сверяет, если обнаруживается несоответствие, подается сигнал и сообщение на дисплей. Периодичность посылки пакета команд/данных две в секунду.
Тестировал так устройства я в течении длительного времени, статистика такова, сбои в передачи данных происходят в среднем раз в пол-часа, иногда реже, раз в час. Команды естественно выполняются правильно, так как ошибки отлавливаются и происходит повтор команды, но есть два вопроса:
1. нормально ли появление ошибок в неэкранированном проводе висящем в воздухе с такой частотой как у меня? Точнее, провод висит за гипсокартон стеной, а устройства монтируются в стену. Кое где провод проходит в штукатурке. Общая длина чуть более 10 метров. Может стоит еще поработать над эл. схемой и снизить вероятность ошибок? Низкий уровень на шине < 5V. Высокий уровень >8V.
2. Правда ли, что метод дублирования данных и последующей сверки хуже, чем какие-либо традиционные протоколы?
Контроль четности байта при посылке по одному проводу, по моему, не применим. Если импульс помехи "затрет" сразу два бита в цепочке бит составляющих байт, этот байт пройдет проверку четности, бедут приняты неверные данные.
Думаю, как у меня, методом дублирования, как говорится, "молния в одно и тоже место не ударяет дважды" вероятность подмены бит и прохода контроля маловероятна. В крайнем случае, можно трижды передавать одинаковые байты и сверять сразу три при проверке.
Как думаете?
Вот, к примеру на столе пульт и основной блок соединены тремя проводниками.
Перед двухбайтной посылкой вида - идентификатор+команда, мастер закорачивает линию для сброса в течении 100 мксек. Ведомый зарегистрировав событие сброса, начинает прием данных вида - идентификатор+команда. Проверяет идентификатор (сравнивает со своим) и запоминает переданную за идентификатором команду. Снова ожидает событие сброса и повторения посылки вида - идентификатор+команда.
Если дважды ведомый принял одинаковую команду, значит команда верна. Ведомый выполняет эту команду и отчитывается мастеру посылая ответный байт, код выполненной команды.
Скорости хватает. Там и так команды чаще 2 раза в секунду не посылаются. Этож для бытовой автоматики, зажечь лампочку или потушить ее. Проверить температуру водички и ее уровень. Включить эл. клапан или отключить. По этому и сделано всего два байта одна посылка, удрес устройства и команда. Когда требуется подтверждение, это три байта, Адрес, команда, ответные данные. Теперь я расширяю дублированием для проверки истинности данных. CRC при таком малом количестве данные одного посыла наверное неприменим.
Когда по линии передается текст для дисплея, после байта адреса устройства и байта команды вывода на дисплей, посылается серия символьных байт определенной длины, в моем случае 16, но целостность этих данных меня сейчас сильно не беспокоит, в будущем думаю просто ввести 17-й байт с контрольной суммой, для текстовых данных.
Э-э-э-ммм... А можно мне со своим ламерским пятачком встрять (бо не программист есмь)?
А чем плох вариант мажоритарного подтверждения команды, когда команда принимается к исполнению, только если повторяется три раза подряд без ошибок? Вряд ли смогу правильными терминами описать (тем более, изобразить алгоритм), но на пальцах выглядит примерно так: посылка, принятая приёмником, помещается в регистр стека, "вытесняется" выше следующей посылкой, потом обе ещё раз вытесняются третьей посылкой. Значения регистров сравниваются побитово, и только при совпадении всех трёх слов формируется команда к исполнению. Т.е, если, например, второе слово принято с ошибкой, потребуются ещё два повтора команды БЕЗ ошибки, пока ошибочное значение не будет вытеснено из стека. Не смогу нарисовать алгоритм, но могу нарисовать реализацию подобной логики на "развесухе".
Дык здесь-то она кому нужна? Рисовать долго, а делать же на дискретной логике никто же не будет. Да и знаком этот алгоритм телевизионщикам, ибо часто в ДУ применялся (а может, и до сих пор применяется - я несколько выпал из новых веяний, посему не в курсе).
она продемонстрирует процессы, кот. происходят во внутрях черных ящиков! Очень поучительно... Молодежь уже не представляет процессов , кот. происходят в БИСах... А нам трудно изучить программирование , а может просто лень?...
Я не пользовался термином СТЕК со времен программируемых калькуляторов. С влучае дублирования просто для данных есть временные переменные, а как это будет выглядеть на уровне процессора остается тайной. Мир меняется
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах Вы не можете добавлять файлы Вы можете скачивать файлы
Лучше уж обещанную схемку на рассыпухе бы набросал. 
Ваши права в разделе