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

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

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

Сообщение отредактировал rx3apf - May 19 2008, 18:52

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

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



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

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

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



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

Я считаю, что обрабатывать энкодер в основном цикле - пустая трата ресурсов процессора, ведь обычно энкодер - это устройство ввода команд пользователя, и прибор обычно находится в ожидании таких команд. (Услилитель играет музыку 2 часа в день, а громкость мы выставляем за 5 секунд...)

Обычно есть проблема с недостаточной чувствительностью (пропуски щелчков), а здесь же наоборот - и это хорошо. Значит надо просто посмотреть, как настроено прерывание - по переднему фронту, по заднему или изменению состояния. Если стоит измение состояния - то задать по фронту. Ну а если же настроено по фронту, то "real_volume = volume >> 1;" должно помочь.

сейчас прерьівание по спаду импульса.
думаю разницьі не будет спад или фронт... похоже гдето у меня в логике косяк...

обработка результата работьі енкодера у меня в основном цикле
если изменился volume то...
отключаем прерьівания глобально
пишем в индикатор,
пишем в регулятор громкости
пишем в память EEPROM
включаем прерьівания....
едем дельше по основному циклу

Сообщение отредактировал wired - Jun 17 2008, 14:14

Достался мне как-то "в наследство" проект, в котором обработывался энкодер... "Дядя" его обработку сделал - как и Вы: прерывание по одному выходу энкодера; направление вращения - анализ состояния другого выхода. Получалось - примерно тоже, что и у Вас: то изменение значения на 1 за щелчок, то на 2... Пришёл к следующему заключению: выход энкодера, заведённый на прерывание - он тоже, конечно, "дребезжит", поэтому после изменения этого выхода -> взводится соответствующий флаг -> происходит прерывание -> флаг сбрасывается, но "дребезг" приводит к повторной установке флага во время обрабоки прерывания -> после выхода из прерывания имеем ещё одно прерывание на тот же щелчок энкодера. Иногда повторного прерывания не происходит, тогда - приращение на 1. В результате - переделал обработку энкодера - получил, что-то аналогичное обработке от Леонида Ивановича. Рекомендую и Вам сделать что-то такое же.

но на время обработки я прерьівание то запрещаю... жду... странно.
собсно ничего не мешает устроить обработчик в основном цикле

Добавь в конце обработчика прерывания строчку типа:


А в обработчике прерывания запрещать прерывания не надо, они и так запрещены, и разрешаются после выхода из прерывания автоматически (компилятором), хотя про Codevision я не уверен.

Чего их (прерывания) запрещать? Они при входе в процедуру прерывания и так - запрещены. Дело в том, что при прерывании сбрасывается флаг, который это прерывание порадил, но поскольку уровень сигнала некоторое время скачет ("дребезг"), то за время выполнения процедуры прерывания флаг взводится повторно! После того как будет произведен выход из прерывания - оно (прерывание) повторится. Как вариант - очистка флага перед выходом из прерывания.

Может стоит добавить, сейчас обрабатываю энкодер так:

Прерывание на что настроено: изменение, или фронт/спад? Второй сигнал - он тоже дребезжит... В предыдущем варианте, вроде, было ожидание окончания дребезга (delay_ms(3); ). Кстати, Вы уверены, что дребезг закончится за 3 мс?

В своем последнем варианте - по изменению состояния, используется PIN-Change Interrupt на все четыре пина, куда подключены два энкодера.

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

УПС... вот про єто я не знал, что прерьівания во время входа в обработчик запрещеньі.
а про флаг спасибо, буду сбрасьівать.





я правильно понял? в Execute(0x11) тьі вьізьіваешь внешний обработчик?