Go Down

Topic: Delay vs Without (Read 1 time) previous topic - next topic

GoForSmoke

This is about how using delay affects how you look at coding.

I liken code with delay() to a light wired to a button and power.
The light is only on as long as you hold the button. Much code may be spent on ways around that.

Without delay() the code is like a light wired to a switch and power.
The light changes when you flip the switch. How to tell when to flip a switch, that's what to code.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

aarg

This is about how using delay affects how you look at coding.

I liken code with delay() to a light wired to a button and power.
The light is only on as long as you hold the button. Much code may be spent on ways around that.

Without delay() the code is like a light wired to a switch and power.
The light changes when you flip the switch. How to tell when to flip a switch, that's what to code.


Well, I'm not sure... if I have a button connected to a light and power, the light will respond instantly to any change in the button status. That doesn't sound like delay(). :)
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

RED_

I am not sure... is this post a question or a statement?

Rupersero

Well I'm having trouble what the original post is meaning... The first case sounds like straight from input to output, the second sounds like changing output state with rising edge... Not sure what to do with delay.

aarg

I prefer the cooking analogy. When you bake a cake, do you stand at the oven for an hour while it cooks, or do you go off and do other things and come back to see if its done? That's delay() vs. millis().
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

Rupersero

I prefer the cooking analogy. When you bake a cake, do you stand at the oven for an hour while it cooks, or do you go off and do other things and come back to see if its done? That's delay() vs. millis().
I mostly use the millis() way to do things, but I still don't see what the cases in the opening have to do with delay().

GoForSmoke

The action of delay(), I *liken* to having to hold a button down to make a light shine.

delay() is your finger (execution) on the button (code) doing nothing else (blocked).

Yes, you can turn the led on then delay() then turn it off but delay() always blocks execution.
You can think up 1000 things just like thinking up ways to code around the limits of delay().
This isn't about what you can do with delay(), it' about what delay() does to your code.


The thread is to give people who use delay() another way to think about code, a finger that can stay on one thing or move between many in the same period.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

GoForSmoke

I mostly use the millis() way to do things, but I still don't see what the cases in the opening have to do with delay().
Millis for timing, pin states and flags for events and variable values for break-it-down-to-steps state machines, none of it is worth much when just one routine or library call blocks execution enough to notice and all of it's worth gold when it runs right.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

aarg

#8
Sep 04, 2015, 09:38 pm Last Edit: Sep 04, 2015, 09:39 pm by aarg
I think anyone who doesn't understand something descriptive like, "the program can't do anything while delay() is running", or the like, is beyond the help of analogies.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

Rupersero

I think button and switch are bad analogy for this, since they don't really descibe what's going on (at least with the explanation in the opening). The cooking analogy is much clearer. Also there are some grammar issues here, which make it much harder to understand.

jboyton

The cooking analogy:

1. delay - stare at the clock for the 45 minutes it takes to bake the cake.
2. millis - check the clock every 10 seconds until 45 minutes has elapsed.
3. interrupt - set an audible timer to go off after 45 minutes.

GoForSmoke

Interrupts are great but I save them for special needs. They're a limited resource that may become a point of conflict down the road.

And besides, that interrupt could let you know when the cake -is- done, not just when it should be!
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

GoForSmoke

I think button and switch are bad analogy for this, since they don't really descibe what's going on (at least with the explanation in the opening). The cooking analogy is much clearer. Also there are some grammar issues here, which make it much harder to understand.
You could try being less literal minded about physical wiring and see that the analogy is not a description to play with but a simple generality about use.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Rupersero

This is about how using delay affects your coding.

The code with delay() is like a light wired to a button and power.
The light is only on as long as you hold the button, blocking you from doing other than holding the button. You can use many different ways to work around that.

Without delay() the code is like a light wired to a switch and power.
The light changes on when you flip the switch on. When to flip the switch off is up to your code, but you can do other stuff when waiting for the time to flip the switch.

I think this says it clearer, even though it doesn't really explain what the second case has to do with timing.

GoForSmoke

Well fine I guess but when I write "liken to" it has a meaning, I'm trying to illustrate one thing in terms of something else rather than make a working explanation of the first. I'm trying a step back, not a step into.

When I wrote "Much code may be spent on ways around that. ", it's not a recommendation to do that. It's more like a recipe for spaghetti.

But any of this that can get any beginner able to see what blocking is and learn to avoid it.

Blocking is
> finger(code execution)
> stuck(blocked)
> on the button(delay(),readUntil(),etc).

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Go Up