Самодельная шина команд/данных для управления домашними устр | |||
|---|---|---|---|
| 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 |
Наверное имеется в виду такой вариант?
|
||
| 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 |
Ану, Рома, - тряхни стариной! |
||
| -20 dB 02/12/2011 19:16 |
Дык здесь-то она кому нужна? Рисовать долго, а делать же на дискретной логике никто же не будет. Да и знаком этот алгоритм телевизионщикам, ибо часто в ДУ применялся (а может, и до сих пор применяется - я несколько выпал из новых веяний, посему не в курсе). |
||
| goga_tv 02/12/2011 19:22 |
она продемонстрирует процессы, кот. происходят во внутрях черных ящиков! Очень поучительно... Молодежь уже не представляет процессов , кот. происходят в БИСах... А нам трудно изучить программирование , а может просто лень?... |
||
| Cлесарь 02/12/2011 22:13 |
|
||
