State not correctly initialized for INPUT_PULLUP button

[navdotnetreqs]

Hi,

I have a panic stop button that is set to INPUT_PULLUP. So the pressed state is LOW.

I noticed that when I boot the board (Teensy) I get a false trigger that the button is pressed for the first update cycle. The internal state-variable has weird values for three loops, after this the state stabilizes and it works as it should.

in setup()

  PanicBtn.attach(PANIC_BTN_PIN, INPUT_PULLUP);
  PanicBtn.interval(DEBOUCE_INTERVAL);
  PanicBtn.setPressedState(LOW);

  for (int i=0;i<10;i++){
        PanicBtn.update();
        Serial.printf("Loop %i: pressed: %i, ispressed: %i, state: %i \n", i, PanicBtn.pressed(), PanicBtn.isPressed(), PanicBtn.state);
        delay(100);
  }

• 09:11:00.593 -> Loop 0: pressed: 0, ispressed: 1, state: 0
• 09:11:00.609 -> Loop 1: pressed: 0, ispressed: 1, state: 2
• 09:11:00.703 -> Loop 2: pressed: 0, ispressed: 0, state: 7
• 09:11:00.799 -> Loop 3: pressed: 0, ispressed: 0, state: 3
• 09:11:00.895 -> Loop 4: pressed: 0, ispressed: 0, state: 3
• 09:11:00.993 -> Loop 5: pressed: 0, ispressed: 0, state: 3
• 09:11:01.088 -> Loop 6: pressed: 0, ispressed: 0, state: 3
• 09:11:01.218 -> Loop 7: pressed: 0, ispressed: 0, state: 3
• 09:11:01.314 -> Loop 8: pressed: 0, ispressed: 0, state: 3
• 09:11:01.409 -> Loop 9: pressed: 0, ispressed: 0, state: 3

With a limit switch pulled to ground the same loop goes

• 09:10:00.298 -> Loop 0: pressed: 0, ispressed: 0, state: 0
• 09:10:00.441 -> Loop 1: pressed: 0, ispressed: 0, state: 0
• 09:10:00.490 -> Loop 2: pressed: 0, ispressed: 0, state: 0
• 09:10:00.588 -> Loop 3: pressed: 0, ispressed: 0, state: 0

It seems to me the initial value of the protected Debouncer variable state should be initialized in setPressedState depending on if it's a LOW or HIGH actuated press.

As a workaround I changed the state to public, and set PanicBtn.state = 3 after setPressedState.

[thomasfredericks]

When attaching with a pull-up, the state should be 3. It almost seems like the state is being read before the pull-up is done...

In the following code run when attaching, readCurrentState should return HIGH and set the state to 3.

void Debouncer::begin() {
	 state = 0;
    if (readCurrentState()) {
        setStateFlag(DEBOUNCED_STATE | UNSTABLE_STATE);
    }

	#ifdef BOUNCE_LOCK_OUT
    previous_millis = 0;
#else
    previous_millis = millis();
#endif
}

[navdotnetreqs]

Hi @thomasfredericks , don't know what to say, that's the result though. Did you test the sample code and get a different result?

[thomasfredericks]

I tried to reproduce your error but I do not have a Teensy on hand. What version of Teensy are you using? I tried to reproduce the stated behavior with an ESP32 but I got the expected behavior. If I do not hold down the button at bootup :

Loop 0: pressed: 0, ispressed: 0
Loop 1: pressed: 0, ispressed: 0
Loop 2: pressed: 0, ispressed: 0
Loop 3: pressed: 0, ispressed: 0
Loop 4: pressed: 0, ispressed: 0
Loop 5: pressed: 0, ispressed: 0
Loop 6: pressed: 0, ispressed: 0
Loop 7: pressed: 0, ispressed: 0
Loop 8: pressed: 0, ispressed: 0
Loop 9: pressed: 0, ispressed: 0

If I hold down the button at bootup:

Loop 0: pressed: 0, ispressed: 1
Loop 1: pressed: 0, ispressed: 1
Loop 2: pressed: 0, ispressed: 1
Loop 3: pressed: 0, ispressed: 1
Loop 4: pressed: 0, ispressed: 1
Loop 5: pressed: 0, ispressed: 1
Loop 6: pressed: 0, ispressed: 1
Loop 7: pressed: 0, ispressed: 1
Loop 8: pressed: 0, ispressed: 1
Loop 9: pressed: 0, ispressed: 1

I also tried with an Arduino Nano and got the same results...

[techydude]

@navdotnetreqs This sounds like some capacitance on the Teensy's input slowly coming up (after you configure INPUT_PULLUP). I don't know how the MCU on the Teensy (which version are you using?) implements internal pull-ups, some are actual on-silicon resistors, other are little constant-current circuits which achieve the same result, but either way, it sounds like the input is taking some ~200ms to come up to a Hi input level.

At first I thought it might've been because the Teensy (4.0/4.1) is so absurdly fast compared to the average Arduino, but you're doing delay(100), so that's 200+ ms for it to come up, which is rather long!