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

Сообщение отредактировал Vladimir_T - Sep 22 2006, 04:57

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

С чувствительностью энкодера понятно. Я обычно делаю так, чтобы на каждый щелчок приходился один инкремент/декремент. Это как раз и обеспечивает 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 значимые - шаг влево и шаг вправо). А уже как отслеживать - по прерыванию, поллингом - это каждый сам порешает.