Есть MEGA64 и инкрементальный энкодер PEC12-4220F , кто работал с энкодером посоветуйте , как правильно обстучать его?

Один из сигналов (А или В ) я заводил на внешнее прерывание, второй на любую ногу порта, сконфигурированую как вход. Прерывание - по любому логическому изменению сигнала. В обработчике, исходя из предыдущего и текущего значения сигналов А и В (предыдущее значение - значение А и В, при предыдущем вызове обработчика внешнего прерывания ) принимал решение в какую сторону происходит вращение и соотв. увеличивал или уменьшал значение требуемой переменной. Вот краткий алгоритм работы.. если нужно более подробное описание - обращайтесь...

Обработка энкодера по прерываниям неудобна, так как требуется давить дребезг. Более того, чтобы корректно реализовать квадратурный декодер 1х (или 2х, 4х), прерывания должны происходить не по фронту или спаду одного из сигналов, а по любому изменению состояния энкодера. Отсюда следует порочность декодера типа "программный D-триггер, один сигнал энкодера на вход D, второй - на C". При такой реализации INC/DEC всегда происходит по фронту одного из сигналов энкодера, что есть неправильно. Если вал энкдера просто пошевелить на месте, может насчитаться куча импульсов. INC/DEC нужно делать по изменению состояния двух сигналов, чтобы и INC, и DEC происходили в одной и той же точке, но при её проходе с разными направлениями вращения. Информацию о построении правильных квадратурных декодеров можно почерпнуть из описания спец. микросхем, например, HCTL-2000.
Я обрабатываю энкодер и его кнопку в основном цикле программы. Если программа чем-то занята, то она всё равно не сможет отреагировать на вращение энкодера, а буферизовать проделанный поворот и откладывать его обрботку - это уже слишком. Практика показала, что для комфорного использования энкодера задержки на подавление дребезга не должны превышать 500 мкс, иначе становится заметным пропуск шагов при резком повороте ручки. Я использую 300 мкс. Столь малые времена, к сожалению, не могут быть сформированы системным таймером как большинство других временных интервалов в программе. Поэтому приходится применять "тупую" задержку в виде цикла. Для таких малых интервалов это вполне допустимо, потери производительности процессора будут минимальными. Тем более, что обработка энкодера - это общение с пользователем, который всегда является самым медленным звеном системы Более того, если какая-то задача в основном цикле захочет временно забрать все ресурсы процессора (за вычетом потерь на прерывания), она сможет это сделать. В это время энкодер обслуживаться не будет. Для кнопки время подавления дребезга должно быть существенно большим, я использую 50 мс. Уж очень разные механические характеристики контактных групп кнопки и энкодера.

Сюда выложил пример обработки энкодера на асме для AVR:
http://upload.caxapa.ru/Enc.txt

здесь кусок обслуживающий кодер, кнопку сам допишешь.
Полностью согласен с Леонидом Ивановичем, поэтому функцию вызываю из основной
программы примерно раз в 20мСек, избавляюсь от дребезга и слишком быстрого вращения
define PIN_Coder PIND//PD0,PD1


char status,encoder = 0;

//-----------------------------------------------------------------------------------
signed char ReadEncoder(void)
{
register signed char temp = 0;
encoder = (~PIN_Coder & 0x03);//ïðîâåðÿåì PD0,PD1
if(status != encoder)
{
switch(encoder)
{
case 0:
if(status == 1) temp = 1;
else if(status == 2) temp = -1;
break;
case 1:
if(status == 3) temp = 1;
else if(status == 0) temp = -1;
break;
case 2:
if(status == 0) temp = 1;
else if(status == 3) temp = -1;
break;
case 3:
if(status == 2)temp = 1;
else if(status == 1) temp = -1;
break;
}
status = encoder;
}
return temp;
}
//-----------------------------------------------------------------------------------

Спасибо всем! Буду пробовать!

Не невозможно сделат на 2 перервания.
Вот я делал. Прилагаю изходник. Ето работает стабилно.

советую апноут микрочип AN696 - там схемотехника и Си код.

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

А какой физический смысл несет переменная "чувствительность энкодера"?

Если не жалко - можно пример кода на Си ?

Для устранения дребезга по нескольким входам с одинаковой динамикой удобно использовать алгоритм "вертикальных счетчиков".
Выходы енкодера обрабатывались по 100 мкс прерываниям фильтром на вертикальных счетчиках. Результат: PIn - отфильтрованные входы, PInChg - изменения по входам.
Извините, прога на ассемблере под PIC'и. C-шный код достаточно раскомментировать.Нажмите для просмотра прикрепленного файла
PIn и PInChg можно дальше обработать в основном цикле, или, если напряг по времени, не отходя от кассы. PInChg должен быть обработан до следующего прерывания.
Применительно к энкодеру в предположении, что обрабатываются только два входа:

Ограничения: битовые позиции входов по портам (если обрабатываются входы с нескольких портов) не должны пересекаться.

Еще есть такое решение:
По тику таймерного прерывания заполняется кольцевой буфер. С каждым тиком в буфер засылается значение состояния энкодера. Анализируются элементы массива буфера: при равенстве элементов в массиве, возвращаем код состояния энкодера. Следующее заполнение кольцевого буфера только после обнаружения перекрытия фаз сигналов. Кольцевой буфер на 4-е элемента, частота опроса - 20 Гц.

Если частота опроса 20 Гц, то получится страшно тормозной энкодер. При быстром вращении он будет пропускать шаги - это некомфортно. Нужна частота опроса в 100 раз выше.

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


увы на си для 8 бит не пишу...
а алгоритм описан выше - ничего секретного...

Наверно загадочность заключается в том что :
- при первом же прерывании устанавливается флаг состояния порта и первого прерывания(переменная) и наверно (если нужна перепроверка состояния порта через определенное время) запускается таймер. При этом для предотврашения многочисленных прерываний от порта вследствии дребезга - прерывание порта деактивизируется.
- при прерывании таймера прочитывается порт и сверяется с предыдушим, полученным при прерывании от порта
если совпадает - то рапортуем в коунтер, если нет то в обратное состояни . И также прерывание таймера
деактивизируется и прерывание порта опять активизируется .

Эта частота лишь для примера, ее можно и поднять в десятки раз, суть в использовании кольцевого буфера и занесения в него состояния энкодера. Частота опроса влияет на комфортность работы с энкодером: когда требуется менять параметры регулирования энкодером, например в диапозоне 0-1000 нужна частота выше, чем для диапазона 0-100. При большой частоте опроса бывают затруднения при подходе к требуемой точке , приходится балансировать. Вот и получается, что частота опроса должна быть адаптивной и зависеть от скорости вращения.
Все требования к конпоновке органов управления, средствам отображения и удобству работы с органами управления, как и с прибором в целом, определяются эргономикой, как и та не очень высокая частота для "страшно тормозного энкодера", но с которым очень комфортно работать.

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

С чувствительностью энкодера понятно. Я обычно делаю так, чтобы на каждый щелчок приходился один инкремент/декремент. Это как раз и обеспечивает 1х квадратурный декодер. Возможно, в ряде случаев чувствительность энкодера можно уменьшить (например, при путешествиях по меню). Но верно ли это с точки зрения эргономики? Пользователь крутит ручку, слышит щелчок, а ничего не происходит. Что ему делать дальше?

Необходимость "балансировать" бывает при неправильно выбранной фазе энкодера. На каждый механический щелчок энкодер проходит 4 разных электрических состояния. На этом и основаны 4х квадратурные декодеры. Если мы делаем из 4х декодера 1х, то в качестве рабочего можно взять любой из 4-х переходов. Лучше брать тот, который находится ровно посередине между точками механической фиксации.

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

Если нужно несколько таймеров а возиться неохота то в этом топике есть библиотека для работы по одному апаратному таймеру для нескольких пользователей(в программе), с попеременным вызовом функций через указатели:
http://electronix.ru/forum/index.php?showtopic=10934

Могу сказать обратное...
зачем тратить впустую циклы контроллера, обеспечивая задержку для подавления дребезга, и тем самым увеличивать время основного цикла...
да и обработчик прерывания - всего ничего....
а таймер задействовать для этих целей мне откровенно говоря жалко
их и так мало :-)
а если взять прерывание типа PCint (вектор у него ниже) -вообще красота...
А ещё можно к ногам энкодера прицепить конденсатор - тоже не лишнее будет при борьбе с дребезгом..
Ну и что, что прерывание сработает лишний (ненужный) раз - в любом случае это же какое то действие над энкодером.
не лучше ли это действие проанализировать?...
все таки работа по внеш прерыванию - мне кажется более экономной...

Спорить здесь не о чем. Каждый из вариантов имеет право на жизнь. Предпочтительный вариант зависит от особенностей конкретного приложения. Бывает, что и таймер остается неприкаянный, бывает что и основному циклу делать нечего, когда программа ждет действий пользователя.



Вот этого делать не стоит - конденсатор резко укоротит жизнь энкодера, так как увеличатся импульсные токи при коммутации. Вот RC-цепочку - это можно. Хотя изящнее бороться с дребезгом программно.

конечно же спорить не о чем, да мы и не спорим - обычное обсуждение плюсов и минусов
:-)

Я вас умоляю ..... :-)
я же не предлагаю от 220 вольт запитывать и конденсатор 1000мкф :-)))
а вот RC цепочка своей постоянной времени может как раз понизить "быстродействие" энкодера...
тогда уж элемент с триггером Шмидта.. -вот что действительно спасет.

Хочу поделиться результатами опытов с энкодером...

Главное в работе с последним - это борьба с дребезгом. Для борьбы с ним общепринято вводить паузу (задержку) после обнаружения первого изменения уровня (фронта)...

Так я и делал (делал это в прерывании). Но что обраружилось: или происходили ложные срабатывания (если задержка мала) или (при значительном увеличении времени задержки) происходил пропуск срабатываний (при быстром вращении). Оптимальной, но не решившей проблему (возможно из-за свойств конкретного экземпляра энкодера), оказалась задержка в 300мкС, как и советовал ув. 'Леонид Иванович'.

Идея с подключением конденсатора, предложенная 'Kovrov', показалась мне весьма правильной, а проведенный опыт доказал полную состоятельность такого решения.

Таким образом, считаю, что для "победы" над дребезгом контактов, возникающим при работе энкодера, достаточно подключить параллельно выходам энкодера конденсаторы емкостью 0,1...0,15 мкФ (я поставил 0,15). При этом дребезг "пропадает" полностью (задержка не нужна совсем). Срабатывания отрабатываются правильно не зависимо от скорости вращения ручки энкодера.

Удачи!

З.Ы. Подключение конденсатора безусловно снижает надежность конструкции (как минимум из-за введения новых деталей) и для СЕРЬЕЗНЫХ изделий такое решение не является правильным. Однако в бытовых условиях такое решения полностью оправдано.

0.15 это очень много...
попробуйте использовать интегратор с постоянной времени не более 5 мс
инегратор можн рассмотреть как RC цепь
и будет вам счастье...
на счет З. Ы. тут я полностью не согласен :-)
дополнит рс цепь ни есть пентиум4 -))))))))))

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

Исходные даные - один выход энкодера заводим на вход INT0 (PIND_Bit2), второй выход на другую ногу (в данном случае PIND_Bit3). Настраиваем прерывание INT0 по любому фронту.
Есть глобальная переменная "Volume", которая изменяет свое значение при вращении энкодера.

Обработчик прерывания:



И не используется никаких конденсаторов, таймеров или задержек, при этом все работает как должно. Что я упустил?

ничего не упустилию
просто процессор лишний раз парится на обработку инт0 на момент дребезга
на глаз это не заметно.

Посмотрите на "хвостатый экодер". Может пригодится.
Mechanical mouse

Нарисуйте на бумажке работу энкодера и сгенерируйте вариант работы который вас устроит. Меня вполне устраивает (правда со спец условиями) - энкодер механический, работает сносно. с оптическим не пробовал но думаю будет лучше и надежней - необходимости нет

Единственная светлая мысль на всю тему... И не обязательно частоте опроса быть адаптивной.
Я сделал на плисе 80МГц. Отлично работает!

Вот здесь, в самом начале обсуждения, и был приведён правильный алгоритм, и соображения начёт скорости опроса.
Сам я категорически не люблю программных задержек и фильтрации дребезга по времени. Сегодня дребезг один, затра другой. Сегодня енкодер - ручка пользователя о 16 позициях, завтра - мышка какая-нибудь быстробегающая... Поэтому.
Если рассмотреть все фазы енкодера (00 01 10 11) то видно, что последовательность фаз в одну сторону 01320132... в другую 10231023.... Другие переходы (0132-3-2-3-20) есть дребезг. Т.е. нужен fifo на 3 двухбитных числа (1 байт/регистр) и анализ его 64 состояний (всего 2 значимые - шаг влево и шаг вправо). А уже как отслеживать - по прерыванию, поллингом - это каждый сам порешает.

Да. Без сомнений, кусок тот самый. Ни в каких модификациях не нуждается. Помнить больше 4 бит смысла нет. Из них только 2 бита во время пребывания снаружи этого кода. Переходы 3-2-3-2-3-2 отлавливаются по 4м битам. Со счётчиком будет происходить +1,-1,+1,-1,+1,-1 - что на конечный результат отрицательно не скажется.
Прошу прощения, если кого-то ввёл в заблуждение... Тема исчерпана...

Пробую использовать энкодер PEC16 BOURNS. Предварительно заготовленный код не пошел. Решил попробовать упоминаемый код, сбоит. Снял несколько осциллограм. Это с установленными RC цепочками. Без них иголки полноразмерные.
Попробую использовать прерывания, с многократным считыванием в течении 5 мсек для принятия решения о состоянии уровня. Благо, на 4 энкодера и кнопки целая Мега88.

Ниасилил выделенный участок осциллограммы. Что это?
Нажмите для просмотра прикрепленного файла

Вероятнее всего моя рука дрогнула. Т.е. в этом месте, вероятно, ручка энкодера замедлила движение. Привожу фото внутренностей нового PEC16. Обратите внимание на поверхность. Контакты этого энкодера имеют некоторое подобие фиксации. В этом положении они разомкнуты (сигнал =1). На один щелчек одно замыкание каждого контакта. Который, впрочем, может остаться замкнутым в новом фиксированном положении. Программа должна выдавать один импульс при переходе из одного фиксированного положения в другой.Нажмите для просмотра прикрепленного файла

Дык у меня так и было тоже на одном энкодере. Намучался. Имхо, остаться замкнутым - это неправильно. Сколько экземпляров энкодеров Вы юзали? Может, это вообще баг.
Насчет 5мс антидребезга - многовато. Надо бы 2,5 мс.

Смотрел на одном. Но исходя из вида плоскости контактных пластин и конструкции фиксатора, такую ситуацию нельзя исключать. Правда, энкодеры имеют 24 положения на оборот, что, на мой взгляд, много. Оптимально, я думаю, 10-12. Потом сменю, а пока то, что есть. 5 мс - предварительно, исходя из ширины импульса при более, менее разумном вращении. Далее буду уменьшать. И RC цепочки уберу, вероятно.

Ну вы даете! Я успешно обрабатываю с помощью ATtiny13 программой из 100 байт. Правда, не покупной энкодер (долгий поиск выявил, что все они - полное говно), а оптрон TCUT1300.


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

Ну так порекомендуйте ортронный по сносной цене.

А кнопку на валу тоже сами делаете?

Вот так прямо и все ? Что-то не замечал... Видел разок истирание пары позиций в валкодере трансивера от Yaesu, а так - работают годами, без проблем. В некоторых готовых изделиях - бывает пропуск или забывчивость, но совершенно однозначно чисто программная проблема. Тоже, видимо, кто-то посчитал, что раз энкодеры г..., то и утруждать себя правильной обработкой не стоит. А вот если головой подумать (или хоть начало топика прочитать, где как раз все разжевано) - то все получится просто, надежно, и будет работать много лет.


А нахрена ? Еще и оптическую часть городить, юстировать... Оптическая мышь стоит от сотни рублей, вытаскивается сенсор с подсветкой - и вот все готово. Бонусом еще и отдельный оптический кодер на колесико. С трещеткой.

Разрешите выполнять ?! Вот сейчас прямо бегом все помчались... А кто будет делать трещетку, кнопку на шток ? Кто обеспечит микропотребление ? Предложите что-то оптическое в ту же цену, что изделия от Boirns или ALPS ? Нет ? Тогда, может быть, стоит поумерить категоричность ?

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

Пробовал тут рулёз от Parallax. Там готовая прога шла к нему на 16 квадратурных энкодеров. При
внешнем кварце 8МГц и умножителе на 16 (внутренняя 128МГц) без прерываний обрабатывалось
на ура. Может то же попробуете. Микроконтроллер P8X32A (на имраде 82 грн.).

И что, это нормально, с неработающей позицией можно продолжать работать?

Пропуск - это чисто аппаратная проблема.

Что там юстировать? Поставил колесо с прорезями и пусть крутится.

Не понял, что за трещетка с кнопкой?

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

Нет. Не всегда, точнее. Зависит от обработки. И есть у меня такое подозрение, что заявления типа "готовые кодеры - г.." происходит как раз из-за непонимания, как надо обрабатывать сигналы таких датчиков. Гордое заявление про программу из 100 байт - тоже. Куда там столько ? Автомат состояний для кодера с дребезгом - этак слов 20-30 программы (AVR). И не пропускает, и лишнего не считает.

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

Основная масса механических энкодеров имеет достаточно крупный шаг, причем эти шаги ощущаются тактильно (как, например, колесико мыши), причем у разных изделий - по-разному (скажем, PEC12, PEC16 - довольно мягкие, попадавшиеся мне ALPS - жесткие и четкие, в зависимости от назначения выбирается тот или иной тип). Замена на плавно вращающийся кодер просто недопустима по эргономическим соображениям, это столь же неудобно, как компьютерная клавиатура без клика. Там же, где нужна плавность - и без того обычно применяют оптику. Дело и не только в ресурсе - трудно сделать механический кодер с сотнями импульсов на оборот. А еще у мелких механических кодеров часто есть кнопка на штоке, во многих случаях удобная вещь. И заниматься самодельщиной, изобретая механическую часть самостоятельно - удел радиолюбителей. Для единичного изделия - годится. Для серийного - нет.

Ради справедливости. Оптические есть с фиксацией или без фиксации, с кнопкой и без, отличие - цена и ресурс. Мне, кстати, больше понравились энкодеры Филипс.

Так вам он нужен в качестве элемента управления? Я-то думал - как промышленый датчик... Тогда зачем энкодер? Поставьте многопозиционный переключатель и будет вам щасття

К счастью, у нас есть конструкорский отдел и механический цех, который умеет точить любые детали, а уж диск с зубьями 1.6 мм - плевое дело.
А что такое самодельщина? Ведь ты тоже что-то делаешь, разрабатываешь какие-то схемы - зачем заниматься самодельщиной, ведь наверняка это уже кто-то делал до тебя, не проще ли это купить? Я знаю одно предприятие, на котором никогда не разрабатываются собственные платы - это такая принципиальная установка руководства. Хотя они занимаются промышленной автоматизацией. Для любого изделия закупается готовая микропроцессортая плата, вставляется в покупной корпус - и все, изделие готово, остается только запрораммировать. В качестве пульта или монитор, или - в последнее время - берется микропроцессорная плата с установленным на ней ЖК дисплеем. То есть, кроме проводов и разъемов -ничего своего. Так что, самодельщина - понятие растяжимое, все зависит от профиля предприятия.

Неудобно и ненадежно. И конструкторы связной аппаратуры (где инкрементальные энкодеры с трещеткой применяются повсеместно) придерживаются того же мнения. Там, где положения фиксируются - ничего лучше не придумано. Там, где плавная перестройка - оптика. Аналогично и в другой аппаратуре - где нужно переключатель - поставлю переключатель или абсолютный кодер. А то и сенсорную кнопку. От задачи зависит.

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

Конечно. Для себя, "для души". Но если что-то такое, что уже "есть в природе" - то стимулом может быть разве что неподходящая цена или качество. Чаще - отсутствие каких-то требуемых функций. Однако времена, когда радиолюбители с энтузиазмом химичили с самодельными детектирующими кристаллами, высунув язык, искали активные точки, делали конденсаторы из стекла и фольги, а резисторы из угольных стержней и стеклянных трубок - давно прошли. Серийный компонент "на коленке" не сделать лучше, чем Bourns, ALPS или кто еще. Так что неубедительно даже применительно к любительской конструкции. В серийное же продаваемое изделие мне такое решение поставить - даже в кошмарном сне не привидится. Это кошмарные ужасы совка, надеюсь, что в далеком прошлом, и возврата к ним не будет...

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

А смысл? С обработкой энкодера нормально справляется AVR. Сейчас использую такой код:



Иногда делаю еще измерение скорости вращения энкодера и при быстром вращении формирую другие сообщения (например, для изменения редактируемого параметра в 10 раз быстрее).

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

взял за основу, прерьівание по спаду
volume - вьівожу на дисплейчик
сделал так:



получил интересную картину, на один щелчок енкодера проходит 2 значения
т.е. на дисплейчике видньі только четньіе или нечетньіе числа
что я не так делаю?
или советуете обрабатьівать в основном цикле как у Леонид Иванович