Здравствуйте!
Я сделал эл. схему и создал протокол передачи данных по одному проводу. По типу протокола 1-wire. Напряжение питания устройств на шине 15V. Высокий уровень> 10V. Низкий уровень < 5V. Расстояние между устройствами, ведущим и ведомым, несколько метров. Больше месяца намеренно не делаю никакого контроля достоверности информации передаваемой по шине, получил такую статистику: в среднем, раз в час происходит сбой достоверности преданных данных, почемут, особенно в ночное время.
Данные в размере двух байт, передаются от ведущего к ведомому (двубайтная последовательность, адрес и команда) с частотой двух посылов в секунду. Ведомый принимает два байта и немедленно отвечает ведущему одним байтом, отвечает продолжая передачу ведущего. Тактовая частота последовательности передаваемых бит - 100 Гц.
Нормальная ли это статистика ошибок для однопроводной шины по типу 1-wire? Грубо говоря, провод висит в воздухе и не будет экранирован.
Планирую как-то ввести контроль достоверности, на стороне ведомого, для переданных мастером адреса ведомого устройства на шине и команды. На стороне мастера сделать проверку достоверности ответа ведомого.
Если у кого-нить есть опыт, подскажите, как лучше в данной схеме реализовать контроль? Может просто ведущему дважды посылать запрос и сравнивать два ответа ведомого? Ведомому сравнивать два запроса ведущего? Как говорится, молния не попадает дважды в одно место.

Как минимум нужно использовать контроль четности, а лучше - CRC8, как это сделано в тех же DS18B20. Еще можно для повышения помехоустойчивости увеличить ток в линии.

Для контроля четности читать собственно нечего. Мастер передает байт идентификатор устройства и следом за ним байт команду. Суммировать эти два значения и сравнивать с третим байтом четности?

В данный момент сделал двойную передачу мастером ID устройства и команду, если дважды ведомый принимает одинаковую команду, команда принимается ведомым. Если ведомый принял команду, то продолжает принятую от мастера последовательность двух байт, ответным байтом равным значению байта команды мастера. Мастер получив такой ответ от ведомого, фиксирует, что команда успешно принята ведомым. Что-то мне подсказывает, что данный способ надежней простого контроля четности.

Как сделано в DS18B20 изучаю.

Нет, снабдить каждый байт своим битом четности, как это сделано в UART. Бит четности, кодирование по Хеммингу, CRC8 - обязательно должен быть механизм контроля корректности посылок.



Сложно, надумано и ненадежно. Почитайте у того же Тутевича про помехоустойчивое кодирование. Или хотя бы про код Хемминга у Калабекова. Это ведь не зря все придумали и обосновали:


http://lord-n.narod.ru/walla.html

Я думал все эти биты четности для уменьшения количества передаваемых контролируемых бит. Выше скорость передачи.
А если скорость передачи не принципиальна, что может быть надежней повторения передачи и сравнения двух, а то и трех, переданных данных.

А если из-за обрыва или КЗ на линии вы трижды получите вполне допустимые посылки вида "0xff" или "0x00", что вы станете делать ? А если вход чувствительного приемника повиснет в воздухе, и вы постоянно будете получать "0x55" или "0xAA", тоже формально вполне допустимые ?

прямой код и инверсный

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

Разве что-либо может быть надежней?

Тактирует шину мастер(ведущий), ведомый передает данные по тактам ведущего, как и DS18B20

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



Делайте. Игнорируйте разработанную до вас теорию, тысячекратно проверенную и десятилетиями используемую. Набивайте шишки. Только потом не жалуйтесь, что ничего не работает ...

дублирование и резервирование изобрели до нас

Не будем продолжать этот бессмысленный спор. Я стою на том, что изобретать новые способы помехоустойчивой передачи данных, не изучив того, что разработано до вас (не изучив из-за простого нежелания изучить), по меньшей мере не совсем разумно ...

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

У меня нет времени детально продумывать описанный вами протокол. Лично мне видятся как минимум связанные с повторениями проблемы распознавания границ посылок - можно запутаться, что и к чему относится. Еще раз. Ничего изучать не надо. Просто настройте ваш МК на работу с битом четности, и все. На проходящие контроль четности посылки отбрасывайте. Проще едва ли можно придумать ...

Но насколько мне известно при контроле четности обнаруживается лишь какой-то процент ошибок или я что-то не понимаю. Двойная ошибка в байте ведь может пройти контроль четности?

Байт информации по одной линии, это последовательность 8 переданных бит. Если в середине передачи байта пройдет импульс помехи длиной в два бита, как понимаю байт может пройти контроль четности как истинный. Четность ведь не нарушится?

Да, двойные ошибки так не обнаружишь, но ведь и ваша схема неидеальна. В обоих байтах нарушится первый разряд. Что тогда ? Или из-за обрыва вы примете одни нули или одни единички ? Вы попробуйте, вполне возможно вам контроля четности и хватит. А еще очень советую увеличить передаваемый в линию ток ...

нет. для 1wire шины в пром зоне = одна, две ошибки на часы, дни работы - сто пудово... при правильном передатчике и приёмнике (аппаратной и программной части). интенсив где то 10-20 байт в секунду...

мне кажется, что надо копать в сторону детекции уровней. т.е. тут предлагают увеличить токи - вот это мне кажется ближе(при исправной логике софта), к истине. в 1wire там всё таки ноль играет бОльшую роль чем может показаться. это и помехоустойчивость так же...

удачи вам
(круглый)

Если линия закорочена или оборвана, ничего не пойдет, необходимо вначале получить правильный ID устройства, это не 0ч00 и не 0XFF.
Если нарушится первый разряд в обоих байтах дублированной команды, ведомому тогда вся надежда, что на стороне ведущего есть соответствующий обработчик. Ведомый то отсылает обратно код принятой команды, дабы ответить мастеру какая команда реально была выполнена. Если несоответствие, надо выходить в безопасный режим аварии или еще как реагировать, просто повторить команду.


Биты по шине передаются в точности как 1-wire, только у меня частота на порядок ниже, для поддержания тактовой частоты 1-wire контроллер приходится дополнять кварцем, как минимум 8 мГц. У меня сейчас используется внутренний генератор контроллера 4 мГц.

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

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

Только сейчас вспомнил, у меня на компьютере Радио РК-86, при загрузке программы с магнитной ленты проверялась контрольная сумма байт загруженной программы, что удивительно, иногда контрольная сумма сходилась, а программа выдавала глюки, например подмена символов. Загружал заново. Наверное это совсем редкое явление, но тоже возможно.
Изучаю варианты контроля данных

Слесарь, где-то на форуме встречал утверждение, что разрабатывать свой протокол (канальный уровень модели OSI) еще вполне допустимо, хотя и готовых немеряно ( WAKE, SLIP, MODBUS...), но создавать свой физический интерфейс (нулевой уровень модели) нужно только тогда, когда есть весомые требования. Можно поинтересоваться, есть ли они у Вас? Почему бы не воспользоваться готовым 1-wire. Там и интерфейс и протокол.

По поводу контроля ошибок. Предлагаю crc8. Считается аналитически (медленно) и таблично (быстро). Если вероятность обнаружения ошибки не устраивает, есть crc16/32.

это откуда вот такое(8мГц)?
помню на 51 серии (выполнение команд = 2мГц) работает до сих пор на ура в нескольких странах мира...


Можно и ниже 1мГц(но задачи в фоновом режиме - придёться извращаться, чтоб крутить)... мастер можно вплоть до 200 кГц думаю опускать. другое дело, что интенсив мелкий получится по данной шине...

(круглый)

Там, возможно, использовалась простейшая сумма по модулю "2", а не CRC

Все равно приходится самому обработчик протокола писать, если это не под готовое ведомое устройство, то можно и свой пртокол, заодно на практике видно все слабые места в технике передачи данных.
Собственно своего там мало, принцип синхронизации и выставления бит на шине, как и 1-wire. Питание только 12 ... 15V чтоб работало и от аккумулятора и от БП.
Все устройства на шине самодельные.


Тактирующий импульс 1-wire 6 мкс. с используемыми мной контроллерами и средой программирования при 4 мГц реализовать крайне сложновато. По крайней мере, мне не удавалось. Просто ставлю кварц 8 мГц.

да ладно сложно.
1) 6uS = это рекомендуемая задержка для мастера. минималка - 1uS. Из опыта скажу - что в пром зоне с минимальной задержкой - отлично дышит на дцать метров.
2) 1uS = это 4 такта МК(при тактовой 4МГц).
значит имеем что Вы должны обеспечить задержку от
1*4 = 4
6*4 = 24

от 4 до 24 тактов.
пуш-поп - это уже 4 такта. т.е. выставляете ноль на шину и деалеет любые подготовительные телодвижения. они занимают (как правило) не меньше чем требуется. далее выставляете еденичку и далее...

в чём сложности? пояснить на пальцах можете?

(круглый)

Просто не получается.
Я же не просто тактирую(программно делаю выдержки времени для такта), еще по тактам выставляю/снимаю сигнал с порта, суммирую полученные данные, фильтрую дребезг сигнала в проводе и прочее.. ,Ну не получается на 4 мГц и все, просто ставлю кварц на 8 мГц и проблема решается.

Как в некоторых протоколах передачи по ИК-каналу (пульты ДУ).

Вот я сейчас отлавливаю ошибки при передаче по одному проводу, просто дублируя байта и сверяю их в приемнике. Мож правда лучше дублировать инверсно в плане истинности передаваемых данных? Предположим, байты следуют один за другим при передаче. Байт, это последовательность из восьми переданных бит.

Нет сумма по модулю 2 была у SPECTRUM у РК 86 контрольная сумма двух байтовая сумма плюс перенос

Способ контроля целостности данных может быть любой, в том числе и самый изощренный. Но почему бы не применить готовые алгоритмы? Ведь даже те же 1wire-устройства используют CRC8.

Вообще неплохо было бы посмотреть осциллографом что там в линии творится и свести физические причины возникновения ошибок к минимуму.

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

Ага, поэтому конечный продукт получается сыроватым, работает через пень-колоду и проч. Быстрее, быстрее, еще быстрее, прыжками, через две ступеньки ... Читать некогда, учиться - тоже. Результат выходит соответствующий, спешка хороша при ловле блох. Лучше все-таки потратить какое-то время на самообразование, оно потом окупится многократно ...

Это как существует задача, повесить на установку несколько датчиков и пару клапанов - моторов. Любой нормальный КИПовец зайдет в магазин КИПсервис и купит готовый универсальный контроллер, напишет программу на языке логики этого контроллера. Все сделает быстро и качественно. Но что поделаешь, мне лень изучать еще один язык логики прибора например ОВЕН, пойду тернистым путем паять свой прибор и писать обслуживающую прогу на привычном языке. Иначе я не работаю, надо обращаться к обычным КИПовцам или электрикам.


Ну так на ошибках тоже можно учиться, получилось плохо - переделываешь. Это творчество.
Когда надо сделать сразу и правильно, надо обращаться к специалистам, кто специализируется в определенной теме.
Просто иной род деятельности


Да. Надо посмотерть. Но боюсь мой осцилограф плохо будет отображать дискретный сигнал. Я настраивал протокол по логическому пробнику. Низкий и высокий уровни подбирал по мультиметру, подбором сопротивлений. Контроллер связан с сигнальной линией через транзисторные ключи. Сигнальная линия притянута сопротивлением 4,7 кОм к нестабильному питающему напряжения 12 ... 15v. От этого напряжения питаются устройства висящие паралельно на линии.

Кстати, а теория длинных линий учтена?) Ту же I2C ничто не мешает на километр растянуть, лишь бы соблюсти постоянные времени...

это ж какие токи нужны, чтобы фронты сохранить... чай не дифпара...

Вся шина вот:

Она там с силовой линией рядом идет? Жестко!

Такие условия задачи. Действительно, линия до 10А нестабилизированного 12V ... 15V постоянного напряжения. На линии присутствуют эл. двигателя и лампы накаливания освещения. Минус этой линии является общим проводом информационной линии (зеленый с коричневым провод - сигнальный).

Слесарь, Ваши решения задач вызывают восхищение! (это правда, без иронии!!!) Но неужели там было трудно прокинуть два провода и гнать данные по RS485? Помехоустойчивость самого интерфейса значительно выше, а если и протокол соответствующий прикрутить с контрольной суммой, то вообще будет сказка)))


Так я и сделал оговорку про время... Это скорее эмоции были, конечно не надо на километр тянуть приборную (внутреннию) шину.

Я незнаю, подключаются ли по RS485 множество устройств паралельно? А за 1-wire как-то читал, что питание устройств и данные как-то передаются по одному проводу, паралельным подключением всех устройств..
Такой уж сделал выбор. Тянуть дополнительные провода для данных или какой-то специализированный провод, это будет менее кустарно. Тогда думаю лучше автомобильный CAN.
Постораюсь решить одним проводом, мож будут последователи такой прокладки проводки по квартире.

Делал управление освещением. По двум проводам, что раньше были проводкой, питается сенсорный выключатель, который USARTом передает команды по тем же двум проводам. Команд там больше двух не нужно, но несколько байт с контролем CRC вполне будет возможно. Кстати, ошибок в передаче/приеме пока нет. Скорость небольшая да и байты команд выбраны хитро.

Конечно, как минимум 32 устройства.

Единственное, что нужны контроллеры этой шины. Если для 485-го годится контроллер USART, то для CAN нужен свой, совершенно другой аппаратный контроллер.

Понятно. Хорошо, спасибо! Буду иметь в виду для будущих разработок.

Точнее - там, все-таки использовалась контрольная сумма ВСЕЙ программы.
Ошибки при использовании контрольной суммы как средства контроля данных я сам видел - в малоизвестном устройстве венгерского производства VT-20 с использованием 2.5 МБ дисков при 256-байтных блоках так же были сбои.
Сбоев 16-битного CRC на флоппи-дисках, лентах, каналах передачи данных я не встречал.