Delay vs Without

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.

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.

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(). :slight_smile:

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

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.

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().

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().

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().

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.

Rupersero:
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.

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.

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.

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.

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!

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.

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.

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.

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).