Updated Constructors to do all the pin() and interval() setups. All the
setup can now be done in one step when instantiating the object. Added
held() and retrigger(). See examples. Updated other examples to use the
new constructor.
Updated Constructors to do all the pin() and interval() setups. All the
setup can now be done in one step when instantiating the object. Added
held() and retrigger(). See examples. Updated other examples to use the
new constructor.
All the setup can now be done in one step when instantiating the object.
The thing is you want to setup the pin before attaching it. That is why it was moved to the separate attach() function.
Added held() and retrigger().
retrigger() is a common request and held() is an interesting addition. Instead of having a separate variable, maybe the held time could be passed in the function? Like held(500) ?
> All the setup can now be done in one step when instantiating the object.
The thing is you want to setup the pin before attaching it. That is why it was moved to the separate _attach()_ function.
> Added held() and retrigger().
_retrigger()_ is a common request and _held()_ is an interesting addition. Instead of having a separate variable, maybe the _held_ time could be passed in the function? Like _held(500)_ ?
I can move the attach() function to run at the first time update() is called so we could still have it all in one constructor and after the pin is setup. I'm not sure I can add the held(500) easily since all the code for that function is in update() and requires a separate variable. I did have to add many more variables to the program to get the functionality of held and retrigger but I feel it was worth the extra bytes. I'll take a look again and see if I can reduce the extra variables in any way.
I can move the attach() function to run at the first time update() is called so we could still have it all in one constructor and after the pin is setup. I'm not sure I can add the held(500) easily since all the code for that function is in update() and requires a separate variable. I did have to add many more variables to the program to get the functionality of held and retrigger but I feel it was worth the extra bytes. I'll take a look again and see if I can reduce the extra variables in any way.
Should be on a different object, this would increase the size of the object, which is not good on a limited Arduino Uno with already too many objects going around. Might be implemented in a children class for example, that way if we don't need this extra functionality we can just instantiate the parent and keep a smaller object.
Should be on a different object, this would increase the size of the object, which is not good on a limited Arduino Uno with already too many objects going around. Might be implemented in a children class for example, that way if we don't need this extra functionality we can just instantiate the parent and keep a smaller object.
Sounds like a good idea. Currently I am not working on this as one can
imagine since I haven't updated it in a long time. When/if I come back to
this I'll try to implement a child class. Feel free to take this fork over
if you want.
Should be on a different object, this would increase the size of the
object, which is not good on a limited Arduino Uno with already too many
objects going around. Might be implemented in a children class for example,
that way if we don't need this extra functionality we can just instantiate
the parent and keep a smaller object.
Sounds like a good idea. Currently I am not working on this as one can
imagine since I haven't updated it in a long time. When/if I come back to
this I'll try to implement a child class. Feel free to take this fork over
if you want.
On Jan 3, 2018 2:11 PM, "Nelson Vides" <notifications@github.com> wrote:
Should be on a different object, this would increase the size of the
object, which is not good on a limited Arduino Uno with already too many
objects going around. Might be implemented in a children class for example,
that way if we don't need this extra functionality we can just instantiate
the parent and keep a smaller object.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/thomasfredericks/Bounce2/pull/15#issuecomment-355142294>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALHgSmT9APHyPe-wxMP7smw3vWEAzaENks5tG_sggaJpZM4D1l29>
.
This pull request has changes conflicting with the target branch.
.gitignore
Bounce2.cpp
Bounce2.h
examples/bounce/bounce.ino
examples/change/change.ino
examples/duration/duration.ino
examples/retrigger/retrigger.ino
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.
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.
Updated Constructors to do all the pin() and interval() setups. All the
setup can now be done in one step when instantiating the object. Added
held() and retrigger(). See examples. Updated other examples to use the
new constructor.
The thing is you want to setup the pin before attaching it. That is why it was moved to the separate attach() function.
retrigger() is a common request and held() is an interesting addition. Instead of having a separate variable, maybe the held time could be passed in the function? Like held(500) ?
Oh I see what you mean with the attach(). I'll move it out of the constructor and do some more updates.
I can move the attach() function to run at the first time update() is called so we could still have it all in one constructor and after the pin is setup. I'm not sure I can add the held(500) easily since all the code for that function is in update() and requires a separate variable. I did have to add many more variables to the program to get the functionality of held and retrigger but I feel it was worth the extra bytes. I'll take a look again and see if I can reduce the extra variables in any way.
Whats the status on this? Looks very handy!
Should be on a different object, this would increase the size of the object, which is not good on a limited Arduino Uno with already too many objects going around. Might be implemented in a children class for example, that way if we don't need this extra functionality we can just instantiate the parent and keep a smaller object.
Sounds like a good idea. Currently I am not working on this as one can
imagine since I haven't updated it in a long time. When/if I come back to
this I'll try to implement a child class. Feel free to take this fork over
if you want.
On Jan 3, 2018 2:11 PM, "Nelson Vides" notifications@github.com wrote:
Should be on a different object, this would increase the size of the
object, which is not good on a limited Arduino Uno with already too many
objects going around. Might be implemented in a children class for example,
that way if we don't need this extra functionality we can just instantiate
the parent and keep a smaller object.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/thomasfredericks/Bounce2/pull/15#issuecomment-355142294,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALHgSmT9APHyPe-wxMP7smw3vWEAzaENks5tG_sggaJpZM4D1l29
.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.