I will have to think about this. A more abstract class has often been requested allowing debouncing of more than just a single hardware pin. So I will not implement this right now, but later. I need to make a base class that is extended to hardware pins.
I will have to think about this. A more abstract class has often been requested allowing debouncing of more than just a single hardware pin. So I will not implement this right now, but later. I need to make a base class that is extended to hardware pins.
It allows save byte of RAM each time Bounce is member of class, when pin must be later used in class.
Cool.
For now I can live with:
``` c++
class BounceExt: public Bounce
{
public:
BounceExt(uint8_t pin, uint16_t interval_millis ) :
Bounce(pin, interval_millis) {};
uint8_t get_pin() {
return pin;
}
};
```
It allows save byte of RAM each time Bounce is member of class, when pin must be later used in class.
(...) in most situations you can have a const in your code which you pass to Bounce2 aka it takes no space in RAM.
Bounce objects store pin number as their attribute, so most likely byte of RAM is used regardless how init value was passed.
Why does that save RAM?
I do not have to duplicate pin number data like:
classPushButton{Bouncedebouncer;uint8_tpin;// duplicate value as in debouncer.pin
> (...) in most situations you can have a const in your code which you pass to Bounce2 aka it takes no space in RAM.
Bounce objects store pin number as their attribute, so most likely byte of RAM is used regardless how init value was passed.
> Why does that save RAM?
I do not have to duplicate pin number data like:
``` c++
class PushButton{
Bounce debouncer;
uint8_t pin; // duplicate value as in debouncer.pin
```
I merged a new version of the library where I split the hardware layer from the debouncing algorithm. It should now be easier to make custom classes.
@matkor We could now add a getPin function to the Bounce class.
I merged a new version of the library where I split the hardware layer from the debouncing algorithm. It should now be easier to make custom classes.
@matkor We could now add a getPin function to the Bounce class.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Please add public accessor to this->pin like:
TIA
I will have to think about this. A more abstract class has often been requested allowing debouncing of more than just a single hardware pin. So I will not implement this right now, but later. I need to make a base class that is extended to hardware pins.
Cool.
For now I can live with:
It allows save byte of RAM each time Bounce is member of class, when pin must be later used in class.
Why does that save RAM? Because in most situations you can have a const in your code which you pass to Bounce2 aka it takes no space in RAM.
Bounce objects store pin number as their attribute, so most likely byte of RAM is used regardless how init value was passed.
I do not have to duplicate pin number data like:
@matkor, why do you store the debouncer and pin separately?
I do not.
I just need access pin having only Bounce instance.
I merged a new version of the library where I split the hardware layer from the debouncing algorithm. It should now be easier to make custom classes.
@matkor We could now add a getPin function to the Bounce class.
Was added to v2.58