Go Down

Topic: millis not accurate? (Read 2 times) previous topic - next topic

Nick Gammon

I think what he is saying is that, if you take 40 seconds to press the "start" button the clock starts at zero but the trigger is already 40 seconds in.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

dethredic


I think what he is saying is that, if you take 40 seconds to press the "start" button the clock starts at zero but the trigger is already 40 seconds in.


I don't think that would be correct as trigger() is called just once in setup(), so it would be near zero, if not zero.
www.gunnewiek.com

Coding Badly

Quote
I think what he is saying is that...


You have the right idea. 

I believe I was wrong in my assessment.  I think the code is actually unstable.  If "trigger = millis();" results in a non-zero value assigned to trigger, I believe the application gets stuck in the while loop until trigger wraps around.  I think the end result is that second is set to zero, minute jumps ahead by one, and trigger is left at "random" value lower than "millis() - adjustment".

But the details are irrelevant given the fact that aTime / adjustment serve no useful purpose and can be easily eliminated thus eliminating any possibility of a problem.

Nick Gammon

Well stare at it as I might, I can't quite get my head around it. But this isn't right:

Code: [Select]
if(buttonPressed(goPin) && !goPinIsPressed)
  {
    goPinIsPressed = true;
    startClock = true;
    aTime = millis();
  }



Whenever you press "goPin" it resets aTime, but it doesn't reset the hour/minute/second variables. So I think that pressing the button during the day (if you indeed do that) will have an undesirable effect.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Go Up