Bounce2 library vs self-made bounce timer?

Hi, I have read what I can on the bounce2 library, what I am struggling to understand is does this do something fundamentally different to me just having my own debounce with a millis timer?

So if I set a timer when a button press is detected, and then check that any subsequent button press is say, at least 250ms later, is bounce2 doing just this or is it doing something fundamentally more and more impressive?

unsigned long timeofPagePress = 0;

void pageFunction() {
if(digitalRead(pagerButtonPin) == LOW) {
if ((millis() - timeofPagePress) > 250) { //only allow changover every 250 milliseconds
//do something
}

   timeofPagePress = millis();
   }

}

Why not look at the source code of the library ? It is on your PC if you have the library installed

thanks I have, can't say I really understand it though.

...and just to add to my question, I am assuming this library is way more powerful than my example, otherwise what does hundreds of lines of code accomplish? I am just trying to understand the power in this library as compared to a simple millis() comparison shown.

Take a look at the source code and you will see that the library uses millis() for timing and provides functions to detect when the input rose, fell or changed for example, which your simple code does not, as well as the ability to return the length of a button press

It is like a menu of functions that you may or may not want, but the compiler will only include the functions that you have used in the code it produces so although the library has a lot of functions and lines of code, many of which are comments, the final code is not burdened by unused functions

In addition, it is easy to create multiple instances of button decoding in your code, each with a meaningful name, without needing to write specific code for each of them

At the end of the day, it is your choice

As a contrast, do you worry about the amount of code used by digitalRead(), which is easy to use, or would you prefer to read the AVR registers yourself in your code to save calling the function ?

Ah, but there's a different and very important reason to use digitalRead() instead of accessing AVR registers.

With that bounce library, or without it (using millis() yourself for debouncing) the code you write is pretty certain to work on any Arduino compatible board. You can choose to use the library or not, and your code will run on any of those boards. You may never need to move to another board, but others might re-use your code on a different board.

But if you use code which accesses AVR registers instead of digitalRead(), your code will only work on other boards based on AVR chips, perhaps only the exact same model of chip. You, or others, can't move your project to a different board without re-writing it. But digitalRead() will work on any Arduino compatible board without alteration.

So, that debounce library could be described as a "convenience" library, performing functions you could do yourself using other standard Arduino functions. It provides a convenient, hopefully bug-free way to do the same thing. It allows code re-use, which is generally a good thing.

Functions like digitalRead() are part of a library called the Arduino Core. The Core library is different for each type of chip, but it looks exactly the same to the user. For example, the code inside digitalRead() will be completely different for the esp8266 Core compared to the ATmega328 Core. But from the outside they look identical. So the Core, and libraries like it, are "hardware abstraction" libraries which enable the same sketch to run on different chips by completely hiding, or abstracting, the differences between those chips.