Hi all, I just can't understand why so many people pollute forums with totally useless posts. Forums exist to aid people who are having a difficulty and are asking for some advise. If one has no useful, objective and practical advise to give, he should simply not introduce noise in the forum. I'm sorry guys but your comments are totally rubbish! Don't pollute forums, please!
1 Like
@jarriaga please don't pollute the forum with pointless "solutions"
"advise" is a verb.
I think you mean "advice" (a noun).
You're welcome.
1 Like
@hk_jh, if you like I can explain why this function works. And, just forget all the other rubbish posted!!!!
@jarriaga, can you explain to me why the other solutions wouldn't work?
1 Like
I didn't see any other solution! Just noise!
Welcome to my ignore list.
1 Like
I think everyone is misreading your question. Millis() is great for intervals up to one rollover event (49.7 days). You can't test a period over one rollover because the millis() counter is an unsigned long (32-bits).
For long periods you should really be using an RTC. If you want to do it entirely in software then you could count the hours using an interval of 3,600,000 milliseconds per hour.
2 Likes
No problem. You will have to forgive anyone who points out posts with mistakes or bad information or misapprehensions though, don't you think?
a7
It's been a while since we've heard from @hk_jh. I'm going with, the next post has to directly answer a question from @hk_jh or be from @hk_jh. Anything else is going to draw ire.
@hk_jh, are you able to wade through the mess above?
@OP cut through the mess - read this
2 Likes
Hi @SteveMann, with all respect, yes you can test a period over any number of rollovers. the function I showed provides for that.
Regards.
@jarriaga, here I'm risking drawing ire and possible smiting, so I'm going to be brief.
The OP's code has a period of 20 milliseconds and another of 500 milliseconds.
Think about it.
Bring on the lightning bolts.
1 Like
I see I'm going to have to dispense some timeouts.
If you've posted something off-topic this would be grand opportunity to self report. Use the flag at the bottom of your post.
so because my interval is only 20ms I can leave my code as it is and it will continue without issues also after 47~ days?
1 Like
please do if you don't mind!
what do you mean by do it right? the way my code is now isn't right?
1 Like
I'm not sure anymore.. It seems people point I should have no problem because my interval is less then 49~ days (when millis rolls over). Is that true?
1 Like
If this, what I cut form @SteveMann's post and think is your original code, you are fine. The code is correct.
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
readSensors();
checkHeartbeatTIMER();
}
}
is the paradigmatic pattern and will work perfectly for all time provided only than the interval being timed is less than 49.7 days long.
TBC timing 20 ms intervals and using the same mechanism to time, say, a 500 ms interval will work forever.
a7
3 Likes
Your code is fine. It will work as you want even at the point that millis() rolls over (starts again at zero).
The reason is the way the unsigned arithmetic works. The statement below...
will still work even when currentMillis has rolled over.
4 Likes
has its own timing mechanism and does not need to be within the statements being performed every interval.
Since interval is ony 20, it works fine, on,y at the slight cost of not being strictly on for 500 and off for 500.
You can move the checkHeartbeatTIMER() to just before the if statement, where you may have seen it before. It takes its own care, look at the function and you'll see the same pattern at work within it.
This is the basis for writing code that never blocks. If everyone doesn't block, where woukd blockages come from?
a7
1 Like