Accuracy of setInterval

Gordon

Thanks. I'll certainly be using the crystal, but drift in the clock bothers me less than scheduling inaccuracies.

I'd note that my testing so far really shows quite surprising accuracy - even if I change wastetime() to loop for 20k times, it's still accurate. So much so that I
think something must be wrong....

OK, some questions

1. You say it's not pre-emptive - does that mean if I have a time-consuming function which lasts 10 seconds, setIntervals won't get called at all? (I know I shouldn't do this, but ...)

2. Is there anything in the system which might cause it to block setIntervals for some largeish time period - I'm thinking bit-bang serial, I2C, CC3000..

3. I presume getTime() returns a value that is read directly from hardware when you call it?

I see two solutions to deliver an accurate GetDateTime function which includes both calendar date and milliseconds:

1. Your suggestion - a global date-time variable updated every second

2. A getDT function which, when called, reads GetTime and updates a global clock variable according to time elapsed since the last time it was called.

If setInteval can get delayed, and I have long-ish functions, then I suspect I need to use #2. The problem is that so far I can't duplicate a problem case :)

Martin