нет. для 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 такта. т.е. выставляете ноль на шину и деалеет любые подготовительные телодвижения. они занимают (как правило) не меньше чем требуется. далее выставляете еденичку и далее...

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

(круглый)

Сообщение отредактировал kolobok0 - Dec 1 2011, 08:14

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

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

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

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

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