Перейти к содержанию
    

Протокол передачи данных по одному проводу

....Нормальная ли это статистика ошибок для однопроводной шины по типу 1-wire?....

 

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

 

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

 

удачи вам

(круглый)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

 

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

 

удачи вам

(круглый)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Существуют очнь много разных алгоритмов...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изучаю варианты контроля данных

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

это откуда вот такое(8мГц)?

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

 

 

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

 

(круглый)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Все устройства на шине самодельные.

 

это откуда вот такое(8мГц)?

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

 

 

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

 

(круглый)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

да ладно сложно.

1) 6uS = это рекомендуемая задержка для мастера. минималка - 1uS. Из опыта скажу - что в пром зоне с минимальной задержкой - отлично дышит на дцать метров.

2) 1uS = это 4 такта МК(при тактовой 4МГц).

значит имеем что Вы должны обеспечить задержку от

1*4 = 4

6*4 = 24

 

от 4 до 24 тактов.

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

 

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

 

(круглый)

Изменено пользователем kolobok0

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Просто не получается.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...