Pausing a Arduino shetch, and wait for a button press

[Cj1corbystarlet]

Hi guy's,

I'm writing a sketch for a arduino to measure some time/input's per min, but i have to pause the sketch so the user can get things ready, then hit the button, complete the task then hit the button again to go onto the next task and so on ....

Can anyone give me some hints how this is done as i cant find any tutorials in the net for this.

Theoretically it should be easy as pie...... but i cant seem to do it.

I'm a wire monkey, not a coder

Ben
 

[PeterG]

The easy way would be to use an interrupt on the input pin.

Regards

[sub]

Try something to the effect of while(digitalRead(pin) == 0) {}, assuming you are pulling the pin high on a button press.

[Cj1corbystarlet]

Ok i tried this and it works .... Sort of.

"
void loop()
{
 
{
  while (digitalRead(6)==0)
  {
    delay(10);                        //  debounce
  }
}
and the rest of the loop code works..        "

So yes, on powerup it processes my void Setup ()
loads my splash screen
Waits for a push of button 6 -- Yeah
then processes one run of the code, obviously goes back to the start of Void Loop()
and then waits for "the button push again.

I obviously need the void Loop() to continue to loop.....

Can i have a loop in a loop ? is "Goto" an option

Any ideas ?  My Basic and Turbo Pascal, and C  Programming days  are long gone (16 Years ago)

[sub]

The "loop" there is just a function name.  You'll be wanting a while or for loop.  Avoid goto unless you really know what you are doing (e.g. for Linux-style cleanup).

It might be worth flicking through a C tutorial---once you have a grip on what constructs are available to you, you will be able to make things far more concise and manageable.

[Mechatrommer]

Avoid goto unless you really know what you are doing

why?

[sub]

Because once you start using it instead of loop and procedural constructs things get messy.  Before you know it, your dog has burnt down, your house has distemper, and you're trying to debug a piece of code whose program flow has been obscured by eight levels of goto that jump into the middle of block of code from 500 lines away.

Sure, perhaps a slight exaggeration, but being able to see how you got to your current state at a glance is pretty important.

[Tony R]

Avoid goto unless you really know what you are doing

why?

goto can be hard to debug as sub said. but it also is prone to stack overflows which can cause your program to be utterly useless. Not to mention the fact that you will be shunned by almost every professional programmer in the world.

you can configure interrupts, but for your application i cannot see why the while look is not working, however it seems that you have an extra {. and i think you want to move the delay to after the loop because it will run what is inside the loop while the IO pin is 0. but you wait to delay it after a 1 is detected (i assume when the it is pressed it is triggering a 1)

[baljemmett]

goto can be hard to debug as sub said. but it also is prone to stack overflows which can cause your program to be utterly useless.

It shouldn't be -- goto won't touch the stack (at least not pushing onto it -- although it should pop off and discard any automatics if you're jumping out of scope).  Stack overflows are more of an issue when you're doing calls or equivalent.

Not to mention the fact that you will be shunned by almost every professional programmer in the world.

That, however, is a lot harder to quibble with   (There are times when you might use one because it's less nasty than the alternatives, but those are few and far between and so best ignored until you've got to the point that you can work them out for yourself!)

[alm]

The debugging and maintenance argument is a valid one, however. This is why structured programming was invented in the first place. Read Dijkstra's paper if you want more details. Since you usually spend much more time debugging than coding, it makes sense to optimize for debugging. Goto statements also make it hard to guarantee proper cleanup, like free()ing memory. Because of this issues, anyone who has to ask should avoid its use.

[Bored@Work]

Goto statements also make it hard to guarantee proper cleanup, like free()ing memory.

However, ironically the only idiom where goto is acceptable in the view of most professionals is a certain cleanup idiom to avoid code duplication while providing a controlled cleanup.

Because of this issues, anyone who has to ask should avoid its use.

Indeed. Basic programming craftsmanship is to not use goto. Once you have mastered the craft you can start to occasionally break the rule if absolutely needed.

[baljemmett]

The debugging and maintenance argument is a valid one, however.

Yes, indeed; sorry, didn't mean to imply that it wasn't -- should have trimmed that quote a bit tighter.  Basically, using goto willy-nilly will make the poor sod who has to maintain your code later hate you, and that's not a good thing -- especially when the poor sod might be you once you've forgotten all about how the code you've just written works.

[Mechatrommer]

if you can maintain locality in your code with goto statement, i think debugging hazard is not so serious. the fact is.. "for", "while" and those fancy loop statement is nothing else but just a "goto" translation in asm, with controlled and "encapsulated" locality. the problem is, kids usually made a far jump from another side of the world (between subroutines or between two very different purpose of code chunks, hence destroying locality and making debug almost imcomprehensible, certainly not the way to go. so "the advisor" will always pick the "safe side", hence promoting "not to use goto".

well, about the improper memory freeing and proper cleanup? "return" can do the same nasty thing, experience will tell. people who has to ask is afraid if he missed something he never heard