Эффективный способ подключения инкрементального энкодера

[balmer]

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

[a5021]

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



Ключевой момент, когда он говорит "sometimes it gets a glitch" -- время от времени проходит помеха. Причем, все это видно на прыгающих значениях индикатора. Т.е. даже с развязкой через триггеры Шмитта оно все равно допускает ложные срабатывания.

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

А можно просто использовать микроконтроллер, в который энкодер понимает аппаратно. Те-же STM32

Аппаратный пробинг, как средство борьбы с дребезгом контактов, есть не только у STM32. Зачатки оного можно даже у AVR наблюдать. На STM8 почи весь набор, что и на STM32.

Говоришь ему - энкодер подключен к такимто контактам.

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

Дребезг контактов естественно обрабатывается аппаратно.

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

[acckyiboxxx]

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

[Ser60]

Используйте оптические энкодеры и проблемы с дребезгом исчезнут. Такие по стоимости сейчас не намного дороже механических.

[acckyiboxxx]

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

[a5021]

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

В протезе есть генератор с формой выходного сигнала по образцу.



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

[Ser60]

не знаю где вы нашли дешевые оптические

Вот, например, модели серий EM14A0D и C14D16P от Bourns и CUI, соответственно за 13$ и17$, с которыми я имел дело. Да, дороже механических, но зато чистый сигнал и процессор не отвлекается понапрасну. А может для Ваших приложений подойдет touch panel с внешним контроллером (справа, 10$). Она одна может заменить ощутимое число других органов настроек. В прошлом году делал проект с такой на лицевой панели и нарисованными под ней кнопками. Контроллер TSC2007 от ТИ подавляет весь дребезг и упрощает программу МК.

[acckyiboxxx]

a5021, Ser60, спасибо за информацию , как проведу исследования результаты улетят в первый пост

[Леонид Иванович]

В STM32 не использую аппаратную обработку энкодера по следующим причинам:

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

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

Спойлер

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

//----------

//Модуль поддержки энкодера

//Энкодер подключается к портам ENC_F1 (фаза 1) и ENC_F2 (фаза 2).
//Функция Enc_Exe() вызывается в основном цикле.
//Результат обработки энкодера может быть прочитан
//с помощью функции Encoder_GetCode().

//----------

#include "Main.h"
#include "Encoder.h"

//---------- Константы: ----------

enum { State0, StateA, StateB, StateAB }; //состояния энкодера

//---------- Переменные: ----------

static char EncPrev;      //предыдущее состояние энкодера
static char EncPrevPrev;  //пред-предыдущее состояние энкодера
static char Code;         //код энкодера

//---------- Инициализация энкодера: ----------

void Encoder_Init(void)
{
  EncPrev = State0;       //инициализация предыдущего состояния
  EncPrevPrev = State0;   //инициализация пред-предыдущего состояния
  Code = ENC_NO;          //нет поворота
}

//---------- Обработка энкодера: ----------

void Encoder_Exe(void)
{
  char EncCur = 0;
  if(!Pin_ENC_F1) EncCur  = StateA; //опрос фазы 1 энкодера
  if(!Pin_ENC_F2) EncCur |= StateB; //опрос фазы 2 энкодера
  if(EncCur != EncPrev)             //если состояние изменилось,
  {
    if(EncPrev == StateAB &&        //если предыдущее состояние StateAB
       EncCur != EncPrevPrev )      //и текущее и пред-предыдущее не равны,
    {
      if(EncCur == StateB)          //если текущее состояние StateB,
        Code = ENC_DN;              //шаг вниз,
          else Code = ENC_UP;       //иначе шаг вверх
    }
    EncPrevPrev = EncPrev;          //сохранение пред-предыдущего состояния
    EncPrev = EncCur;               //сохранение предыдущего состояния
  }
}

//---------- Чтение кода энкодера: ----------

char Encoder_GetCode(void)
{
  return(Code);
}

//---------- Установка кода энкодера: ----------

void Encoder_SetCode(char c)
{
  Code = c;
}

//----------

[Morroc]

А если в основном цикле есть неделимые куски кода, выполняемые достаточно долго ? Например вывод на графический дисплей.

[Леонид Иванович]

Ну и что? Все равно тогда основной цикл не сможет отреагировать на энкодер, как его ни опрашивай.

[Morroc]

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

[ARV]

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

[Morroc]

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

[ARV]

неприятно? да фигню вы говорите, уважаемый! ибо человек не в состоянии заметить 20 миллисекундную задержку в принципе, а большинство и 0,1 секундную не замечают! а для МК 20мс это много, а 100мс - почти вечность! и печалиться о том, что реакция на энкодер будет задержана на это время - просто приступ перфекционизма в шизоидной стадии!

про пропуск щелчка я сказал утрируя, ибо чтобы возник пропуск надо программу писать на MS Visual C и исполнять в ОС Windows, все прочее успеет энкодер обработать "мгновенно"

[Morroc]

Я не про задержку реакции системы относительно пользователя, а именно про пропуск шагов энкодера. Пример вполне типичный привел - графический индикатор (особенно цветой или подлюченный по i2c), в процессе вывода (допустим) частоты на который энкодер продолжает вращаться. Если использовать LCD 16*2 и простейший энкодер на 24 щелчка пропусков почти нет даже если просто опрашивать - это да, уже попробовал

[ARV]

на дохленькой меге с низкоскоростным SPI я заполнял цветной дисплейчик от сименса примерно 12-15 раз в секунду, выводя различные геометрические фигуры. поэтому я с твердой уверенностью заявляю, что никакой вывод на ЖКИ не сможет привести к пропуску шагов энкодера даже при его опросе в главном цикле!
ну, если вы хотя бы немного умеете писать программы, конечно

[Morroc]

За 50 мс заполнения экрана разве не могут импульсы придти ? В приличном энкодере вроде 400 импульсов на оборот. Хотя ситуация когда это нужно может и нечастая, кроме как частоту менять я так сходу и придумать не могу где надо так быстро крутить. Оптический я не пробовал без прерываний, если не забуду гляну на выходных.

[akl]

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

[Леонид Иванович]

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

От этого больше вреда, чем пользы. Допустим, регулируем напряжение БП. Программа чем-то занялась и перестала реагировать на события. Затем освободилась и отработала сохраненные события - напряжение прыгнуло неизвестно как, что может иметь катастрофические последствия. Если событие не можем обработать, его нужно пропускать, а не сохранять.

В приличном энкодере вроде 400 импульсов на оборот.

Это какая-то экзотика. Обычно не больше 24 импульсов на оборот. Именно о таких обычных энкодерах здесь речь.

Энкодер, довольно шустро, может вращать станок

Энкодеры на валах двигателей - это совсем другая история.