That may be true, but the compromise can become "buried" and break additional code that might be added to loop(). To future proof your sketches, it's best not to use any delay(), even a short one.
1 Like
And some ppl will never call a 10 ms delay “short”.
a7
1 Like
it's best to understand your requirements and meet them
If you are writing a series of sketches over time, your requirements should span that time. It is wise to consider the future, in cases where exceeding the immediate requirements in order to support likely future requirements is not difficult.
If you are developing "piecemeal", where sketches are essentially stand alone and you are reviewing and writing each one independently, then I agree. It wouldn't matter.
I'm not sure of the OP development pattern, but I have a lot of code re-use and I try to avoid setting future traps for myself.
So, a long time ago, I developed my own switch debounce reference sketch, which I'm confident I can adapt to any sketch that it could reasonably work in.
If a loop time of 10 - 20ms is no problem in an application, you can simply add this delay() at the beginning or end of loop and read your buttons with digitalRead(). No further debouncing is needed in this case.
But the approach in #19 isn't really much more complicated.
As I implied, no-wait debounce is not really complicated. If you find it to be so, there are libraries that will do it for you.
not complicated? this thread is already up to 26 responses
KISS
Don't know what you want to tell with this answer 
considering delay, is out the question, my little knowledge, said that is pausing the code.
if you have 3 sensor that you need to read it every 1 min, one by one, then is fine..
but if you have 3 sensors and you need the one to give instant value then delay command is not good.
Yes, 99.9% of the time this subject comes up. 
Yes, and mostly with unnecessary complicated solutions 
.
1 min is 60,000 msec.
why should a 10 msec delay when a button is pressed be an issue?
what is acceptable: < 1 sec, < 1msec < 1usec < 1nsec ??
Just one example - if you are running the 7 segment library on a display, it will blink when you press the button.
Loop time is a shared resource, which is limited. You can't eliminate it but it's not a good idea to waste it.
That is not a bug - that is a feature 
then that may be a requirement that affects the design.
Yeah, requirements are great. But when you expect to combine your own or other peoples code in a single sketch, there are requirements that go beyond the bare application requirement. The requirement to "play nice" with other software is normally provided mainly by the OS, but in the case of Arduino programming, it's more of a programmers responsibility. So it's a good idea to support "global" requirements like non-blocking for example, wherever possible.
Think about how often sluggish loop timing presents a mystery to a new programmer. Such that we often see problems related to that here.
Also in an experimental environment or frame of mind, modularity and re-use are extremely beneficial - todays project may have only limited requirements but the chances are good that it may become the basis for another project with different requirements. Thus maintaining a global baseline standard for your own (and borrowed) code is a good policy.
For me, this is not hypothetical, but a long standing approach. I have dozens of custom solutions as simple test templates, that make their way into the applications I write. That includes switch debounce so I have one of those. I only had to code and test it once. Now I can use it safely anywhere I need it because it meets and exceeds the base functional requirements by obeying the global requirements, with little effort really.
i.e. it might begin with no 7 seg display, but end up with one later. In which case, designing for the bare minimum requirements may be more painful than implementing the global (in this case non-blocking) standard in the first place.
i think you have the impression that i don't support using millis(), i Do, when needed.
and i think good developers know and understand how to do it many ways
i don't believe there is one "good" way
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.