Arduino.ru

а чо de Brabander с Гайвером говорят?

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

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

Правильно подключать энкодер - через прерывания. Ну либо заботиться, чтобы между вызовами encoder.tick() не было длительных задержек.

Попробуйте работу с LCD временно выкинуть из loop() вообще.

Не совсем так. Глючить начинает когда перед выводом параметра на дисплей (lcd.print(myparam);) я вывожу строку (lcd.print("Param: ");)

Если выводить просто:

Код выше - это максимально упрощенный и сохранивший этот глюк.

Вообще изначально код был больше и опрос энкодера и вывод на экран были в разных функциях и не в loop обе.

Я долго искал ошибку в своей логике. Думал это я чего намудрил. Но когда нашел причину и сделал код минимальным для глюка.

Неожиданно :(

Ок. Попробую другую библиотеку для энкодера. У Гайвера удобная работа с энкодером... вот и остановился на ней. И у него в этой библиотеке есть вариант использования энкодера по прерываниям. Тоже попробую.

Я надеялся что это известный глюк и есть стандартное его решение. Спасибо.

С другой тоже весьма вероятно упретесь в то, что при наличии функций, работающих с LCD, энкодер в линейном алгоритме точно так же будет работать непредсказуемо. Чуть побольше объёмы вывода и всё, приплыли. Вместо lcd.*() просто delay поставьте и получите схожую картину.

Хм... как же тогда с ними(энкодерами) работать.... Как понять "энкодер в линейном алгоритме"?

Или это как раз намек на "попробовать с энкодером работать через прерывания"?

В общем так и поступил. Но с Гайверской библиотекой.

#include <LiquidCrystal_I2C.h>
//name=LiquidCrystal_I2C
//version=1.1.4
//author=Frank de Brabander
//maintainer=Marco Schwartz <marcolivier.schwartz@gmail.com>
//sentence=A library for I2C LCD displays.
//paragraph= The library allows to control I2C displays with functions extremely similar to LiquidCrystal library. THIS LIBRARY MIGHT NOT BE COMPATIBLE WITH EXISTING SKETCHES.
//category=Display
//url=https://github.com/marcoschwartz/LiquidCrystal_I2C
//architectures=avr
#include <GyverEncoder.h>
//name=GyverEncoder
//version=4.8
//author=AlexGyver <beragumbo@ya.ru>
//maintainer=AlexGyver <beragumbo@ya.ru>
//sentence=Advanced library for encoder.
//paragraph=Allows to get maximum uses of encoder: turns, holded turns, fast turns and more.
//category=Sensors
//url=https://github.com/AlexGyver/GyverLibs
//architectures=*

#define CLK 2
#define DT 3
#define SW 4

Encoder encoder(CLK, DT, SW);
LiquidCrystal_I2C lcd(0x27, 20, 4);

void setup() {
  encoder.setType(TYPE2);
  lcd.init();
  lcd.backlight();
  attachInterrupt(0, isrCLK, CHANGE);    // прерывание на 2 пине! CLK у энка
  attachInterrupt(1, isrDT, CHANGE);    // прерывание на 3 пине! DT у энка
}

void isrCLK() {
  encoder.tick();  // отработка в прерывании
}
void isrDT() {
  encoder.tick();  // отработка в прерывании
}

#define FLASH_MS 400
uint32_t ms = 0;
byte myparam = 10;
bool f = true;
void loop() {

  encoder.tick();
  if (encoder.isRight() && myparam < 35) myparam++;
  if (encoder.isLeft()  && myparam > 10) myparam--;

  if (millis() - ms >= FLASH_MS) {
    f = !f; ms += FLASH_MS;
  }

  lcd.setCursor(0, 0);
  //      lcd.print(myparam);                               // Работает
  //      if (!f) lcd.print("   "); else lcd.print(myparam);  // Работает
  //      lcd.print("Param: "); lcd.print(myparam);           // Работает
        lcd.print("Param: "); if (!f) lcd.print("   "); else lcd.print(myparam); // Работает

}

Вроде нормально. Буду переносить "идею" в основной код и смотреть как это все заработает. Спасибо

Или все же рекомендуете использовать другую библиотеку? А какую лучше?

Я такую юзаю: https://github.com/PaulStoffregen/Encoder

Мне эта понравилась

Потому что

//author=AlexGyver

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

Из 12 скачал, но не смотрел.... Также не разобрался с "Лионидом Ивановичем".... И как я понял, все эти либы без обработки кнопки энкодера. Не критично, но...

В общем остановился пока на "гайвере" энкодер на двух прерываниях. Приемлимо. Посмотрю как будет дальше. У него(Гайвера) есть еще минилиба и просто "куски кода" для работы с энкодерами... Пока выявил небольшой (а может это и норма) косяк с пропуском шагов если ручку чуть побыстрее(не сильно) крутить...

//author=AlexGyver

Не пугайте меня) Неужели совсем так плохо?

Спасибо всем отвечавшим.

Воспользуйтесь "титановым велосипедом".

Да у гайвера там и на прерываниях написана какаято ересь...

я немца библиотеку юзаю, пропусков нет, все пины не пробовал, но импровизировал на разных, ведёт себя везде одинаково, сейчас к примеру на 4 и 5 у него там и на кнопку есть, одиночную, библиотека

А я вообще так до сих пор и не понял, зачем нужна библиотека энкодера, там кода 2-3 строки достаточно.

Ну типа того, вот с его сайта:

int32_t newEncoderPos = controlEncoder.read() / 4; - Это помогло.

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

И еще такой непонятный глюк появился. Если сразу как только запустить Arduino IDE 1.8.10 и в нем уже по умолчанию загружен скеч. Нажимаем "компиляция" или "Загрузка" не важно - то сразу вылазит:

Потому что файл не перекомпилируется, если он не изменялся.

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

Так-то можно вообще не использовать библиотек и самому все делать с нуля :)

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

Все равно не понятно.

Вот я открыл IDE с уже загруженном скечем. Нажимаю первый раз компиляция. Варнинг. Сразу второй раз. Чисто. Ведь я же его не менял.

Но даже если что-то изменить, сохранить. Закрыть ИДЕ. И заново открыть. То опять первый раз варнинг, второй четко.

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

А мой код на энкодер выглядит так:

#define ENC_B 3

volatile int encTick=0;

void enc_ISR(){
				digitalRead(2)==digitalRead(ENC_B)?encTick=1:encTick=-1;
}

void setup(){
				attachInterrupt(0,enc_ISR,CHANGE);
				pinMode(ENC_B,INPUT_PULLUP);
}
void loop(){
				
}

Зачем тут библиотека ?

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

Но даже так:

#define ENC_B 3

volatile int encTick = 0;

void enc_ISR() {
  digitalRead(2) == digitalRead(ENC_B) ? encTick = 1 : encTick = -1;
}

void setup() {
  attachInterrupt(0, enc_ISR, CHANGE);
  pinMode(ENC_B, INPUT_PULLUP);
  Serial.begin(9600);
}

int cnt = 0;
void loop() {
  if (encTick != 0) {
    cnt += encTick;
    encTick = 0;
    Serial.println(cnt);
  }
}

(Давно я не программировал... Можно ли так менять волатайловскую переменную?)

у меня получается два тика на один щелчок. 

Может у меня энкодер дибильный :(

В прочем если дальше с этим ядром делать то что нужно + обработка кнопки, короткое нажатие, длинное удержание... Получится кода на еще одну библиотеку :)

А кнопка вообще к энкодеру никакого отношения не имеет.
Там должен быть отдельный обработчик.
attachInterrupt() может быть не только CHANGE(с ним и будет два тика), а ещё и FALLING/RISING.
В коде был показан обработчик энкодера, как дальше использовать результат обработки, это уже отдельная песня.
Смысл приведения данного кода в том, что бы показать, что библиотека (любая,не говоря уже про библиотеку гивера) в принципе нафиг не нужна

в русском языке прижилось слово - волатильность )))
самое сложное как раз - как это использовать

Вам нужно устранять проблему, а не перебирать библиотеки.

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

Меня вот этот момент и задел. Как так, что варнинг показывается только при первой компиляции, а потом типа просто помни про него :( Я смотрел код библиотеки дисплея и его функцию begin и в теле begin действительно не используется передаваемый в нее параметр cols.

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

Я Вас понимаю и Вы в общем-то говорите правильно. Но как всегда есть но...

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

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

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

В конкретном моем случае я не уверен где основная ошибка. В библиотека энкодера гайвера, в библиотеке LCD, в версии IDE(ага, оказывается и такое может быть (но это не совсем так, новые компиляторы не совместимы со "старыми библиотеками" т.е. по сути дело не в IDE а в либах) или в моем коде. Хотелось бы разобраться.

Даже если самому с нуля делать можно так же напороться на грабли и долго искать проблему.

Уверен, что многие сейчас скажут. "Да вы что, я сам пишу все с нуля и никогда не наступаю на грабли и все у меня быстро решается и все у меня гладко" Я рад за таких людей и им завидую

Все теперь понятно, вопросов больше по данному вопросу не имею. Спасибо.

На данный момент с библиотекой гайвера работа с экодером даже по двум прерываниям происходит ужасно. Очень сильно пропускаются шаги. Ручку нужно крутить ну очень медленно, что бы работало... Поэтому буду пробовать может быть самому обрабатывать этот энкодер, например за основу возьму #25.

Но как-то странно получается. Я пересмотрел(поверхностно) код всех либ, которые тут озвучены. В некоторых много чего используется... А по сути на выходе тоже самое что и в #25 Не все так просто как кажется и не все так сложно как есть на самом деле :)

попробуйте библиотеку из поста #12, она точно не пропускает, числа правда даёт в относительных, от начала старта единицах, вот пример как устанавливаю частоту:
 

static int pos = 0;
  encoder.tick();

  int newPos = encoder.getPosition();
  if (pos != newPos) {
      if(max(newPos,pos) > pos){freq = freq +incr;}else{freq = freq - incr;}
      
    Serial.print("Freq = ");
    Serial.println(freq);
    ftFreq = freq/10;
    Serial.println(freq/1000.0f, 2);
    Radio.SetVfoFreq(ftFreq);
    pos = newPos;
  }

Пробуйте

bool f_two = 0;

void two() {// Прерывание Энодера В
  f_two = 1;
}

void one() {// Прерывание Энодера А
  if (f_two) { //Если было Прерывание Энодера B
    f_two = 0;
    digitalRead(2)==digitalRead(ENC_B)?encTick=1:encTick=-1
  }
}

void setup() {
  attachInterrupt(0, one, FALLING);
  attachInterrupt(1, two, FALLING);

}

А вообще,что бы дисплей с энкодером не конфликтовали, дисплей нужно обновлять только тогда, когда обновляются выводимые данные, да и в принципе если это будет происходит с частотой достаточной для восприятия (скажем 5-10Гц), таких проблем не будет.

Накладки и задержки всегда будут. Выводи хоть раз в секунду, хоть раз в 10 секунд. Не с дисплеем, так с другим чем-то всплывёт задержка.

  if (pos != newPos) {
      if(max(newPos,pos) > pos){freq = freq +incr;}else{freq = freq - incr;}

Попробовал. Там в этом RotaryEncodor'е есть кстати getDirection()... Правда я со своими познаниями си сходу не понял как ее использовать. Но вот:

#include <RotaryEncoder.h>

// Setup a RoraryEncoder for pins:
RotaryEncoder encoder(2, 3);

void setup()
{
  Serial.begin(9600);
  Serial.println("SimplePollRotator example for the RotaryEncoder library.");
} // setup()


// Read the current position of the encoder and print out when changed.
int pos = 0;
void loop()
{
  encoder.tick();
  delay(10);
  int n = (int)encoder.getDirection();
  if (n == 1) {pos++; Serial.println("Rotate Right");}
  if (n == -1) {pos--; Serial.println("Rotate Left");}
  if (n != 0) {Serial.println(pos);}
} // loop ()

Если убрать delay(10) - (довольно большая в принципе задержка, но все же) то да, пропусков нет.

В общем наверное не все так просто с этими энкодерами(

PS:

#include <RotaryEncoder.h>

// Setup a RoraryEncoder for pins:
RotaryEncoder encoder(2, 3);

void setup()
{
  Serial.begin(9600);
  Serial.println("SimplePollRotator example for the RotaryEncoder library.");
} // setup()


// Read the current position of the encoder and print out when changed.
int pos = 0;
void loop()
{
  encoder.tick();
  delay(10);
  switch (encoder.getDirection()) {
    case RotaryEncoder::Direction::CLOCKWISE:
    pos++; Serial.println("Rotate Right"); Serial.println(pos);
    break;
    case RotaryEncoder::Direction::COUNTERCLOCKWISE:
    pos--; Serial.println("Rotate Left"); Serial.println(pos);
    break;
    case RotaryEncoder::Direction::NOROTATION:
    break;
  }
} // loop ()

Дык они и обновляются при вращении ручки энкодера :( Но вообще полностью согласен. Здесь по ходу нужно какую-то "хитрую" логику делать...

Но тут по всей видимости не только в дисплее дело :(

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

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

.....

Самый лучший результат пока получился. Спасибо.

В прочем это практически код из 25. Моя лень и низкие знания си не дали мне сразу сообразить это:

#define ENC_B 3
volatile int encTick=0;
bool f_two = 0;

void two() {// Прерывание Энодера В
  f_two = 1;
}

void one() {// Прерывание Энодера А
  if (f_two) { //Если было Прерывание Энодера B
    f_two = 0;
    digitalRead(2)==digitalRead(ENC_B) ? encTick=1 : encTick=-1;
  }
}

void setup() {
  attachInterrupt(0, one, FALLING);
  attachInterrupt(1, two, FALLING);
  Serial.begin(9600);
}

int cnt = 0;
void loop() {
  if (encTick != 0) {
    cnt += encTick;
    encTick = 0;
    Serial.println(cnt);
  }
  delay(50);
}

Но vosara мне дал хорошего пинка)

Как видно задержку я увеличил в пять раз (по сравнению с кодом использования библиотеки RotaryEncoder в #40) и все равно пропусков нет.

Да, если ручку вертеть слишком быстро, то может и пропускаются шаги, но они идут (в данном случае cnt увеличивается/уменьшается) строго на 1

В общем остановлюсь я пока на данном варианте

Немного подправил. Сделал для теста вот такой код:

#include <LiquidCrystal_I2C.h>

#define ENC_A  2
#define ENC_B  3

LiquidCrystal_I2C lcd(0x27, 20, 4);

bool f_isrA = false;
volatile char encTick = 0;
void isrA() {
  f_isrA = true;
}

void isrB() {
  if (f_isrA) {        //Если было Прерывание Энодера A
    f_isrA = false;
    digitalRead(ENC_A) == digitalRead(ENC_B) ? encTick = 1 : encTick = -1;
  }
}

void setup() {
  lcd.init(); lcd.backlight();
  attachInterrupt(0, isrA, FALLING);    // прерывание на 2 пине! A у энка
  attachInterrupt(1, isrB, FALLING);    // прерывание на 3 пине! B у энка
  Serial.begin(9600);
}

int cnt = 0;
void loop() {
  if (encTick != 0) {
    cnt += encTick;
    encTick = 0;
    Serial.println(cnt);
  }
  UpdateScreen();
  delay(50);    //Специальная задержка для теста
}

#define PERIODMS 400
uint32_t msscr = 0;
void UpdateScreen() {
  lcd.setCursor(0, 0);
  lcd.print("Test Encodera");  //Специальная задержка для теста
  static bool f = true;

  if (millis() - msscr >= PERIODMS) {
    f = !f; msscr += PERIODMS;
  }
  lcd.setCursor(0, 2);
  lcd.print("Value: "); if (!f) lcd.print("    "); else lcd.print(cnt);
}

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

Вопрос: переменную bool f_isrA = false; не нужно делать валотайловой(или валотильной, как правильно, вообщем volatile)?

Она хоть и используется только в прерываниях, но всеж...

//Да, если ручку вертеть слишком быстро, то может и пропускаются шаги

разумеется будут пропуски если cnt суммировать в лупе, а не там, где encTick получен.

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

И еще. "Дребезг" вызывает частые вызовы обработчиков прерывания, что плохо. Потому в качестве f_isrA лучше использовать флаги разрешения прерываний. Т.е. всегда разрешено только одно из прерываний. Например разрешено сразу isrA. При срабатывании isrA разрешаем isrB и запрещаем isrA. Потом при срабатывании isrB разрешаем isrA и запрещаем isrB, ну и encTick присваиваем (или может увеличиваем или уменьшаем? ;)

// Вопрос: переменную bool f_isrA = false; не нужно делать валотайловой(или валотильной, как правильно, вообщем volatile)?

Тут пофиг оно.

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

#46 - спасибо. Т.е. пока у меня новый энкодер, код из #44 работает нормально. Но скоро придет проблема. Правильно я понял?

Буду учитывать замечания по дребезгу и прерываниям. Всем спасибо.

В логике я еще разберусь, но для меня сложна в разбирании бинарная математика :( Если Вы обратили внимание, то я иногда тут поправляю код. Стараюсь его оптимизировать. Может и не получается у меня, но я ...стараюсь) И вы(все) мне в этом очень помогаете. Спасибо

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