If you are doing a continuous use project, don't use millis() or micros(), or delay() or even delayMicroseconds() in your project, because the variable will experience a count reset (overflow), instead, use some timer or operating system.
Automatically handles
micros()andmillis()overflows / wrap around special cases.
millis() overflow ... a bad thing?
if handled properly
if it difficult to you - then do not use millis()...
But it will better to learn it.
Yep... Many tutorials are made just as examples, but don't consider long usage time. It's good to warn users, this way it prevents them from thinking that the Arduino platform is bad, or that it's just a platform for amateurs.
No.
Most of tutorials are written with millis overflow in mind, especially since it doesn't require any effort. Do you read the link, what provided by @LarryD ?
The only thing that you should to do for prevent millis() overflow problems - use subtracting and do not use adding with millis() values.
and it's all!
Oh sure I hope so!
And for tutorials, which are written without overflow in mind - it's not worth wasting time, this means that the author does not understand the basics of arduino and therefore he may have many more errors in the code.
Your first message sounds like "Don't drive the car, you can go into the oncoming lane and get into an accident"
And yes, if you don't know which side of the road is right, don't drive. But you can learn...
Comparing apples to oranges is not cool, unless your explanation isn't enough, then you want to manipulate your listener's mind, take that into account, just use example code, that should be enough.
I was under the impression micros() were created using NOP's. So they don't overflow.
I've seen some delayMicroseconds source code that is done using machine cycle, these should have no problem with overflow, but it's interesting to check the source code to be sure.
Do you read the link in post #2?
Is that code not enough for you?
I have seen and tested the code. But it seems to me that it only avoids the non-compliance with the comparison, which must occur in the case of using the sum.
When the rolling variable goes from maximum to minimum at the moment of overflow, can the time be shortened?
For example, if we have:
u32 u32_prev = 0; // Global
...
u32 u32_now = millis(); // Local
#define ref_time_100 100
if ((u32_now - u32_prev) >= ref_time_100) {
u32_prev = u32_now;
}
When the u32_now variable goes from 0xFFFFFFFF to 0x00, then the u32_prev variable must have some high value. And when subtraction occurs, the resulting value should be negative, but since it is an unsigned variable, then the value resulting from the subtraction is a high value. Thus, the comparison with the expected time base reference value can be validated before the moment it should occur.
I don't know if I managed to explain my point correctly to you, but it might be possible to run some simulations to see if this occurs.
I found this calculator that lets you use unsigned values:
What a silly post.
So I should not be using millis() and micros() even when the code is writtent to deal with the overflow issues ?
You can use it, but it's interesting to know what's going on, many codes accept sporadic variations. But it can be a warning for anyone thinking of doing something very specific, such as medical equipment prototypes, perhaps.
Eh ?
You said Dont use it ?
no, it won't be a high value
Take the calculator and calculate yourself
(uint32_t) 1 - (uint32_t) 0xFFFFFFFF
The data sheet for the processors used in the Arduinos specifically states that the processor should not be used for medical applications.
@rtek1000 do you have much experience in using an Arduino? These dire warnings do suggest that you don't. Or at best you have grossly misunderstood what code is all about. How do you think an an operating system is going to handle things any different to what can be achieved by writing code on the processor?
Basically it can't.
Everyone discovers something new and gets excited from time to time. As is clear from this thread millis is just fine to use, as is delay in the right circumstances. Like all things you should simply understand the specs and see if it meets your requirements
What a nonsense post.