time sensitive, which would be better in this instance? delay or millis? when I turn my arduino on. I want the user to have (2) minutes to complete a task. (3) pins will be available when the arduino is powered up. (1) will power another PCB, the other connected to a push on push off switch. when the user pushes the switch it allows them to input information directly into the PCB. there will be a delay of 10 seconds and then a (1) second HIGH from the 3rd PIN will go back to the PCB. this will confirm the users input. if the user is not satisfied, they can simply turn off the project, turn it back on and try again.
"IF" the user has already completed this task and the arduino is turned ON again. "THEN" after the (2) minutes I want the sketch to continue on.
since nothing else is going on at this point I would assume that "delay" would work fine. what I am not sure about is whether delay is best for a 2 minute wait or if I should use millis. your view? I have read conflicting thoughts on how much time each parameter is good for, or, what their limits are.
I would just use millis() as it is better practice and works better if you ever want to check things in the future while you are waiting.
There are more limitations with delay. You won't be able to do anything while it is running, and depending on the type of variable you pass it, you might not get a full 2 minutes out of it.
You would need to make sure you pass it a correct variable type (long int) or use a counter.
when the arduino hits a delay the processor stops running the loop (it no longer reads digital inputs or does anything else in the code). Once the delay is over the processor runs the code after the loop.
delay on start up to do something that's not time sensitive like displaying on a lcd "welcome" is fine and normally put in the set-up so its only used once. Your code need to be able to read the buttons during this time so delay will not work.
I really don't like your idea about restarting the arduino but im not sure what you are doing. I will tell you that on start up millis=0 so only after start up you can use a "if" and compare millis to a number
if (millis()<3000){ //3 seconds from start up
//do this
}
any other time you need to record a time stamp and use that as a timer
"since nothing else is going on at this point I would assume that "delay" would work fine. what I am not sure about is whether delay is best for a 2 minute wait or if I should use millis. your view? I have read conflicting thoughts on how much time each parameter is good for, or, what their limits are. "
You assume correctly.
I have never heard of delay() being inaccurate. delay() uses milliseconds, so it can work for several days/weeks (if ever needed).
delay() is easier to code with.
millis() give you more ability to later add more simultaneous functions.
Each has its advantages, and we can't tell you that one is best for all coding.
Fredric58:
"IF" the user has already completed this task and the arduino is turned ON again. "THEN" after the (2) minutes I want the sketch to continue on.
This part is a problem. When the Arduino is turned off, it loses its memory. So there is no way for it to know that it was previously on within the last 2 minutes, or whether certain tasks were completed at all (unless that information is stored in EEPROM). That, and it has no idea of absolute time unless it has an RTC attached.
Aside from your current problem of continuing timing through a reset, besides the obvious advantage that by using millis() your program can do other things in the meantime, the millis() method uses a lot less program space. I just did a test in my sketch:-
unsigned long mS; // Declared elsewhere as global, to re-use again.
mS = millis(); // 1840 bytes
while (millis() < mS + 150) {} // " "
delay(150); // 1912 bytes 72 extra bytes
I've been doing a few of these tests - the results are surprising.
LarryD: @OldSteve
Then what happens at roll over time?
Also need type unsigned long.
Yep, mS is declared as unsigned long. (I'll edit my last post now, to show that.)
It behaves just like delay(), but more code could be added between the curly brackets if needed later.
Edit: I misunderstood what you meant by rollover. You mean when millis() rolls over. I guess the delay would be inaccurate if it happened to be running at rollover. In my sketch, it's only used for button debounce, so I don't care, and in the case of the OP it's in the first couple of minutes of runtime, so millis() won't roll over. (Most sketches won't run for 50 days, so it's only the ones that do that have to be rollover-safe.)
Won't that lead to a long delay?
Edit: Apparently not, according to this:-
Thanks for that. I started out just going by how the "BlinkWithoutDelay" example said to do it. (Perhaps a poor example to be included with the IDE.)
As I mentioned, most sketches will not run for 50 days anyway, but it's probably a good idea to just get used to doing it safely all of the time.)
So that's one piece of code I won't put to the test. Blowed if I'm gonna sit here for 50 days waiting to check on it.
I've added it to my "Snippets" file so I won't forget, as well as to my current sketch. I've learned a lot in my first two days of owning an Arduino.
odometer:
That's what micros() is for.
If it's going to roll over, I'd prefer it to roll over soon so I can see what happens when it does.
Ha. Good thinking. micros() will act the same in that regard. Either way, I trust you, and Nick's explanation on the page I linked to says it all. I was just having trouble picturing where the millis value would be at after the subtraction.
I can't do much more tonight, but I'll test it with micros() in the morning as proof-of-concept, for my own satisfaction.
Thanks again. The time is bound to come when I'll desperately need it.
I started out just going by how the "BlinkWithoutDelay" example said to do it.
The BWD example does not have a problem with rollover and uses the correct data types (except for the LED pin and LED state variables which could usefully be byte instead of int)
UKHeliBob:
The BWD example does not have a problem with rollover and uses the correct data types (except for the LED pin and LED state variables which could usefully be byte instead of int)
I used unsigned long for mS. (At least I learned that much.)
And my sketch won't have a problem with rollover either - it's only a controller for a pair of continuous-rotation servos on a small model car. It will never run for more than an hour at a time.
What I guess I meant was that no mention was made in BWD that rollover could potentially be a problem in long-running sketches. As an example of how to use millis() to replace delay(), it could have been mentioned in the comments. It only takes an extra line of typing.
You can imagine how many people are doing it the way I was without considering rollover. I guess if I was to search through all of the examples, there would be some that are taking rollover into account.
OldSteve:
I used unsigned long for mS. (At least I learned that much.)
And my sketch won't have a problem with rollover either - it's only a controller for a pair of continuous-rotation servos on a small model car. It will never run for more than an hour at a time.
What I guess I meant was that no mention was made in BWD that rollover could potentially be a problem in long-running sketches. As an example of how to use millis() to replace delay(), it could have been mentioned in the comments. It only takes an extra line of typing.
You can imagine how many people are doing it the way I was without considering rollover. I guess if I was to search through all of the examples, there would be some that are taking rollover into account.
bwd didn't mention roll over as its already coded in a way that deals with the problem. I have a sketch that's been running continuously for over 6 months using the example in bwd so I know it works.
gpop1:
bwd didn't mention roll over as its already coded in a way that deals with the problem. I have a sketch that's been running continuously for over 6 months using the example in bwd so I know it works.
OldSteve:
Thanks for that. I started out just going by how the "BlinkWithoutDelay" example said to do it. (Perhaps a poor example to be included with the IDE.)
Which version of the Arduino IDE do you have? In my version (1.0.5-r2) the BlinkWithoutDelay example looks like this:
unsigned long currentMillis = millis();
if(currentMillis - previousMillis > interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
which is what odometer recommended, except in that example previousMillis is declared to be a "long" while it should be "unsigned long" (I forget the exact promotion rules when subtracting a signed long from an unsigned long, but it's safest to make both unsigned long).
christop:
Which version of the Arduino IDE do you have? In my version (1.0.5-r2) the BlinkWithoutDelay example looks like this:
unsigned long currentMillis = millis();
if(currentMillis - previousMillis > interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
which is what odometer recommended, except in that example previousMillis is declared to be a "long" while it should be "unsigned long" (I forget the exact promotion rules when subtracting a signed long from an unsigned long, but it's safest to make both unsigned long).
I didn't look closely enough, did I? I'm already embarrassed. Didn't you see my last post?
Decided to rub my nose in it some more?
