Interrupt example not actually using interrupts

[gi1mic]

The Interrupt example should be changed to use the following format in the setup section

     attachInterrupt(digitalPinToInterrupt(pin), ISR, mode)

i.e. attachInterrupt(digitalPinToInterrupt(PIN_IN1), checkPosition, CHANGE); attachInterrupt(digitalPinToInterrupt(PIN_IN2), checkPosition, CHANGE);

and then the line

     encoder.tick();

can be removed from the loop function.

As shipped the example does not use interrupts and simply polls encoder changes.

[wotupfoo]

In examples/InterruptRotator/InterruptRotator.ino the setup() calls attachInterrupt() and the checkPosition() interrupt routine is right above it in the code. So while calling .tick() method in loop() is pointless, it is interrupt driven by the checkPosition handler.

[mathertel]

First: The attachInterrupt was missing – now it is present now and should work. Update to version 1.5.2.

Just to verify your findings I did the following using an ESP8266 nodemcu board using the InterruptRotator.ino example:

• Added pinMode(D1, OUTPUT) to setup().
• Modify checkPosition() to add some output on D1.

  IRAM_ATTR void checkPosition()
  {
  long p1 = encoder->getPosition();
  encoder->tick(); // just call tick() to check the state.
  long p2 = encoder->getPosition();
  if (p1 != p2) {
  digitalWrite(D1, ! digitalRead(D1));
  }
  }

  This was generating changes on D1 as expected with a HIGH/LOW change on every turn. The means that input signal changes are now detected by the interrupt routine as expected.

Then I removed the modifications above and added the code around the tick() call in the loop() function:

This was generating much less HIGH/LOW changes but they occur. So why ? At least this means that the tick() call in the loop function has effect.

My guess: I haven’t analyzed all signals in parallel but as I have done some prior work I know that the signal on the input pins may change VERY fast as the contacts often do create some HIGH/LOW noise that is typically removed from input signals by debouncing algorithms. Here with the rotary library the “debouncing is built in” but when missing a signal because it is generated before the last one was handled will leave an input state not recognized. I expect that the tick in the loop() function will detect this even without interrupt.

My conclusion: as long as the additional tick() in the loop() function doesn’t hurt, leave it in.