avr работа с энкодером

[Владимир_К]

Надо использовать внешнее прерывание.

Да есть у меня и такой вариант.. Но, что-то не так пошло. Скорее всего причина в следующем - на время, когда программа считает и прописывает новую частоту в Si, я запрещал прерывания. Возможно это лишнее. При этом что получается? Время расчета частоты и записи ее в Si превышает время, в течение которого валкодер поворачивается на один шаг. То есть, считанное состояние валкодера контроллер может распознать как вращение в другую сторону. В результате получал следующее - вращаю вперед, частота нормально перестраивается, если крутить побыстрее - начинает перестраиваться совсем не туда куда надо. Чтобы этого не было, нужно, чтобы периодичность обращения к валкодеру не превышала определенное время, а именно - время самой длительной операции, выполняемой программой. Для этого у меня все это крутится в основном цикле, коротком цикле. Там всего несколько операций и постоянно считывается что выдает валкодер и пишется в буфер. При возникновении прерывания по таймеру, выполняются все операции - счет новой частоты, вывод на экран и пр. В это время, конечно, все импульсы от валкодера будут пропущены. Но не думаю, что это важно.
Если использовать внешнее прерывание от валкодера, тогда запрещать прерывания нельзя. Но тогда, что-то было не так. Где-то контроллер вел себя не корректно.. Особенно я не вникал. Тот алгоритм, что использую сейчас работает нормально. Валкодер у меня оптический, на подшипниках, если крутнуть пальцем, то можно за один раз перестроиться на 10-15 кгц, а то и больше. При медленном вращении - перестройка как и положено - на один шаг. Крутим в два раза быстрее - перестраивается в 4 раза. Фактически частота перестройки равна содержанию буфера энкодера в квадрате, умноженная на шаг.
Кроме того, это все только начало. А дальше начинается более интересное - воплотить это все в аппарате и чтобы помех не было и шума и прочего. Поэтому, если бесконечно ковыряться в программе, то синтезатор так и будет лежать на столе..

[UN7GCE]

...на время, когда программа считает и прописывает новую частоту в Si, я запрещал прерывания.

Владимир, МК настолько быстро считает, что даже при 1000 оборотах нет необходимости запрещать прерывания.
Вот здесь простой синтез с двумя энкодерами. Трещотка и оптика. Правда исходник на асм. Запрет прерываний только на запись в EEPROM.
А здесь хорошая статья про энкодеры на СИ.

[Radio_Ham]

#include <avr/interrupt.h>//библиотека прерываний


int position=0;

ISR (INT0_vect)
{
if (((PIND&0x01)==0x00) &&(position<9999) ) position=position+1; //инкремент position
if (((PIND&0x01)==0x01) &&(position>-9999))position=posit ion-1; //декремент position
}

int main(void)
{
DDRD=0xfa; //PD0,PD2 как входа, остальные - выхода
PORTD=0x05;


MCUCR=(1<<ISC01)|(1< <ISC00); //Включаем прерывание INT0 по фронту на PD2
GICR=(1<<INT0);

write_position(); //Пишем position

sei(); //Разрешаем прерывания

while(1)
write_position();


return 1;
}

Энкодер начинает сходить с ума, цифры бегут вперед его

[Genadi Zawidowski]

Вы в курсе, что механический валкодер в момент замыкания/размыкания контактов формирует "бороду" из тысяч переходов между состояниями замкнуто и разомкнуто?

[ur3ilf]

Для противодействия бороде ставят RC фильтры.
Три года только механические и использую. Проблем не имею. Ни чем не хуже оптики.

[rx3apf]

Давить дребезг RC-фильтрами - "дурной тон". Правильно реализованный автомат состояний нечувствителен к дребезгу, не теряет импульсы, не набрасывает лишнее, и не забывает направление (привет программистам фирмы Alinco).

[Radio_Ham]

Скиньте схему rc фильтра

[Genadi Zawidowski]

Скиньте схему rc фильтра

прошу.

Только бы я поставил по 1 килоому… А так принцип такой.
Попробуйте не из прерывания а из основного цикла для проверки алгоритма - не вешаясь на прерывание (не забыть убрать его разрешение из кода).

[ur3ilf]

Давить дребезг RC-фильтрами - "дурной тон".

Почему? Хуже не будет. Я ставлю на трещетку конденсаторы по 10 нанофарад. Внешние подтягивающие резисторы не использую. Хватает тех что в мегах по входам встроенные.

Правильно реализованный автомат состояний нечувствителен к дребезгу, не теряет импульсы, не набрасывает лишнее, и не забывает направление (привет программистам фирмы Alinco).

Нет ну это конечно же само собой. А как иначе? Только так. Работает любой нормальный датчик- хоть механика, хоть оптика. Считаю все состояния = учетверение против "классики". Кому лень доработать механику и убрать трещётку то три состояния просто игнорируются и ни как не воздействуют не величины. Только учёт "автомата состояний". Можно и по таймеру опрашивать но я так не часто делаю. Если обычных прерываний не хватает то есть у атмелов ещё куча PCINT прерываний. Работают сразу по фронту и спаду. То что надо для валкода.

Самый простой валкодер делается с одним прерыванием по фронту или спаду. При возникновении прерывания смотрится второй порт валкода и если там ноль то счётчик декременируется а если единица то инкременируется. Или наоборот. Примитивно до безобразия. Но с дачиками без дребезга коими является оптика работает хорошо.
Пару строк кода всего.

[rx3apf]

Внешнее подавление дребезга - это "костыли" (тогда уж сразу готовый внешний "кондиционер", было что-то такое у Моторолы). С сомнительным эффектом (зависит, в том числе, от износа контактной группы). Грамотная реализация или должна вообще быть нечувствительна к дребезгу в принципе, либо , в предположении, что источник гарантированно не имеет дребезга, может быть реализована проще (правда, в момент смены направления можно получит неприятности, если излишне упрощать. Это как раз тот случай, когда прерывание по одной квадратуре, и смотрим за состоянием другой. Набросить лишнее - как два пальца). 10 nF + ~50 кило встроенного pull-up это маловато (0.5 ms постоянная). Правда, наличие конденсатора на входе полезно в аспекте подавления внешних наводок (статика и радиочастотные), но я бы этак до 1 nF урезал.

Что до реализации - дело вкуса. По прерываниям энкодера имеет смысл, если хост спит и пробуждается по событию (экономим питание или минимизируем EMI). Лично я использую опрос по таймеру (заодно обрабатывающий и прочие события, например, позволяя не вводить лишние ожидания для работы HD44780, и, т.о. резко сокращая непроизводительные расходы CPU), по возможности предпочитая более-менее предсказуемую растактовку без асинхронных событий.