делаю последовательную передачу данных
Как надежнее контролировать наличие повреждения байта при передаче?
Что дает большую надежность распознования ошибки: проверка на четность или проверка на нечетность?
на мой взгляд - на нечетность
если можно - примеры и ссылки, но без трехэтажной математики: она меня доводит до трехэтажного мата
Тут в самом вопросе смешаны мухи и котлеты, которые, как советовавл ВВП, нужно держать отдельно. Четность или нечетность используются для контроля приема/передачи одного байта и производится аппаратно. CRC считается программно и позволяет проконтролировать правильность приема всего сообщения ( я не рассматриваю шины вроде CAN, с которй не знаком и которая тоже вроде бы это делает аппаратно) . Я в своих прогах отключаю контроль четности и считаю CRC16, которая теоретически пропускает необнаруженную ошибку с вероятностью 1/65536 .
Тут еще маячит другой вопрос. Обнаружив ошибку, ведущий перезапрашивает у ведомого повтор, на это уходит дополнительное время. Теоретически можно доказать, что при относительно большом уровне искажений и длинных сообщениях вероятность удачного приема стремится к нулю. В особо ответственных случаях я упаковывал информацию в короткие блоки, которые в пакет укладывал в 3 экземплярах. На приемном конце проверялся каждый, и если в двух из 3 CRC оказывалась не битой, прием считался успешным.
В официальных протоколах я такого не встречал, и за "самодеятельность" получал "шпинделей" от шефа, на что ему резонно отвечал : "А вам шашечки нужны или ехать?" Надежная работа системы, по-моему, важнее тупого следования стандарту.
Последний раз редактировалось Jack_A Ср мар 09, 2011 00:41:51, всего редактировалось 1 раз.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
я планирую бит четности одного байта в протоколе нижнего уровня, а поверх еще и CRC на три байта, CRC - четвертый
я понимаю, что чем длинее посылка, тем выше вероятность повреждения
И про уменьшение скорости обмена из-за запросов и повтором, но тут надежность прежде всего!
aleksandr-zh писал(а):я понимаю, что чем длинее посылка, тем выше вероятность повреждения
Совершенно верно. Достаточно словить две помехи за время передачи байта, и контроль четности с высокой степенью вероятности ничего не выявит. Если нужна более высокая надежность, используйте, например, коды Хэмминга.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
имхо, четность явно лишнее... у вас же не 7 уровней сетевого взаимодействия, к чему разделять на верх и низ, когда фактически оно все может быть на одном уровне? CRC достаточно, имхо...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
aleksandr-zh писал(а):хм, я не уверено, но это получится уже не контроль, а восстановление поврежденных данных... Да и математика для МК получится несколько излишняя
Верно. Например, если передавать 4 бита данных + 3 контрольных, то можно гарантированно исправить одиночную ошибку, обнаружить двойную и с высокой степенью вероятности обнаружить ошибку большей кратности.
Насчет математики - она очень простая и ненапряжная. Контроль по Хэммингу даже аппаратно делается без больших затрат, его часто реализуют на оперативной памяти для ответственных приложений.
Кстати, передача будет средствами UART или собственным специальным интерфейсом?
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Goldsmith писал(а):
Насчет математики - она очень простая и ненапряжная. Контроль по Хэммингу даже аппаратно делается без больших затрат, его часто реализуют на оперативной памяти для ответственных приложений.
я уже почитал в Сети о данных кодах. Надо подумать: стоит ли игра свечь
Goldsmith писал(а):
Кстати, передача будет средствами UART или собственным специальным интерфейсом?
нет, всё свое: передача по сети 220 Вольт, в паузах - при переходе тока через ноль
Достиг скорости (транспортной) в 1900 бит: Старт-бит + 8 данных+Четности + 8 данных+Четности
Думаю, изменить на:
Старт + 4 данных+Четность +4 данных+Четность + 2НомерПакета+Четность
Транспортная -ниже, данных меньше передам, но надежность - выше
ARV писал(а):имхо, четность явно лишнее... у вас же не 7 уровней сетевого взаимодействия, к чему разделять на верх и низ, когда фактически оно все может быть на одном уровне? CRC достаточно, имхо...
я пока в процессе разработки, но планирую два уровня
Первый - транспортный, с минимально достаточной проверкой целостности данных (тот же бит четности или нечетности)
Второй- информационный, там тоже будет CRC на 2-4 байта (планирую: два под адрес и один - под данные)
имхо, ничего, кроме разрастания кода и снижения скорости вы не добъетесь своими уровнями... если вы опираетесь на "декларируемое" везде "небольшое количество помех в сети вблизи перехода через 0", то наоборот было бы логичнее стараться передать как можно больше битов в этот промежуток и повторить весь пакет спустя 10 мс, если он с ошибками, чем медленно и печально по несколько лбит передавать с контролем ошибок...
на самом деле помех около нуля мало? по-моему, это немного не так... без привязки к нулю разве плохо доставляются данные?
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
