Maybe just make it 2 separate libraries that both reference the common bits?
Regardless, nice work, this really helped me with my project. I was fighting with my own debounce code for a long time before I gave up and tried this lib.
Maybe just make it 2 separate libraries that both reference the common bits?
Regardless, nice work, this really helped me with [my project](http://blog.mrgibbs.io/ble-wind-vane-assembly/). I was fighting with my own debounce code for a long time before I gave up and tried this lib.
I have been using this library in its default mode with a WeMos D1 Mini Pro (using ESP8266 processor). It was trouble free, but as a matter of curiosity I have studied how it works. According to my analysis, this library supports 3 modes of de-bouncing (not 2) out of a possible 4 modes. You select mode by un-commenting (or not) one only of two different lines, that is
#define BOUNCE_LOCK_OUT or
#define BOUNCE_WITH_PROMPT_DETECTION.
If you don't un-comment out either of these lines, you get the default or NORMAL mode of debouncing. if you un-comment both of them you get BOUNCE_LOCK_OUT.
The 4 modes of debouncing that are possible are obtained by combining 2 choices, each with 2 possibilities.
The first choice is between Early or Late output. That is, the debounced output is made available either as soon as the input changes (Early output) or only after the debouncing timeout (Late output).
The second choice is between the debounce timer being started at the first input change only (one-shot timer) or being re-started at every bouncing input change (multiple restart timer).
The resultant 4 modes are:
Mode 1: Early output, single shot timer (your BOUNCE_LOCK_OUT)
Mode 2: Early output, multiple restart timer (your BOUNCE_WITH_PROMPT_DETECTION)
Mode 3: Late output, single shot timer (not supported)
Mode 4: Late output, multiple restart timer (your NORMAL or default mode)
Your question that started this thread has two main parts: 1. a better way of integrating the [2, or 3, or 4] debouncing algorithms; and 2. that does not take up more cpu or memory. My opinion (for what it may be worth) is that the #define method, providing conditional compilation, is hard to use for many users. However the level of skill required may be consistent with the understanding of the difference between the methods and the reasoning that may lead to one method being preferred over another.
The actual increase in cpu time and/or memory (program and/or data) of other methods may or may not be significant. It will be project dependent. It will also be dependent on the way the compiler optimises (or fails to optimise) the use of code that is not actually used. All beyond my pay grade.
The best I can suggest is to write an alternative version with parameter-driven selection of debouncing mode, and measure the resource changes.
I would be willing to have a go at this, subject to any comments.
I have been using this library in its default mode with a WeMos D1 Mini Pro (using ESP8266 processor). It was trouble free, but as a matter of curiosity I have studied how it works. According to my analysis, this library supports 3 modes of de-bouncing (not 2) out of a possible 4 modes. You select mode by un-commenting (or not) one only of two different lines, that is
#define BOUNCE_LOCK_OUT or
#define BOUNCE_WITH_PROMPT_DETECTION.
If you don't un-comment out either of these lines, you get the default or NORMAL mode of debouncing. if you un-comment both of them you get BOUNCE_LOCK_OUT.
The 4 modes of debouncing that are possible are obtained by combining 2 choices, each with 2 possibilities.
The first choice is between Early or Late output. That is, the debounced output is made available either as soon as the input changes (Early output) or only after the debouncing timeout (Late output).
The second choice is between the debounce timer being started at the first input change only (one-shot timer) or being re-started at every bouncing input change (multiple restart timer).
The resultant 4 modes are:
Mode 1: Early output, single shot timer (your BOUNCE_LOCK_OUT)
Mode 2: Early output, multiple restart timer (your BOUNCE_WITH_PROMPT_DETECTION)
Mode 3: Late output, single shot timer (not supported)
Mode 4: Late output, multiple restart timer (your NORMAL or default mode)
Your question that started this thread has two main parts: 1. a better way of integrating the [2, or 3, or 4] debouncing algorithms; and 2. that does not take up more cpu or memory. My opinion (for what it may be worth) is that the #define method, providing conditional compilation, is hard to use for many users. However the level of skill required may be consistent with the understanding of the difference between the methods and the reasoning that may lead to one method being preferred over another.
The actual increase in cpu time and/or memory (program and/or data) of other methods may or may not be significant. It will be project dependent. It will also be dependent on the way the compiler optimises (or fails to optimise) the use of code that is not actually used. All beyond my pay grade.
The best I can suggest is to write an alternative version with parameter-driven selection of debouncing mode, and measure the resource changes.
I would be willing to have a go at this, subject to any comments.
I will see how to change this. The library was created when hobby micro-controllers were much less capable. The only concern I have is that this version must remain compatible with all the previous code.
I will see how to change this. The library was created when hobby micro-controllers were much less capable. The only concern I have is that this version must remain compatible with all the previous code.
Thank you for your reply. I understand about compatibility with previous code. I too will have a further look at this and post further when I have something.
Thank you for your reply. I understand about compatibility with previous code. I too will have a further look at this and post further when I have something.
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.
Anyone have a better way of integrating the two debouncing algorithms that does not take up more cpu or memory than using a define?
Maybe just make it 2 separate libraries that both reference the common bits?
Regardless, nice work, this really helped me with my project. I was fighting with my own debounce code for a long time before I gave up and tried this lib.
I have been using this library in its default mode with a WeMos D1 Mini Pro (using ESP8266 processor). It was trouble free, but as a matter of curiosity I have studied how it works. According to my analysis, this library supports 3 modes of de-bouncing (not 2) out of a possible 4 modes. You select mode by un-commenting (or not) one only of two different lines, that is
#define BOUNCE_LOCK_OUT or
#define BOUNCE_WITH_PROMPT_DETECTION.
If you don't un-comment out either of these lines, you get the default or NORMAL mode of debouncing. if you un-comment both of them you get BOUNCE_LOCK_OUT.
The 4 modes of debouncing that are possible are obtained by combining 2 choices, each with 2 possibilities.
The first choice is between Early or Late output. That is, the debounced output is made available either as soon as the input changes (Early output) or only after the debouncing timeout (Late output).
The second choice is between the debounce timer being started at the first input change only (one-shot timer) or being re-started at every bouncing input change (multiple restart timer).
The resultant 4 modes are:
Mode 1: Early output, single shot timer (your BOUNCE_LOCK_OUT)
Mode 2: Early output, multiple restart timer (your BOUNCE_WITH_PROMPT_DETECTION)
Mode 3: Late output, single shot timer (not supported)
Mode 4: Late output, multiple restart timer (your NORMAL or default mode)
Your question that started this thread has two main parts: 1. a better way of integrating the [2, or 3, or 4] debouncing algorithms; and 2. that does not take up more cpu or memory. My opinion (for what it may be worth) is that the #define method, providing conditional compilation, is hard to use for many users. However the level of skill required may be consistent with the understanding of the difference between the methods and the reasoning that may lead to one method being preferred over another.
The actual increase in cpu time and/or memory (program and/or data) of other methods may or may not be significant. It will be project dependent. It will also be dependent on the way the compiler optimises (or fails to optimise) the use of code that is not actually used. All beyond my pay grade.
The best I can suggest is to write an alternative version with parameter-driven selection of debouncing mode, and measure the resource changes.
I would be willing to have a go at this, subject to any comments.
I will see how to change this. The library was created when hobby micro-controllers were much less capable. The only concern I have is that this version must remain compatible with all the previous code.
Thank you for your reply. I understand about compatibility with previous code. I too will have a further look at this and post further when I have something.