Pausing a Arduino shetch, and wait for a button press - Page 1
Forum section: electronics / general

author: Cj1corbystarlet
author_rank: Contributor
timestamp: November 04, 2011, 11:13:48 am
content: 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 coderBen

author: PeterG
author_rank: Frequent Contributor
timestamp: November 04, 2011, 11:17:33 am
content: The easy way would be to use an interrupt on the input pin.Regards

author: sub
author_rank: Regular Contributor
timestamp: November 04, 2011, 11:26:40 am
content: Try something to the effect of while(digitalRead(pin) == 0) {}, assuming you are pulling the pin high on a button press.

author: Cj1corbystarlet
author_rank: Contributor
timestamp: November 04, 2011, 12:40:53 pm
content: 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 screenWaits for a push of button 6 -- Yeahthen 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 optionAny ideas ? My Basic and Turbo Pascal, and C Programming days are long gone (16 Years ago)

author: sub
author_rank: Regular Contributor
timestamp: November 04, 2011, 12:57:32 pm
content: 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 04, 2011, 01:08:34 pm
content: Quote from: sub on November 04, 2011, 12:57:32 pmwhy?

author: sub
author_rank: Regular Contributor
timestamp: November 04, 2011, 11:08:00 pm
content: 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.

author: Tony R
author_rank: Regular Contributor
timestamp: November 15, 2011, 04:01:27 pm
content: Quote from: Mechatrommer on November 04, 2011, 01:08:34 pmgoto 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)

author: baljemmett
author_rank: Unknown
timestamp: November 15, 2011, 04:55:26 pm
content: Quote from: Tony R on November 15, 2011, 04:01:27 pmIt 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.QuoteThat, 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!)

author: Unknown
author_rank: Unknown
timestamp: November 15, 2011, 05:42:19 pm
content: 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.

author: Bored@Work
author_rank: Super Contributor
timestamp: November 15, 2011, 08:34:22 pm
content: Quote from: alm on November 15, 2011, 05:42:19 pmHowever, 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.QuoteIndeed. 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.

author: baljemmett
author_rank: Unknown
timestamp: November 16, 2011, 12:05:56 am
content: Quote from: alm on November 15, 2011, 05:42:19 pmYes, 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 16, 2011, 12:25:31 am
content: 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