Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Посоветуйте в выборе протокола
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2
Pyku_He_oTTyda
Есть такая задача, связать два устройства находящихся на расстоянии 100 метров друг от друга по однопроводной линии. Один мастер, второй ведомый. Необходимо передать четыре команды. МК в устройствах работают от внутреннего RC генератора. Передовать команду необходимо не чаще одного раза в 100-300 мс.
Помогите выбрать протокол, по которому организовать связь.
Пока думаю в сторону применения АЦП, то есть в мастере резистивный ЦАП, в ведомом АЦП. Попробовал макетировать в коридоре - 60 метров кабеля работаетsmile.gif
Кто чего еще посоветует?
Andy Mozzhevilov
Цитата(Pyku_He_oTTyda @ Jul 19 2006, 15:22) *
Есть такая задача, связать два устройства находящихся на расстоянии 100 метров друг от друга по однопроводной линии. Один мастер, второй ведомый. Необходимо передать четыре команды. МК в устройствах работают от внутреннего RC генератора. Передовать команду необходимо не чаще одного раза в 100-300 мс.
Помогите выбрать протокол, по которому организовать связь.
Пока думаю в сторону применения АЦП, то есть в мастере резистивный ЦАП, в ведомом АЦП. Попробовал макетировать в коридоре - 60 метров кабеля работаетsmile.gif
Кто чего еще посоветует?


Попробуйте посмотреть на LIN
http://www.lin-subbus.org
Имхо, это более хорошая идея, чем использовать мультиуровневый сигнал.
AlexanderX
Связъ должна быть двунаправленная или однонаправленая?

Как вариант - токовая петля.
zltigo
Цитата(Andy Mozzhevilov @ Jul 19 2006, 12:35) *
Попробуйте посмотреть на LIN

:-) Это называется "красиво жить не запретить..."

Если на двух примитивных без нормальных генераторов контроллеров есть "лишние" DAC/ADC, то почему-бы и нет. Калибруйте "приемник" в паузах между командами по уровню + легкую фильтрацию принятого и все будет абсолютно нормально работать на упомянутой скорости и четырех командах.
beer_warrior
Тональными посылками можно (сильно поскипанным DTMF)
CDT
Цитата(AlexanderX @ Jul 19 2006, 12:39) *
Как вариант - токовая петля.

Правильный вариант для таких скоростей и расстояний.
Alex_Pol
Вместо резистивного ЦАПа можно шимовать. И связь однонаправленная? Команда, как понял, однобайтная, (4-х битная)?
Andy Mozzhevilov
Цитата(zltigo @ Jul 19 2006, 15:45) *
Цитата(Andy Mozzhevilov @ Jul 19 2006, 12:35) *

Попробуйте посмотреть на LIN

:-) Это называется "красиво жить не запретить..."

Если на двух примитивных без нормальных генераторов контроллеров есть "лишние" DAC/ADC, то почему-бы и нет. Калибруйте "приемник" в паузах между командами по уровню + легкую фильтрацию принятого и все будет абсолютно нормально работать на упомянутой скорости и четырех командах.


Если требований к помехоустойчивости не предъявляется, то можно.
Но не думаю, что реализация LIN так уж сложна, чтобы была именно "красивой жизнью".
Он и сделан то вместо действительно красивого CAN, как легкий протокол.
Семён
Цитата(Pyku_He_oTTyda @ Jul 19 2006, 13:22) *
Есть такая задача, связать два устройства находящихся на расстоянии 100 метров друг от друга по однопроводной линии. Один мастер, второй ведомый. Необходимо передать четыре команды. МК в устройствах работают от внутреннего RC генератора. Передовать команду необходимо не чаще одного раза в 100-300 мс.
Помогите выбрать протокол, по которому организовать связь.
Пока думаю в сторону применения АЦП, то есть в мастере резистивный ЦАП, в ведомом АЦП. Попробовал макетировать в коридоре - 60 метров кабеля работаетsmile.gif
Кто чего еще посоветует?

Я решал похожую задачу на немного модифицированном 1-Ware. Если интересно могу рассказать подробней.
Pyku_He_oTTyda
Связь однонаправленная.
LIN для данного применения слишком шикарноsmile.gif
Наверное буду использовать ЦАП/АЦП. думаю вот, поставить гальваническую развязку или обойтись защитными диодами по входу?




Цитата
Я решал похожую задачу на немного модифицированном 1-Ware. Если интересно могу рассказать подробней.


Пока ехал на работу в маршрутке, тоже такая мысль приходила в голову.
Даже думал о том, какую последовательность какой команде присвоитьsmile.gif
Если нетрудно, расскажите. Особенно интересуют применяемые скорости и возможные грабли.
AlexanderX
При однонаправленной передаче можно использовать UART на токовую петлю. На приемной стороне поставите опторазвязку и будете спать спокойно. wink.gif
Семён
ИМХО: При однонаправленной передачи мастер не будет знать, принял ведомый команду или нет. Допускает ли Ваше ТЗ негарантированную доставку команды или нет? Отсюда надо и исходить.
Pyku_He_oTTyda
Цитата
ИМХО: При однонаправленной передачи мастер не будет знать, принял ведомый команду или нет. Допускает ли Ваше ТЗ негарантированную доставку команды или нет? Отсюда надо и исходить.


Допускает. ТЗ простое, в общих чертах: четыре кнопки - четыре команды.
Пришла правильная команда - что то делаем, не распознали команду - не делаем ничего.
UART в данном случае не нравится тем, что МК работают от встроенного RC генератора, причем на открытом воздухе. Впринципе диапазон температур от -10 до +жара на солнце (а этим летом было жарко)smile.gif Опасаюсь нечеткого приема при использовании некварцованных генераторов с обеих сторон.
Кроме многоуровнего управления кажется более целесообразным либо 1-Wire, либо частотные посылки. При плавании частоты генератора проще идентифицировать команду.

З.Ы. Кстати, кто нибудь знает софт, с помощью которого можно снять импульсную последовательность команд ИК пульта дистанционного управления. Мне кроме WinLirc ничего не попадалось, а он, как оказалось не работает с Panasonic и JVC. Может существует какой либо логический анализатор для РС?
Это еще одна зубная боль в этом проекте
Семён
Цитата(Pyku_He_oTTyda @ Jul 19 2006, 14:11) *
Пока ехал на работу в маршрутке, тоже такая мысль приходила в голову.
Даже думал о том, какую последовательность какой команде присвоитьsmile.gif
Если нетрудно, расскажите. Особенно интересуют применяемые скорости и возможные грабли.

Мне не требовалось гальванической развязки, поэтому я использовал вот такую схему. Эта схема легко переделывается как под полевые транзисторы так и под опто пары (Правда в своё время я не нашел нужных мне оптопар).
В качестве ведомого выступала MEGA8 работающая от внутреннего генератора на 8мГц. Большую часть времени она спала или измеряла своими АЦП разные датчики.
Программная логика ведомого устройства была следующей: Сигнал IN_DALLAS подключался к порту внешнего прерывания, как только происходил отрицательный перепад запускался таймер, по положительному перепаду принималась решение помеха или сбросовый импульс, при переполнении таймера принималась решение линия замкнута. Далее шел обмен данными 3байта плюс CRC, каждый принятый пакет подтверждался OK или ERR. Кстати набор команд был небольшой, поэтому если команды такой не было, а CRC был правильный также формировался ERR. Отличием от родного 1-ware было, то, что я несколько увеличил длительность всех импульсов (хотя скорей всего это можно было не делать). По ТЗ у меня была дальность до 50 метров испытывал до 60 метров. РЕЗЮМЕ: у контролера забираются две ножки одна из них внешние прерывание и один таймер. В итоге контролер отвлекается от основной программы, только обнаружив сбросовый импульс. В качестве мастера выступала Mega162 c кварцевой стабилизацией. Кварц нужен был для передачи по UART.
Ну примерно гдето так.
Pyku_He_oTTyda
Цитата
Семён


Спасибо! Идея понятна.
Семён
Кстати если контролер используется только для приема команд и грубо говоря, чтобы щелкнуть реле не проще взять аппаратный декодер?
AlexanderX
На сколько я помню точность внуреннего генератора 8-ой Меги ± 3% во всем диаппазоне рабочих температур. Так что ставьте 1200 бод или меньше и правильность приема данных Вам гарантирована. Для успокоения можно переслать контрольную сумму или CRC. smile.gif
Семён
Цитата(AlexanderX @ Jul 19 2006, 15:58) *
На сколько я помню точность внуреннего генератора 8-ой Меги ± 3% во всем диаппазоне рабочих температур. Так что ставьте 1200 бод или меньше и правильность приема данных Вам гарантирована. Для успокоения можно переслать контрольную сумму или CRC. smile.gif

Без калибровки все 10%. Было у меня устройство, где на одной плате стояло 10 ATTINY2313 работающих автономно от 4мГц внутреннего генератора. Индикация дежурного режима мигающий зеленный светодиод. Всё это дело так красиво переливалось и меняло рисунок, что заказчик сказал, что если ему понадобиться гирлянда для ёлки обязательно обратиться ко мне.
yung
Цитата(AlexanderX @ Jul 19 2006, 14:12) *
При однонаправленной передаче можно использовать UART на токовую петлю. На приемной стороне поставите опторазвязку и будете спать спокойно. wink.gif


Мне эта мысль тоже нравится. Единственное "но" - использование внутренних генераторов - нестабильность частоты. Эта тема, кстати, обсуждается на форуме.
И еще. Лет 10 назад я использовал собственный протокол - передача бит осуществляется положительным импульсом, тактирование - отрицательным. Под командой может подразумеваться завершение передачи байта информации (например, два информационных импульса перед синхроимпульсом), либо байта команды (скажем, три импульса). Линия связи строго говоря потенциальная, но со стороны приемника стоят два оптрона - один для положит. полуволны, другой для отрицательной. Перед ними токоограничительный резистор. Эта реализация хороша тем, что нет жестких временных ограничений - скорость со стороны мастера можно изменять. Дешифрация довольно проста даже с использованием жесткой логики (10 лет, однако). Насколько мне известно, системы с применением этого протокола до сих пор выпускаются. Я в свое время по объектам покатался (бензоколонки, нефтедобыча и пр.) - проблем со сбоями не было.Нажмите для просмотра прикрепленного файла
Семён
Цитата(yung @ Jul 19 2006, 16:12) *
Мне эта мысль тоже нравится. Единственное "но" - использование внутренних генераторов - нестабильность частоты. Эта тема, кстати, обсуждается на форуме.
И еще. Лет 10 назад я использовал собственный протокол - передача бит осуществляется положительным импульсом, тактирование - отрицательным. Под командой может подразумеваться завершение передачи байта информации (например, два информационных импульса перед синхроимпульсом), либо байта команды (скажем, три импульса). Линия связи строго говоря потенциальная, но со стороны приемника стоят два оптрона - один для положит. полуволны, другой для отрицательной. Перед ними токоограничительный резистор. Эта реализация хороша тем, что нет жестких временных ограничений - скорость со стороны мастера можно изменять. Дешифрация довольно проста даже с использованием жесткой логики (10 лет, однако). Насколько мне известно, системы с применением этого протокола до сих пор выпускаются. Я в свое время по объектам покатался (бензоколонки, нефтедобыча и пр.) - проблем со сбоями не было.Нажмите для просмотра прикрепленного файла

ИМХО:Идея хорошая, но требует двухполярного источника питания, а это не всегда удобно и всегда дороже.
Dog Pawlowa
Я бы использовал кодирование, как в некоторых радиомодулях -
ноль передается как 2/3 периода высокий уровень, и 1/3 периода низкий уровень
единица передается наоборот, как 1/3 высокий, а 2/3 низкий.

Промежуток между посылками - постоянно какой-то один уровень.
В начале посылки для определения скорости несколько периодов меандра (но не обязательно)

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


К счастью нетsmile.gif Из "примочек" семь АЦП работают.
из 10 штук и с кварцем красиво переливатся будет, наверно, не проверял... но что то подсказывает, что будет.
Кстати, в выходные ехал на тросу на Ниве с рыбалки 90 километров, впереди тянула другая Нива. Соответственно была включена аварийка в двух машинах. Так вот, ловил себя на мысли, что реле поворотов достаточно стабильно работали в двух машинахsmile.gif , по крайней мере не было разбега, какого ожидал
Семён
Цитата(Pyku_He_oTTyda @ Jul 19 2006, 16:18) *
Цитата
Кстати если контролер используется только для приема команд и грубо говоря, чтобы щелкнуть реле не проще взять аппаратный декодер?


К счастью нетsmile.gif Из "примочек" семь АЦП работают.
из 10 штук и с кварцем красиво переливатся будет, наверно, не проверял... но что то подсказывает, что будет.
Кстати, в выходные ехал на тросу на Ниве с рыбалки 90 километров, впереди тянула другая Нива. Соответственно была включена аварийка в двух машинах. Так вот, ловил себя на мысли, что реле поворотов достаточно стабильно работали в двух машинахsmile.gif , по крайней мере не было разбега, какого ожидал

Если бюджет позволяет можно использовать микросхемы от DALLAS USART<->1-ware название не помню, но стоят где-то 4у. е 300 метров на витой паре обещают
Pyku_He_oTTyda
Поищу, интересно
okela
Я бы ставил на передающем устройстве простейщий ШИМ , а выход сделать токовый (мА так 20).
На приемном конце надо определять 4 градации ширины импульса, либо ставить фильтр простейший и
на АЦП если он есть в наличии.
И с помехозащищенность будет всё нормано.
Семён
Цитата(okela @ Jul 19 2006, 17:52) *
Я бы ставил на передающем устройстве простейщий ШИМ , а выход сделать токовый (мА так 20).
На приемном конце надо определять 4 градации ширины импульса, либо ставить фильтр простейший и
на АЦП если он есть в наличии.
И с помехозащищенность будет всё нормано.

Немножко не понял, а АЦП зачем? Лучше компаратор. Во-первых, проще, во-вторых, ресурсов использовать будет меньше.

Продолжение: к томуже по прерыванию компаратора таймер запускается автоматически можно спокойно мерить ширину импульса. Только, а гальванической развязки можно забыть.
add
А почему бы не 1-Wire протокол... только помедленнее..сделать..
Шина дергается вниз к земле.Берем интервал(слот). вначале синхроимпульс(определеннойдлительности), далее устанавливаем "0" (притягиваем шину к земле до конца слота), или "1" (отпускаем шину). Все. Начало пакета длинным слотом(раза в 4 больше). Для Вашего варианта вполне подойдет..
Ссылка: http://www.elin.ru/1-Wire/?topic=info#1
Удачи.
xemul
Т.к. жестких требований к доставке команды нет, имхо, UART и байт калибровки в начале пакета или раз в х секунд вполне справятся с нестабильностью в 10%. На стороне мастера вообще ничего придумывать не придется, на стороне слейва - по принятому байту калибровки/ошибке фрейма двигаем OSCCAL вверх или вниз. Контрольную сумму можно встроить в байт команды, если, конечно, не предполагается исправлять 2-хкратные ошибкиsmile.gif.
Физический уровень - наверное, токовая петля с оптроном.
Семён
Доброе утро. Сразу извиняюсь за свой последний свой пост <к томуже по прерыванию компаратора таймер запускается автоматически можно спокойно мерить ширину импульса. Только, а гальванической развязки можно забыть.> Бежал с работы Вот и сморозил ерунду.
Pyku_He_oTTyda обрати вниманию на предложение okela примерно также в своё время писали данные на магнитофоны. Реализация такого протокола довольно простая.
pokos
Цитата(xemul @ Jul 19 2006, 18:51) *
Физический уровень - наверное, токовая петля с оптроном.

Именно. А по ней старый добрый манчестерский код. Нестабильность частоты 40% - абсолютно по барабану.
Семён
Цитата(pokos @ Jul 20 2006, 10:55) *
Цитата(xemul @ Jul 19 2006, 18:51) *

Физический уровень - наверное, токовая петля с оптроном.

Именно. А по ней старый добрый манчестерский код. Нестабильность частоты 40% - абсолютно по барабану.

Принимал как то манчестерский код с карт. Без кварцевой стабилизации как-то коряво работало. Может что-то не то делал? Хотя с кварцем устройство выпускается серийно.
pokos
Цитата(Семён @ Jul 20 2006, 11:03) *
Без кварцевой стабилизации как-то коряво работало.

Даже совсем тупой алгоритм с наглухо зашитыми параметрами вполне устойчив к разнице скоростей, поскольку синхрится каждый бит. Есть и более сложные способы, например, синхриться надо не по единственному фронту, а по нескольким усреднённым.
Товарищ как-то давно написал читалку с магнитофона для Радио-86РК, так ленту можно было пальцем подтормаживать на ходу, до определённого предела сбоев не было.
vesago
На работе есть сетевой доступ. В этой системе связь между контроллерами по двум проводам - общий и сигнальный. Связь на километр на скорости 9600. Схема примитивная - вроде той, что выше приводилось. Сляпана на транзисторах. К компу подключается через конвертер тоже на рассыпухе. Я его ковырял через конвертер 485/232 адам. Питание общее, к сигнальному проводу подключал + 485, - в воздухе. Кажется это называется токовая петля. Наверное и вам надо вроде того сделать. Приятнее все-таки с уартом работать.
Igor26
Цитата
Поищу, интересно

DS2480 называются. 150 метров по витой паре работает, проверено.
yung
Цитата(Семён @ Jul 19 2006, 16:17) *
Цитата(yung @ Jul 19 2006, 16:12) *

Мне эта мысль тоже нравится. Единственное "но" - использование внутренних генераторов - нестабильность частоты. Эта тема, кстати, обсуждается на форуме.
И еще. Лет 10 назад я использовал собственный протокол - передача бит осуществляется положительным импульсом, тактирование - отрицательным. Под командой может подразумеваться завершение передачи байта информации (например, два информационных импульса перед синхроимпульсом), либо байта команды (скажем, три импульса). Линия связи строго говоря потенциальная, но со стороны приемника стоят два оптрона - один для положит. полуволны, другой для отрицательной. Перед ними токоограничительный резистор. Эта реализация хороша тем, что нет жестких временных ограничений - скорость со стороны мастера можно изменять. Дешифрация довольно проста даже с использованием жесткой логики (10 лет, однако). Насколько мне известно, системы с применением этого протокола до сих пор выпускаются. Я в свое время по объектам покатался (бензоколонки, нефтедобыча и пр.) - проблем со сбоями не было.

ИМХО:Идея хорошая, но требует двухполярного источника питания, а это не всегда удобно и всегда дороже.


В моем протоколе требуется три состояния линии. Можно использовать 0, 1 и Z-состояние. Схема приемо-передачи может выглядеть следующим образом. При Z-состоянии мастера оба транзистора приемника открыты, а при появлении 1 или 0 один из них закроется.
Семён
Цитата(pokos @ Jul 20 2006, 11:16) *
Цитата(Семён @ Jul 20 2006, 11:03) *
Без кварцевой стабилизации как-то коряво работало.

Даже совсем тупой алгоритм с наглухо зашитыми параметрами вполне устойчив к разнице скоростей, поскольку синхрится каждый бит. Есть и более сложные способы, например, синхриться надо не по единственному фронту, а по нескольким усреднённым.
Товарищ как-то давно написал читалку с магнитофона для Радио-86РК, так ленту можно было пальцем подтормаживать на ходу, до определённого предела сбоев не было.

Спорить не буду, так как писал эту вещь более двух лет назад. Просто приведу пример приема 9 единиц. Для справки это прием хендера (начало передачи).

;////////Инициализация/////////////


ldi temp,TICK_1d2_T;
mov t_c_1d2,temp

ldi temp,TICK_1d3_T;
mov t_c_1d3,temp

ldi temp,8
mov N_start_bit,temp

ldi temp,Fd64
mov del_fr64,temp
clr StopTimer

clr count_N
start_9bit:

rcall ResetTimer0
clr count


;//////9 Start_Bit/////////////////

nach0:
sbic PINB,_OUT
rjmp nach0
nach1:
sbis PINB,_OUT
rjmp nach1

wait0:
out TCNT0,t_c_1d2
out TCCR0B,del_fr64
t3d4:
in temp,TIFR
sbrs temp,1
rjmp t3d4
semNew:
rcall ClearTimer0
sbic PINB,_OUT
rjmp tart_9bit

wait1:
out TCNT0,t_c_1d3
t1d2:
sbic PINB,_OUT
rjmp add_count

in temp,TIFR
sbrs temp,1
rjmp t1d2
sem_tnd:
rjmp start_9bit

add_count:
out TCCR0B,StopTimer

in temp_sem,TCNT0
cpi temp_sem,0Xd0
brlo sem_tnd

inc count
cpse count,N_start_bit
rjmp wait0

;////End 9 Start-Bit////////////
;---------------------------------
ResetTimer0:

ldi temp,0
out TCCR0B,temp

in temp,TIFR
sbrs temp,1
rjmp timer0_noFull

ori temp,2
out TIFR,temp

sbrs temp,7
rjmp NoFullT1_2

andi temp,0b11111101;
out TIFR,temp
NoFullT1_2:

timer0_noFull:

ret
ClearTimer0:

in temp,TIFR
ori temp,2
out TIFR,temp

sbrs temp,7
rjmp NoFullT1_1

andi temp,0b11111101;
out TIFR,temp

NoFullT1_1:

ret
Давно хотел переписать данный код. Останавливает лишь то, что с кварцем работает без нареканий.



Цитата(yung @ Jul 20 2006, 11:39) *
В моем протоколе требуется три состояния линии. Можно использовать 0, 1 и Z-состояние. Схема приемо-передачи может выглядеть следующим образом. При Z-состоянии мастера оба транзистора приемника открыты, а при появлении 1 или 0 один из них закроется.

Будет время обязательно попробую
Woodoo
Цитата(yung @ Jul 19 2006, 14:12) *
И еще. Лет 10 назад я использовал собственный протокол - передача бит осуществляется положительным импульсом, тактирование - отрицательным. Под командой может подразумеваться завершение передачи байта информации (например, два информационных импульса перед синхроимпульсом), либо байта команды (скажем, три импульса). Линия связи строго говоря потенциальная, но со стороны приемника стоят два оптрона - один для положит. полуволны, другой для отрицательной. Перед ними токоограничительный резистор. Эта реализация хороша тем, что нет жестких временных ограничений - скорость со стороны мастера можно изменять. Дешифрация довольно проста даже с использованием жесткой логики (10 лет, однако). Насколько мне известно, системы с применением этого протокола до сих пор выпускаются. Я в свое время по объектам покатался (бензоколонки, нефтедобыча и пр.) - проблем со сбоями не было.Нажмите для просмотра прикрепленного файла


Уж очень похоже Ваш метод кодирование на RZ (with Return to Zero)...
Pyku_He_oTTyda
Cпасибо за ответы!
Пока выбрал для себя три пути:
1. 4 кнопки и весовые резисторы
2. ширина шим
3. собственный протокол на основе вышеизложенного, калиброватся в начале каждой посылки

попробую в макете что себя ведет и как
Семён
>>4 кнопки и весовые резисторы
порочный путь для промышленного оборудования. Учитывай, что кнопки не идеальны и постепенно окисляются и меняют свое сопротивление, механика разбалтывается тем самым, увеличивая дребезг. То, что хорошо работала на столе через год эксплуатации может начать вести себя не как ты рассчитывал. С кнопками однозначно нужно работать: есть контакт, нет контакта.
xemul
Цитата(Pyku_He_oTTyda @ Jul 21 2006, 09:08) *
Cпасибо за ответы!
Пока выбрал для себя три пути:
1. 4 кнопки и весовые резисторы

И это все в длинную линию? Глюков будет...
Цитата
2. ширина шим
3. собственный протокол на основе вышеизложенного, калиброватся в начале каждой посылки

имхо, все-таки стОит попробовать использовать аппаратные ресурсы контроллера (USART:)). Хотя хозяин - барин.
Если очень хочется использовать ШИМ, можно толкать в USART на передачу, например, 0xe0/0xfe как 0/1, не обращать внимания при приеме на ошибки и пытаться понять, на что принятое больше похоже - на 0xe0 или на 0xfe.
Но с периодической калибровкой слейва, по-моему, проще.
bbill
Полностью согласен с Семеном, кнопки замкнут-разомкнут.
Столкнулся в устройстве, когда при передаче, после "0" старт-бита находился бит установленный в "1". Его можно использовать для калибровки по длительности в очень широких пределах. Все стабильно работает на линиях до 150 м. Алгоритм приема 7 каналов мне подсказал defunct в начале июня.
Обязательна оптронная развязка, иначе по землям будет хаос. И не забудьте про грозы, на длинных линиях...
Семён
Цитата(xemul @ Jul 21 2006, 19:18) *
Цитата(Pyku_He_oTTyda @ Jul 21 2006, 09:08) *

Cпасибо за ответы!
Пока выбрал для себя три пути:
1. 4 кнопки и весовые резисторы

И это все в длинную линию? Глюков будет...
Цитата
2. ширина шим
3. собственный протокол на основе вышеизложенного, калиброватся в начале каждой посылки

имхо, все-таки стОит попробовать использовать аппаратные ресурсы контроллера (USART:)). Хотя хозяин - барин.
Если очень хочется использовать ШИМ, можно толкать в USART на передачу, например, 0xe0/0xfe как 0/1, не обращать внимания при приеме на ошибки и пытаться понять, на что принятое больше похоже - на 0xe0 или на 0xfe.
Но с периодической калибровкой слейва, по-моему, проще.

Используя ШИМ мы также используем аппаратные возможности: Со стороны мастера просто программируем ШИМ и просим его поработать какое-то время. Со стороны ведомого используем таймер с функцией захвата. На мой взгляд, самая простая реализация.
Itch
А если команд требуется не всего 4, то не проще ли использовать UART. Передавать информацию надо только в первом полубайте, второй полубайт - нули. За 4 бита ошибка не успеет набежать. Можно ввести контроль четности - 2бита - команда, оставшиеся 2 - их инверсия и т.п.
Pyku_He_oTTyda
Заказчик настаивает на резистивном методе, переубедить пока не удается... у них так было уже сделано взамен проводного пульта ДУ от видеокамеры Панасоник. Утверждают, что проблем и глюков не было.
Чтож, прогу написал, макет собрал, в комнате работает без нареканий.
Гальванической развязки тоже не получается, не хватает проводов в кабелеsad.gif Перед МК поставил ЛМ258, включенную как повторитель, по входу защитил диодами и стабилитроном, между первой и второй половинкой ОУ RC-фильтр.
Буду ждать испытаний, что они покажутsmile.gif

Кстати, а как правильно расчитать "ворота" значений АЦП для каждой команды? Пока используются "четверинки". Это выглядит так:
к примеру первая команда - 1 вольт, вторая - 2 вольта, третья - 3 вольта. Для второй команды я выделил диапазон напряжений от 1,75 В до 2,25 В.
А существуют какие либо правила для расчета значений в моем случае?
cyclop
Цитата(Pyku_He_oTTyda @ Aug 1 2006, 16:57) *
Заказчик настаивает на резистивном методе, переубедить пока не удается...
Гальванической развязки тоже не получается, не хватает проводов в кабеле

Консерватизм заказчика понятен: мол, зачем платить за новое решение, когда старое работает.
Мне представляется, что ЦАПовое решение неверно по трём причинам.
1. Важные параметры физического уровня - размах логического сигнала, помехозащитность, помехоустойчивость - всё перечёркивается этим решением. И это в то время, когда задача позволяет вместо амплитудной модуляции проводить ЧМ или ФМ(ШИМ). Ведь по быстродействию у вас запаса "вагон и маленькая тележка". Примените хотя бы такое кодирование ЧМ: "0" одной частотой, "1" - отличающейся в несколько раз. А можно и каждой кнопке дать свою частоту.
2. Передавать на 100 метров без гальванической развязки - это не есть хорошо. Решение проблемы - копеечный оптрон на приёмной стороне.
3. Невозможность расширения.
На 100 метров и при малой зашумлённости линии я бы не стал связываться с передачей аналогового сигнала, но если иначе, то вот такое видится решение. Сразу скажу - сложная реализация.
Итак, вы порождаете синусоидальные сигналы двух частот - для "0" и "1" (или свою для каждой кнопки). Можете использовать для этого AVR и ЦАП, либо воспользоваться отдельными генераторами. На приёмной стороне - распознавание частот. Ну тут есть где развернуться: либо в лоб с помощью триггера Шмитта и далее посчитать наполнение периода входного сигнала своей внутренней частотой, либо фильтры, либо АЦП и алгоритм БПФ.
Решать вам, но я бы отказался от ЦАПового варианта: он может преподнести "сюрприз", особенно если вспомнить о дестабилизирующих факторах - отклонении питания и изменении температуры.
P.S. Писал по памяти, а теперь только увидел, что выделяют вам в кабеле 1 провод, а это, по-моему, должно означать, что "общий" вы разделяете с кем-то ещё и тогда о гальванической развязке речи нет, т.к. этот кто-то скорее всего обошёлся без неё.
_artem_
Если на rc генераторе то можно стартовый байт или синхроблок вставить перед передачей - допустим последовательность
8-ми (или меньше/больше) импульсов 50 процентной скважности а затем саму команду. По этим импульсам приемник должен найти значение своего таймера, ну а дальше можно и уартом или "ручной" манипуляцией gpio.

Для проверки поставьте crc check checksum и/или предавайте команду два или более раз. Потом если нужна двунаправленная равноправная передача данных - делай передачу с проверкой по ответу и же коллизиям . Если перепередача нужна - поставь разное время на ретрансляцию для каждого контроллера.

Или же можно сделать master/slave конфигурацию с постоянны циклом опроса статуса slave по команде от мастера.
Pyku_He_oTTyda
Спасибо всем за внимание к моей теме!
Вылезле новая проблема: вся эта катавасия для того, что бы управлять видеокамерой. Если с панасониками проблем не было (у них гнездо под внешнее ДУ), то с сонями сложнее (только через IR порт).
Соответственно вопрос в том, как узнать команды пульта?
С сылкой этой знаком:http://www.xs4all.nl/~sbp/knowledge/ir/sirc.htm
но она не дает ответа на вопрос...
В этом вопросе может кто нибудь просветить?
Serj78
Как-то 3-4 ujlf назад я разбирал команды модельного пульта с помощью фотодиода, поднесенного вплотную к излучателю,, и звукового редактора. неудобство было в том, что интервалы были в периодах дискретизации(44кгц) smile.gif но это меня не смущало. Сейчас редакторов пруд пруди, том же неро wave editor можно записать и с точностью до ~22 мкс посмотреть... модуляция там обычно 35-38кгц, лучше ее сразу померять и потом писать сигнал сразу с трехногого фотоприемника на эту же частоту,... - там с выхода сразу цифра.

На небольшое расстояние, (~15м)по одному проводу я делал передачу между блоками пласт-автомата- что-то типа совтового uarta, но только очень низкоскоростного- пакет в 40бит передавался за 70мс. провод был в общем кабеле с силовыми, по ним электромагниты питались. пока не поставил опторазвязку, иногда были ошибки... так что опторазвязка нужна однозначно.
Pyku_He_oTTyda
Цитата
Как-то 3-4 ujlf назад я разбирал команды модельного пульта с помощью фотодиода, поднесенного вплотную к излучателю,, и звукового редактора. неудобство было в том, что интервалы были в периодах дискретизации(44кгц) smile.gif но это меня не смущало. Сейчас редакторов пруд пруди, том же неро wave editor можно записать и с точностью до ~22 мкс посмотреть... модуляция там обычно 35-38кгц, лучше ее сразу померять и потом писать сигнал сразу с трехногого фотоприемника на эту же частоту,... - там с выхода сразу цифра.


Спасибо за наводку, разобрал с помощью SoundForge и фотодиода. Алгоритм совпал впринципе с имеющимся описанием Sony SIRC, потом нашел в интернете, что сейчас команды у камер 15 битовые, что у меня и имеется. Так что эту задачу выполнилsmile.gif Спасибо за совет!
Pyku_He_oTTyda
В общем наступили на грабли по вине заказчика, им понадобилось по кабелю питать устройство, причем на общей земле. Падение на земляном проводе составляет около 1 вольта, так что аналоговый канал с весовыми резисторами отпал сам по себе, хотя было сделано и работало.
Теперь смотрю в сторону протокола 1-wire с оптронной развязкой.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.