Самодельная шина команд/данных для управления домашними устр

Cлесарь
01/12/2011 11:07
Позавчера, скоротал время и дорабатывал устройства домашней автоматики. Конкретно, этот проект.
В данном проекте, такие устройства, как пульты управления, главный модуль и исполнительные модули, подсоединены паралельно одной общей шины питания/управления, состоящей из трех проводов (+, -, данные).
Питаются устройства от проводников питания с нестабилизированным напряжение 12V ... 15V. По третьему проводу передается информация, по типу как шина 1-wire. Протокол самописный, но в плане тактирования шины и последовательного выставления уровней в проводе очень похож на 1-wire. Только тактирование на порядок реже, импульсы десятикратно длительней, сделано, чтоб не ставить кварцы в исполнительные устройства и МК успл. устр. справлялся с длительностью импульсов.
Напряжение в информационном проводе так же, нестабильно, притянуто к плюсу общего питания.
Поставил контроль достоверности данных методом дублирования и сверки данных. При передаче, устройство передатчик повторяет одни и теже данные дважды, а устройство приемник данные сверяет, если обнаруживается несоответствие, подается сигнал и сообщение на дисплей. Периодичность посылки пакета команд/данных две в секунду.
Тестировал так устройства я в течении длительного времени, статистика такова, сбои в передачи данных происходят в среднем раз в пол-часа, иногда реже, раз в час. Команды естественно выполняются правильно, так как ошибки отлавливаются и происходит повтор команды, но есть два вопроса:

1. нормально ли появление ошибок в неэкранированном проводе висящем в воздухе с такой частотой как у меня? Точнее, провод висит за гипсокартон стеной, а устройства монтируются в стену. Кое где провод проходит в штукатурке. Общая длина чуть более 10 метров. Может стоит еще поработать над эл. схемой и снизить вероятность ошибок? Низкий уровень на шине < 5V. Высокий уровень >8V.

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

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

Как думаете?

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



Уже это хозяйство вмонтировано в стены.







Dmitry Dubrovenko
01/12/2011 21:26
Если у Вас типа 1-Wire, так почему бы не организовать "эхо".
По-моему, будет самая лучшая защита от ошибок.

Cлесарь
01/12/2011 21:47
Наверное имеется в виду такой вариант?

Цитата:
Перед двухбайтной посылкой вида - идентификатор+команда, мастер закорачивает линию для сброса в течении 100 мксек. Ведомый зарегистрировав событие сброса, начинает прием данных вида - идентификатор+команда. Проверяет идентификатор (сравнивает со своим) и запоминает переданную за идентификатором команду. Снова ожидает событие сброса и повторения посылки вида - идентификатор+команда.
Если дважды ведомый принял одинаковую команду, значит команда верна. Ведомый выполняет эту команду и отчитывается мастеру посылая ответный байт, код выполненной команды.


Dmitry Dubrovenko
02/12/2011 07:51
Ну, типа того. улыбка
Только зачем тогда два раза посылать-то? 1-Wire и так интерфейс не быстрый, а Вы его ещё на порядок замедлили.

Cлесарь
02/12/2011 14:24
Скорости хватает. Там и так команды чаще 2 раза в секунду не посылаются. Этож для бытовой автоматики, зажечь лампочку или потушить ее. Проверить температуру водички и ее уровень. Включить эл. клапан или отключить. По этому и сделано всего два байта одна посылка, удрес устройства и команда. Когда требуется подтверждение, это три байта, Адрес, команда, ответные данные. Теперь я расширяю дублированием для проверки истинности данных. CRC при таком малом количестве данные одного посыла наверное неприменим.
Когда по линии передается текст для дисплея, после байта адреса устройства и байта команды вывода на дисплей, посылается серия символьных байт определенной длины, в моем случае 16, но целостность этих данных меня сейчас сильно не беспокоит, в будущем думаю просто ввести 17-й байт с контрольной суммой, для текстовых данных.

-20 dB
02/12/2011 17:04
Э-э-э-ммм... А можно мне со своим ламерским пятачком встрять (бо не программист есмь)?

А чем плох вариант мажоритарного подтверждения команды, когда команда принимается к исполнению, только если повторяется три раза подряд без ошибок? Вряд ли смогу правильными терминами описать (тем более, изобразить алгоритм), но на пальцах выглядит примерно так: посылка, принятая приёмником, помещается в регистр стека, "вытесняется" выше следующей посылкой, потом обе ещё раз вытесняются третьей посылкой. Значения регистров сравниваются побитово, и только при совпадении всех трёх слов формируется команда к исполнению. Т.е, если, например, второе слово принято с ошибкой, потребуются ещё два повтора команды БЕЗ ошибки, пока ошибочное значение не будет вытеснено из стека. Не смогу нарисовать алгоритм, но могу нарисовать реализацию подобной логики на "развесухе".

viktor_ramb
02/12/2011 17:33
-20 dB,
Цитата:
Не смогу нарисовать алгоритм, но могу нарисовать реализацию подобной логики на "развесухе".

" ... нутром чувствую что будет литр, но математически ..." смех подмигивание

-20 dB
02/12/2011 18:29
viktor_ramb, вот ты прямо привередливый. Так прямо и надо картинку выпросить... Ну, на. Уж как умею.
Цитата:
" ... нутром чувствую что..."
...публиковать сей великоламерский экзерсис не стоило, но таки надо ж доказать, шо ежели не умею, так на пальцАх понятнее получается:
подшучивать, дразнить

viktor_ramb
02/12/2011 18:38
-20 dB,
Цитата:
вот ты прямо привередливый. Так прямо и надо картинку выпросить...

За дело болею - таблетки не помогают, только визуальная конкретика, поможет ли она ТС? хммм... Лучше уж обещанную схемку на рассыпухе бы набросал. классно!

goga_tv
02/12/2011 19:11
viktor_ramb писал:
-20 dB, .. Лучше уж обещанную схемку на рассыпухе бы набросал. классно!

браво! браво! браво!
Ану, Рома, - тряхни стариной! подмигивание

-20 dB
02/12/2011 19:16
Дык здесь-то она кому нужна? Рисовать долго, а делать же на дискретной логике никто же не будет. Да и знаком этот алгоритм телевизионщикам, ибо часто в ДУ применялся (а может, и до сих пор применяется - я несколько выпал из новых веяний, посему не в курсе).

goga_tv
02/12/2011 19:22
-20 dB писал:
Дык здесь-то она кому нужна?

она продемонстрирует процессы, кот. происходят во внутрях черных ящиков! Очень поучительно... Молодежь уже не представляет процессов , кот. происходят в БИСах... А нам трудно изучить программирование , а может просто лень?...

Cлесарь
02/12/2011 22:13
-20 dB писал:
помещается в регистр стека,
Я не пользовался термином СТЕК со времен программируемых калькуляторов. С влучае дублирования просто для данных есть временные переменные, а как это будет выглядеть на уровне процессора остается тайной. Мир меняется

liveinternet.ru RadioTOP Rambler's Top100 –ейтинг@Mail.ru