простой P2P протокол на базе кодировки манчестер

глобальная идея - сделать простую проводную сеть с одним сигнальным и двумя силовыми проводами для освещения
провода уже монтируют, а я сижу изобретаю велосипед)

в основе кодировка манчестер
но стоит цель сделать универсальную библиотеку к которой можно сделать драйвер в виде нескольких простых функций теоретически для любого МК
должны исключаться конфликты при передаче и отрабатываться ошибки связанные с возможными конфликтами
а так же вся обработка должна делаться на прерываниях
драйвер под конкретный МК подразумевает инициализация входа и выхода (требуются два пина), одного таймера и прерываний по пину входа

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

сейчас занят декодированием и возникла дилемма, из за которой и создал тему
стою на распутье
вижу два варианта реализации декодирования:

1) в рамках того же самого обработчика прерываний таймера который уже использован для передачи настроить счетчик который будет считать такты таймера
минус в этом варианте в том, что соотношение 2 вызова на один бит нужно увеличить как минимум до 4 вызовов на один бит
у нас основная сложность в манчестере - определить середину бита, потому что именно направление изменения статуса входа в середине периода дает нам значение бита данных
так вот при четырех вызовах на бит наш счетчик гарантированно досчитает до 3 к тому моменту когда возникнет следующая середина бита

2) задействовать значение железного счетчика таймера МК (OCR для AVR)
сделать 16 битный счетчик 8 бит которого это железный счетчик таймера, а еще 8 бит - счетчик прерываний по переполнению таймера
при получении стартового бита запоминаем значение этого 16 битного счетчика и используем его как мерило длины одного бита при последующем анализе
берем отклонение 25% и если очередное изменение значения входа соответствует значению счетчика от 75-125% то считаем, что это очередная середина бита
для точности после каждой середины можно сбрасывать железный счетчик

плюс этого варианта - более точное определение длины такта. теоретически позволит читать данные с устройства на котором частота генератора сильно отличается от частоты устройства-приемника
минус этого вариант - большая сложность кода и драйвера, нужно больше функций определять в драйвере
менее гибкое решение - по сути таймер нужно будет эксклюзивно выделять под манчестер
могут быть сложность с точной настройкой частоты передачи, в частности с применением режима CTC на AVR

пока отлаживаю первый вариант
и получил большие ошибки с определением середины бита
пришлось увеличить соотношение - 8 прерываний таймера на один бит, ошибки пока пропали, но и скорость тестирования всего 500 бит/сек

кто реализовывал манчестера, поделитесь опытом и идеями

0

Сообщение от oxytt как на стандартном (переносимом) функционале UART сделать манчестер ну или другой вариант с одним проводом? по вашим ссылкам ответа на этот вопрос нет

Ссылки по манчестеру выпрямил.
А если очень хочется с одним проводом то есть т.н. "токовая петля" помехоустойчивость которой и дальнобойность при соотв. скоростях проверена реальными объектами и ГОДАМИ эксплуатации в АСУ ТП и не только.

0

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

0

Сообщение от Ymk задам тупой вопрос. ведь настоящих однопроводных интерфейсов не бывает, должна быть какая-то земля. что тут будет в качестве нее? нулевой провод? т.е. на каждом девайте надо следить, где фаза, а где нуль?

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

0

Сообщение от smort_pys Я вообще все по ЛАН делаю с ВЕБ управлением и ТСР. Там вообще с красотой интерфейса пользователя и совместимости проблем минимум.

У меня будет гейт в Ethernet сеть для управления и настройки
Но каждое устройство делать с IP интерфейсом это не целесообразно
Будет много маленьких плат с интегрированным драйвером светодиодов. Места под rj45 даже без трансформатора там нет

0

Сообщение от oxytt какие преимущества у широтной модуляции перед манчестером?

Простейшее кодирование и декодирование. Причем, как и у манчестера, нет требований к точности тика, поэтому кварц можно не ставить.

Сообщение от oxytt что то типа K-line? обсуждали это несколько месяцев назад когда я выбирал интерфейс не нашлось тогда примера успешного применения, а по манчестеру есть пример от Shads для очень похожей к моей задаче

У вас все равно физическая реализация одна и та же, а тип кодирование уже не сильно повлияет на функционирование системы.

0

Сообщение от itysiy Сообщение от oxytt какие преимущества у широтной модуляции перед манчестером?

Простейшее кодирование и декодирование. Причем, как и у манчестера, нет требований к точности тика, поэтому кварц можно не ставить.

Сообщение от oxytt что то типа K-line? обсуждали это несколько месяцев назад когда я выбирал интерфейс не нашлось тогда примера успешного применения, а по манчестеру есть пример от Shads для очень похожей к моей задаче

У вас все равно физическая реализация одна и та же, а тип кодирование уже не сильно повлияет на функционирование системы.

Можно также посмотреть на реализацию HDMI-CEC управление. На физическом уровне реализована проверка подтверждения приема данных, синхронизация начала посылки. аппаратная и логическая адресация, возможность посылки команд разной длины., арбитраж шины. Я когда разобрался со всем этим - то понял , что толково сделано.
Кстати там широтная модуляция.

0