Енкодер + антидребезг + микроконтролер = "работаю как хочу"

[SmarTrunk]

КРАМ
Я считаю, что это разные вещи.

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

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

[КРАМ]

КРАМ
Я считаю, что это разные вещи.

А я и не спорю с этим.
Дело не в том, что они разные, а в том, что обработка может быть ОДИНАКОВОЙ.
Для обычных кнопок она может оказаться и избыточной, но зато ЕДИНЫЙ алгоритм даст дополнительные удобства для кода в целом.
Фильтрация в обработчике сводится к организации битового буфера длиной в несколько тиков (по сути один байт, куда каждый тик задвигается состояние контакта). Сколько контактов, столько и буферов.

[pyzhman]

А кто будет ресетить флаги состояния?

Программист, надо полагать. Зависит от конкретной задачи. Я дал лишь суть.

[rx3apf]

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

[КРАМ]

А разве у кнопки нельзя организовать машину состояний? И разве кнопки всегда имеют одинаковый алгоритм?
В том и дело, что кнопки могут иметь сложный функционал, а паче ВЗАИМОДЕЙСТВИЕ между собой.
И в этом случае ничем от энкодера не отличаются.
Общий и УНИВЕРСАЛЬНЫЙ код практически не дает оверхеда даже при ограниченной функциональности клавиатуры, но позволяет оперативно изменить эту самую функциональность, ничего не добавляя-убавляя в самом коде.
ЗЫ. Сам по себе автомат состояний дребезг полностью не удаляет. Возможны неприятные ложные срабатывания при нечеткой фиксации положения энкодера.

[rx3apf]

ЗЫ. Сам по себе автомат состояний дребезг полностью не удаляет. Возможны неприятные ложные срабатывания при нечеткой фиксации положения энкодера.

На практике - удаляет полностью. Я обычно проверяю так - риска на ручке в определенную позицию, несколько раз вал с разными скоростями вперед-назад, и после возврата риски на прежнее место код должен совпасть. Совпадает.

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

[shads]

Эти задачи (энкодер и кнопки) решаются по-разному.

+1...
Я пользуюсь такими вариантами:
http://asis-kbr.ru/forum/viewtopic.php?f=13&t=173
http://asis-kbr.ru/forum/viewtopic.php?f=13&t=141

[Alexeyslav]

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

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

[Electro_Alex]

Здравствуйте, уважаемые коты!
Очень заинтересовала тема про обработку энкодера и устранение дребезга.
Изначально я хотел написать в тему viewtopic.php?f=20&t=76027 , но она закрыта, к сожалению. Поэтому пишу сюда. Заранее извиняюсь, если не совсем попал в тему.
По данной ссылке есть код Леонида Ивановича. Идея состоит в применении гистерезиса - сравнивается не только текущее и предыдущее состояние, но пре-предыдущее. Сразу оговорюсь, что я начинаю писать под МК на Си. Я не совсем понял обработку состояния в самом начале. Терзали сомнения. Произвел симуляцию в Протеусе (нашел в одной статье как моделируется энкодер с применением МК и кодом для него). Дребезг бывает проскакивает Поломав голову, рассмотрев все возможные варианты поведения энкодера при дребезге, написал свой код. В нем учитывается как раз пре-предыдущее состояние. Привожу свой код. Извиняюсь, если он быдлокодерский, но мне пока так проще понимать.
Процедура обработки срабатывания таймера (производится периодический опрос энкодера). Суть в том, что изменение переменной происходит, если пройдено последовательно три состояния.

{
char NewState = PINA & 0b00000011;
if(NewState != OldState) //если состояние изменилось,
{
if(NewState != OldOldState) //если текущее и пред-предыдущее не равны,
{
switch(OldState+OldOldState) {
case 5:
{
if(NewState == 1) upState++;
if(NewState == 0) downState++;
break;
}
case 4:
{
if(NewState == 0) upState++;
if(NewState == 2) downState++;
break;
}
case 1:
{
if(NewState == 2) upState++;
if(NewState == 3) downState++;
break;
}
case 2:
{
if(NewState == 3) upState++;
if(NewState == 1) downState++;
break;
}
}
OldOldState=OldState;
OldState=NewState;
}
}

[GARMIN]

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

Спойлер

Занимаюсь новым интерфейсом для своих систем. Разработал простую и интересную программу для работы с энкодером. Мне она понравилась, и захотелось поделиться удачной программой.
Просматривая аналогичные решения по обработке сигналов от инкрементального энкодера, я увидел три способа решения задачи:
1) с помощью условных переходов и статических переменных, хранящих предыдущие состояния энкодера;
2) с помощью машины состояний, которая переключается по сигналам энкодера, исключая запрещённые состояния.
3) вариация номера два с использованием switch - case с метками возможных состояний.
Однако, все варианты имеют недостатки.
Вариант номер один использует несколько переменных и переключается один раз за четыре возможных состояния энкодера.
Вариант номер два использует одну переменную, в которой хранятся в битовом представлении текущее и предыдущее состояние энкодера. Анализ состояний производится с помощью массива данных. Это вариант мне понравился больше всего. Но в том состоянии алгоритм не защищён от ложных срабатываний и пропуска данных.
Вариант номер три использует такое же представление данных, как и вариант номер два, но вместо массива данных использует переход по множеству case меток. Самый неудобный и трудный для восприятия.
Взяв второй метод за основу, я доработал его до приемлемого вида.
Вначале основы.
При повороте энкодера по часовой стрелке состояние выводов изменяются как
00, 01, 11, 10, 00...
А при повороте против часовой стрелки состояние выводов изменяется в другой последовательности:
00, 10, 11, 01, 00...
Считывать состояния энкодера можно один, два или четыре раза за период, но необходимо учитывать предыдущее состояние. Например, если текущее состояние энкодера 11 и предыдущее значение 01, то энкодер повернули по часовой стрелке. А если предыдущее значение 10, то энкодер повернули против часовой стрелки. Соответственно, предыдущие состояния 00 и 11 будут ошибочными, и их нужно игнорировать.
Итак, мы имеем 4 варианта текущего состояния и 4 варианта предыдущего состояния энкодера. Вместе они дают 16 комбинаций. Если взять переменную из четырёх бит, и в младшие два бита записать текущее состояние, а в старшие два - предыдущее состояние, и использовать получившееся число как индекс в массиве, то с помощью значений чисел в массиве возможно точно определить состояние энкодера. Например, 1 - поворот вправо, -1 - поворот влево, 0 - запрещённая комбинация.
Что самое интересное, это то, что такой алгоритм можно применять как для одного изменения энкодера за период, так и для двух и четырёх изменений. А это важно, потому что встречаются энкодеры с разным количеством периодовза оборот. Например, энкодеру с 12 периодами однозначно понадобится 2 или 4 изменения за период, а энкодеру с 48 периодами не больше 1.
Возможность подстройки под тип энкодера это первое преимущество. Второе - я добавил защиту от повторных срабатываний при одинаковом положении энкодера. Например, встретилось два подряд значения 01. Без фильтрации это вызовет запрещённое состояние 01-01 и ошибку в определении следующего состояния. Почему - ответ в третьем преимуществе. Программа анализирует три последовательные состояния энкодера, и при переходе, например, 00-01-00 (то есть шаг туда, шаг сюда) не будет двух ложных срабатываний энкодера. Без фильтрации мы можем получить последовательность состояний 00-01-01-00 и сравнение текущего и третьего состояний не решит проблему дрожания энкодера. Такая проверка нужна для 1-го и 2-х срабатываний за период энкодера.
Программу я писал для микропроцессора STM8S в среде IAR. Текст приведён ниже:

Код: Выделить всё

// определение количества событий за период энкодера (1, 2, 4)
#define   ENC_COUNT      2   
// массив правильных значений переходов 
// между предыдущим и настоящим значением энкодера
#if (ENC_COUNT == 1)
// для 1-го переключения за период
int8_t enc_array [16] =
{
    0,  0,  0,  0,
   -1,  0,  0,  0,
    1,  0,  0,  0,
    0,  0,  0,  0
};
#elif (ENC_COUNT == 2)
// для 2-х переключений за период
int8_t enc_array [16] =
{
    0,  0,  0,  0,
   -1,  0,  0,  1,
    1,  0,  0, -1,
    0,  0,  0,  0
};
#else         
// для 4-х переключений за период
int8_t enc_array [16] = 
{
    0,  1, -1,  0,
   -1,  0,  0,  1,
    1,  0,  0, -1,
    0, -1,  1,  0
};
#endif

uint8_t      state         = 0;   // сохранённые состояния энкодера
int8_t      count_encoder   = 0;   // переменная приращения энкодера

/*****************************************************************************
* Настройка энкодера. 
* Ножки на вход с подтяжкой к питанию
* Прерывания на этот порт с активацией по фронту и спаду
* Приоритет высокий
*****************************************************************************/
void encoder_init (void)
{
   // настройка контроллера прерываний
   __disable_interrupt();
   EXTI->CR1 &= ~EXTI_CR1_PAIS_MASK;
   EXTI->CR1 |= 0x03;   //EXTI_CR1_PAIS_FR;      // Прерывания А по фронту и спаду
   // настройка приоритетов прерываний
   ITC->ISPR2 &= ~ITC_SPR2_PORTA_MSK;
   ITC->ISPR2 |= ITC_SPR2_PORTA_LVL3;         // высокий уровень прерываний порта A
   // настройка ножек
   GPIO_ConfigInput (ENC_A_PORT1, ENC_A_PIN1, PinPullup, PinIrqOn);
   GPIO_ConfigInput (ENC_B_PORT1, ENC_B_PIN1, PinPullup, PinIrqOn);
   // установка текущего состояния энкодера
   if (ENC_A_PIN)
      state |= 0x01;
   if (ENC_B_PIN)
      state |= 0x02;
   __enable_interrupt();
}

/*****************************************************************************
* Прерывание по порту A
* здесь опрашивается состояние энкодера
* результат прерывания сохраняется в переменной count_encoder
*****************************************************************************/
INTERRUPT_HANDLER (Port_A_EXTISR, 3)
{
   int8_t   stt;
   state <<= 2;                           // освободили место для новых значений
   if (ENC_A_PIN)
      state |= 0x01;
   if (ENC_B_PIN)
      state |= 0x02;                        // считали данные энкодера
   if ((state & 0x03) != ((state >> 2) & 0x03))   // если разные значения с предыдущим
   {
      stt = enc_array [state & 0x0F];            // получили условие из таблицы
      if (stt)                           // при изменении энкодера
      { 
#if (ENC_COUNT == 1 || ENC_COUNT == 2)      
         if ((state & 0x03) != ((state >> 4) & 0x03))   // и если энкодер не вернулся обратно   
#endif
         {
            count_encoder += stt;               // изменим счётчик энкодера
         }
      }
   }
   else
   {
      state >>= 2;                        // если одинаковые значения - вернуть state
   }
}


/*****************************************************************************
* функция int_8t encoder() возвращает изменение положения
* энкодера после последнего чтения, если энкодер не двигался, то 0
******************************************************************************/
int8_t encoder (void)
{
   int8_t status = count_encoder;
   count_encoder = 0;
   return status;
}

Позже добавил пропорциональное управление энкодером. В зависимости от скорости вращения переменная count_encoder изменяется или на единицу (медленное вращение), или на десяток (вращение со средней скоростью), или на сотню (быстрое вращение). Это позволило быстро вводить энкодером числа от 1 до 1000. Согласитесь, крутить 50 оборотов, чтобы выставить 1000 - занятие неблагодарное

[Lum1noFor]

Всем привет! Также столкнулся с проблемой считывания с энкодера. Только проблема, скорее, не в том, что теория сложна, а в том, что 99% энкодеров, что сейчас продаются - совершенно другие! Они не подчиняются классической теории, описанной на просторах интернета. В этой теории сказано, что инкрементальный энкодер должен давать ИМПУЛЬС на каждый клик. Те же энкодеры, что продаются сейчас, дают не импульс, а тупо меняют состояние своих каналов на противоположные с определенной задержкой между фронтами (так называемые "двухкликовые"). Я разобрался, как с ними работать на прерываниях, но как считать его тупым опросом - без идей. В моем текущем проекте применять энкодер на прерываниях нежелательно. Кто-нибудь работал с ними?

P.S. Может, кому понадобится, как работать с такими энкодерами на прерываниях:

1. Подключаем энкодер каналами A и B через RC-фильтр (0.1 uF на землю, 10k на плюс питания). Общий вход энкодера на землю. Канал A на вход внешнего прерывания микроконтроллера. Я использовал PIC18, поэтому этот канал будет INT0. Второй канал подключаем на любой I/O вход МК. Каналы желательно подключать через 74HC14, чтобы "выправить" сигнал после фильтра.
2. Выставляем любой фронт срабатывания INT0.
3. По срабатыванию прерывания INT0 проверяем состояние линии B энкодера. Если 1, то инкремент, если 0 - то декремент.
4. В самом прерывании меняем фронт срабатывания INT0 на противоположный и меняем условия декремента и инкремента на противоположные. Это позволит энкодеру срабатывать на каждый клик, а не на каждые два.
5. Выходим из прерывания.

Код на ПИК для понимания смысла прикрепляю ниже.

Код: Выделить всё

// INTEDG0 - бит фронта прерывания INT0. Если INTEDG0 = 1, то нарастающий, если INTEDG0 = 0 - спадающий.
// Канал A энкодера висит на INT0, канал B - на RB2.

void Encoder() iv 0x0008  {           // Вектор высокоприоритетного прерывания.


if (INTCON2.INTEDG0 == 0) {       // Если прерывание INT0 стоит по спадающему фронту, то условие прямое:

 if (PORTB.B2 == 1) {                  // Если во время нарастающего фронта PORTB.B2 равен единице, то инкремент. 
   A++;
 }

 if (PORTB.B2 == 0) {                  // Если во время нарастающего фронта PORTB.B2 равен нулю, то декремент. 
  A--;
 }

}


if (INTCON2.INTEDG0 == 1) {     // Если прерывание INT0 стоит по нарастающему фронту, то условие обратное:

 if (PORTB.B2 == 0) {                // Если во время спадающего фронта PORTB.B2 равен нулю, то инкремент. 
  A++;
 }

 if (PORTB.B2 == 1) {                // Если во время спадающего фронта PORTB.B2 равен единице, то инкремент. 
  A--;
 }

}


INTCON2.INTEDG0 = ~INTCON2.INTEDG0;          // Меняем фронт срабатывания INT0 на противоположный.

INT0IF_bit = 0;                                                   // Сбрасываем флаг прерывания.
}

[КРАМ]

[uquote="Lum1noFor",url="/forum/viewtopic.php?p=3769515#p3769515"]Всем привет! Также столкнулся с проблемой считывания с энкодера.[/uquote]
Энкодеры нужно обрабатывать точно так же, как и кнопки. То есть в прерывании, но не от энкодера, а от ТАЙМЕРА с интервалом больше, чем дребезг энкодера. Или даже чуть меньше, но с двухуровневым опросом, если нужна высокая скорость переключений.
Если энкодер вращают со скоростью такой, что время дребезга перекрывает один импульс, то машина состояний в совокупности с таймером антидребезга будет пропускать срабатывания, но не вызывать ложные переключения.
Ставить емкость на контакты энкодера, значит убить энкодер в самые короткие сроки. Ток через контакты ограничен даташитом на уровне порядка 10 мА. Разряд емкости через контакт будет приводит к току порядка единиц ампер и быстрому обгоранию оных контактов. Впрочем, сама по себе емкость - просто лишняя сущность.
Это во-первых.
А во-вторых, я ничего не понял из Ваших объяснений про "один импульс". Все встречавшиеся мне до сих пор механические инкрементальные энкодеры были идентичны по своей диаграмме энкодерам Bourns: https://www.bourns.com/docs/product-dat ... 58877ff9_9 и имеют оную диаграмму следующего вида:



То есть в статическом положении оба контакта РАЗОМКНУТЫ, что естественно, ибо иначе устройство в статике начнет потреблять энергию через подтяжки к питанию.

[Ivanoff-iv]

Lum1noForу попался энкодер с трещёткой на 2 шага и из состояния ++ в -- (и обратно) он переходит слишком быстро, Люминофор боится не поймать переходные для этого энкодера состояния +- и -+ (а без них не оеределить направления).

[КРАМ]

Слишком быстро - это сколько? Типовой дребезг механических энкодеров - 2 мс (два фронта на один щелчок - 4 мс). Пускай энкодер имеет 24 дискрета на оборот (по максимуму). Пускай угл. скорость вала составляет 2 об/сек, тогда время переключения одного дискрета составит 21 мс. Итого, на статические состояния остается 17 мс. Этого достаточно для фиксации каждого щелчка.

[jcxz]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3769543#p3769543"]То есть в статическом положении оба контакта РАЗОМКНУТЫ, что естественно, ибо иначе устройство в статике начнет потреблять энергию через подтяжки к питанию.[/uquote]Это как это? А если остановили крутилку в таком положении, когда хотя бы один из сигналов == ON? Она что - сама должна довернуть себя до двух OFF?
Чтобы не было потребления в статическом состоянии, нужно просто сделать подтяжки коммутируемыми и включать их только на время опроса.
А в остальном - согласен.

Добавлено after 7 minutes 58 seconds:
[uquote="КРАМ",url="/forum/viewtopic.php?p=3769635#p3769635"]Пускай угл. скорость вала составляет 2 об/сек, тогда время переключения одного дискрета составит 21 мс. Итого, на статические состояния остается 17 мс. Этого достаточно для фиксации каждого щелчка.[/uquote]...Если только, для уменьшения дискретности, не поставят редуктор.

[Lum1noFor]

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

Второй тип - двухкликовый энкодер. Его отличия от однокликового в том, что он дает полный прямоугольный импульс за ДВА клика. При этом за один импульс он дает только изменение логического состояния каналов A и B на противоположное. То есть, допустим, на выходах энкодера изначально был ЛОГ0. Вы делаете один клик, и согнал на выходах меняется с ЛОГ0 на ЛОГ1 и, ВНИМАНИЕ, ОСТАЕТСЯ ТАКИМ (в состоянии ЛОГ1) до тех пор, пока вы не сделаете еще один клик! При этом фронт изменения логического уровня одного из каналов происходит либо раньше, чем у другого канала (вращение в одну сторону), либо позже (вращение в противоположную сторону).

Вот осциллограммы работы данного типа энкодера (прошу прощения за качество, мой осциллограф - ведро).

1. Сделали один клик. ЛОГ0 изменился на ЛОГ1 и остался таким. Триггер на нарастающий фронт по каналу 1.


2. Сделали второй клик. ЛОГ1 изменился на ЛОГ0 и остался таким.


3. Сделали два клика с интервалом 5 секунд.


4. При большом увеличении - вращение в одну сторону.



4. При большом увеличении - вращение в противоположную сторону.


И причем самое противное, что, покупая энкодер, вы совершенно не знаете, какой из них вам попадется (причем, с вероятностью 70% Вам попадется именно двухкликовый).

Я думаю смысл должен быть понятен. И мой вопрос, собственно, в том, работал ли кто-нибудь с этим типом энкодеров методом опроса? Какова логика работы?

[Ivanoff-iv]

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

[Lum1noFor]

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

Да, именно это имелось ввиду.

Код: Выделить всё

думаю, они внутри могут быть полностью одинаковыми и отличаться только трещёткой...

С этим тоже согласен.

[КРАМ]

[uquote="jcxz",url="/forum/viewtopic.php?p=3769639#p3769639"]А если остановили крутилку в таком положении, когда хотя бы один из сигналов == ON?[/uquote]
Попробуйте оставить состояние между щелчками, а я посмеюсь...
Коммутация подтяжки ничего по сути не решает. Ну будет ток меньше с учетом скважности. А если учесть, что энкодер механический, то коммутация подтяжек вообще не комильфо. Может не восстановиться контакт.
У меня PEC12 в фиксированных состояниях выключает оба контакта.
По поводу алгоритма. По сути для варианта с "двумя кликами" нужно немного изменить машину состояний. Принципиально ничего не изменится. Вместо 16 состояний будет 8. Всего и делов.

[Lum1noFor]

После еще нескольких часов экспериментов с кучей энкодеров я выяснил, что ув. Ivanoff-iv был прав - количество кликов энкодера на один полный импульс не зависит от конструкции контактов, а зависит только от трещётки. Нашел среди энкодеров одной конструкции как однокликовые, так и двухкликовые. Отредактировал свои предыдущие посты, чтобы не вводить людей в заблуждение.

И вот, кстати, правильная схема включения энкодера, рекомендуемая самим Bourns. В схему включены дополнительные резисторы на 10 кОм последовательно с каналами для устранения проблемы обгорания контактов энкодера из-за фильтрующих емкостей.