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

Плюсы :

1) Не требуется программной обработки дребезга контактов
2) МК обрабатывает энкодер только по прерыванию, а значит в главном цикле не требуется его постоянно считывать
3) На одно прерывание можно повесить хоть 10 энкодеров , главное что-бы количество выводов выбранного МК позволяло
4) Работать будет даже «ушатанный» энкодер
5) Можно сделать подсветку по вращению энкодера не потребляя при этом ресурсы МК , в представленной ниже схеме при вращении в одну сторону будет мигать красный светодиод , а в другую синий

Минусы :

1) Требуется дополнительная обвязка
2) Придется более тщательно прорабатывать алгоритм остальной программы, например отказаться от динамической индикации во избежание миггания последней во время обработки энкодера

Итак для начала схема :



Поскольку достойной модели инкрементального энкодера в протеусе не нашлось была применена модель механизм действия которой подробно описан здесь http://diymicro.ru/sozdanie-ierarxiches ... odera.html
А здесь ее можно скачать https://bitbucket.org/embedgs/diymicro. ... ?at=master
Эта модель по своему принципу действия аналогична тому если-бы мы взяли обычный энкодер и на общий вывод подали-бы лог единицу. С энкодером вроде-бы разобрались, едем дальше.

Прежде чем объяснять принцип действия конвертора вкратце опишу принцип действия D-триггера для тех кто этого не знает. Любой триггер подобен своего рода выключателю , соответственно он может быть установлен (вкл.) или сброшен (выкл.). Когда триггер сброшен на его «прямом» выходе будет лог 0 , а на инвертирующем выходе лог 1 , если-же триггер установиться то на прямом будет лог 1 , а на инвертирующем лог 0.
Что касается специфики именно D-триггера так это просто усложненная модель RS-триггера к которой добавили еще один способ управления, поэтому давайте для начала рассмотрим RS управление.
Следует помнить что управление может быть как «прямым» , тоесть осуществляться при помощи лог 1 , так и инвертированным когда управление осуществляется при помощи лог 0 (в нашем случае выводы 1, 4, 10 и 13 инвертированные).
Далее все предельно просто, если подать управляющий импульс на пин «S» то триггер установиться , при этом дальнейшее воздействие на вывод «S» не будет иметь никакого результата. С пином «R» та-же история только триггер сброситься.
Наконец-то мы добрались до второго способа управления ,который осуществляется по пинам «D» и «CLK» , здесь тоже все примитивно - пока нет тактирующих импульсов на пине «CLK» управление триггером через пин «D» невозможно , а если подать тактирующие импульсы то на фронтах этих импульсов триггер начнет реагировать на то что «прилетает» на пин «D» , поскольку конкретно в нашем случае пины «D» и «CLK» НЕ инвертирующие то реагировать мы будем по положительному фронту на «CLK» , и если в этот момент на пине «D» была лог 1 то триггер установится , а если 0 то сбросится (для инвертирующих пинов реакция идет полностью наоборот).
Ну и на последок стоит отметить что RS-управление имеет приоритет над D-управлением. Это значит что когда подан управляющий сигнал на «R» или «S» , то что-бы не происходило на «D» и «CLK» на них триггер не отреагирует


Итак с теорией работы D-триггера разобрались теперь разберем принцип работы конвертора , для начала изобразим работу энкодера в виде нулей и единиц
№ этапа обработки 1 2 3 4
Состояние пина А 1 1 0 0
Состояние пина С 0 1 1 0

этап № 1 - на пине А лог 1 , на пине «С» лог 0.
триггер «U1.A» получает лог 1 на пин «R» тем самым деактивируя управление по «RS» (как мы помним они реагируют только на лог 0)
триггер «U1.A» получает лог единицу на пин «D» но пока на него триггер не реагирует ибо не было нарастающего фронта на пине «CLK»
триггер «U1.А» получает лог 0 на пин «CLK» , ничего не происходит
триггер «U1.В» получает лог 0 на пин «R» управление по «D» и «CLK» невозможно , триггер сброшен по «RS»
триггер «U1.В» получает лог единицу на пин «CLK» но триггер не отреагирует так как активно «RS» управление (даже если не обращать на это внимания у нас так и так на пине «D» лог 0 )
триггер «U1.В» получает лог 0 на пин «D», ничего не происходит

этап № 2 - на пине А лог 1 , на пине «С» лог 1.
триггер «U1.A» не меняет состояние на пинах «R» и «D»
триггер «U1.А» получает лог 1 на пин «CLK» , так как во время нарастающего фронта управление по «RS» было неактивно ,а на пине «D» была лог 1 , триггер «U1.А» устанавливаеться
триггер «U1.В» получает лог 1 на пин «R» тем самым деактивируя управление по «RS»
триггер «U1.В» не меняет состояние на пине «CLK»
триггер «U1.В» получает лог 1 на пин «D»,но ничего не происходит так как нарастающий фронт от единицы что сейчас на пине «CLK» прошел еще на первом этапе

этап № 3 - на пине А лог 0 , на пине «С» лог 1.
триггер «U1.A» получает лог 0 на пин «R» тем самым сбрасывая триггер
триггер «U1.A» получает лог 0 на пин «D» триггер не реагирует из-за активного управления по «RS»
триггер «U1.А» не меняет состояние пине «CLK» , ничего не происходит
триггер «U1.В» получает лог 0 на пин «CLK», ничего не происходит
триггер «U1.В» не меняет состояние на пинах «R» и «D»

этап № 3 - на пине А лог 0 , на пине «С» лог 0.
триггеры «U1.A» и «U1.В» получают на все входы лог 0 , и так как они оба сброшены по «RS» , рассматривать остальные пины нет смысла (желающим никто не запрещает).

Как видно из описания сработает только триггер «U1.А» , если-же вращать энкодер в другую сторону тогда сработает только «U1.В»

Вернемся к нашей схеме , на каждый неинвертирующий вывод поставлен переключающий диод (ультрабыстрый) и после диодов все сведено в 1 линию (подключена к осциллографу на вход D ), именно ее следует пускать микроконтроллеру на вывод с внешним прерыванием настроенным на нарастающий фронт таким образом алгоритм получиться следующий :
1) Ловим внешнее прерывание с диодов
2) В обработчике этого прерывания отключаем прерывания глобально
3) По очереди опрашиваем те пины МК куда заведены выходы триггеров на предмет лог 1 , тем самым определяем куда крутили энкодер (на схеме эти пины заведены на А и В входы осциллографа)
4) Определяемся какую задачу надо выполнить (тут полная творческая свобода)
5) В цикле while ждем пока не пропадет лог 1 с пина куда заведено прерывание (пропадет там == пропадет и на остальных заюзанных пинах)
6) Подстрахуемся от того что за время проведенное в обработчике произошло второе прерывание сбросив флаг прерывания (у авр-ок это INTFx)
7) Разрешим прерывания глобально

Непосредственно сам код приводить не буду ибо на схеме нет МК , но полагаю по приведенной выше инструкции даже минимальных знаний ЯП хватит что-бы юзать такую конструкцию с любым типом микроконтроллеров.

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

В целях увеличения надежности и помехозащищенности «S» пины каждого из триггеров подтянуты к плюсу питания резюком 1 КОм , это нужно для того что-бы исключить деятельность этого вывода от помех , так-же не забываем про резисторы R6 – R8 , возможно конечно встроенной в МК подтяжки и хватит, но симуляция в протеусе показала что без них могут быть глюки.

(с) acckyiboxxx

Файлы к статье см. в аттаче.

Это не статья, это пост.
Статьи засылаются сюда: http://radiokot.ru/upload/?new=1

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

понял, подправлю статью - вобью второй минус

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

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

и наконец третий вариант , запрещать только внешнее прерывание на котором висит энкодер , тогда все остальные прерывания будут отрабатывать нормально

Не, так не пойдет. Надо чтоб минусов совсем не было. Мне очень понравилась ваша идея и хорошо бы довести ее до состояния близкого к совершенству.


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


Чувствительных алгоритмов масса. Это передача данных (UART), программный I2C, 1-wire, управление задержками и импульсами. Если вставать в полный запрет прерываний, то со всем этим либо придется распрощаться, либо тратить дополнительные силы на развязывание от запрета прерываний.


Не очень понял, как узнавать, когда это прерывание опять разрешать нужно.

Мне понравилось такое решение, спасибо.Самое то
можно же просто проверять уровень на пине, как изменился обратно, значит пора?

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

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

1) запретили внешнее прерывание внутри обработчика
2) поняли что именно сработало и предприняли действия
3) подождали пока исчезнет лог единица на пине прерывания
4) разрешили внешнее прерывание
5) сбросили флаг этого прерывания

причем 4-й 5-й пункты менять местами не рекомендую так как при врубании прерывания этот флаг может установиться самопроизвольно и сразу после выхода из обработчика мы снова войдем в него



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

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

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

А как долго длится состояние "единица" при сигнале от энкодера?

0.25*дельта t

где дельта t == время одного полного такта энкодера


ps: надо-бы предложить администрации ввести доп смайлы с математическими символами , часто их так не хватает для удобного изложения мыслей ((

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

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


Я тоже вначале именно так и хотел, но теперь не понимаю, а что нужно делать по заднему фронту. Там тоже могут быть какие-то осмысленные действия?

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

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

acckyiboxxx, может и правда, лишние все движения будут по запрету-разрешению, проверьте?

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

лично я многие действия требующие серьезного количества процессорного времени выполняю внутри прерывания (иногда овер 100 строк кода) поэтому для меня так удобнее , и как вижу многие не поддерживают такой подход , посему предлагаю следующее :

отредактирую статью и опишу 2 алгоритма , первый уже описанный для таких-же деятелей как я , второй для "скоростных" , а далее пусть люди сами выбирают как действовать

в общем если есть что добавить то с удовольствием выслушаю , а завтра приступлю к доведению материала до ума

Потребуется аппаратная. Вот типичный сигнал с энкодера:

Спойлер

Вот здесь уже предлагали эту схему на 7474:



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

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

ps: форум по неведомым причинам запретил править первый пост, посему придется дождаться от вас схемы , провести тесты а потом скидывать модерам новый вариант на замену