westfw:
I didn't see that in the post. I looked again and I still don't see it...
You should disable interrupts around the actual delay; an unlucky interrupt might take a couple of us, and cause timer overflow when you weren't expecting it.Wait; are your results all from your test program, or from other attempts as well. AFAIK, the problem I noticed should only happen when calling delayMicroseconds() with a constant argument; your example where you constantly vary the time in a loop should behave differently (and less "wrong.") Hmm. I guess I should look at things more closely!
- Sorry if you couldn't see that. It was in almost at the end of the Blog Post.
I captured the part where I explained it.
You can see the screenshot from Here : SCREENSHOT_BLOG
And after reading what you suggested about 'unlucky interrupt', I think that is Highly possible.
Because this program always gave the same, Buggy (delaying too less) result in Exactly same Numbers. So this meant that Program has some internal situation going on, precisely timed since Startup. And most likely that would be an Interrupt. Otherwise, how can Exactly Same Buggy Numbers Appear always??(It is not a luck)
- Yes, all the result was from one single experiment.
And that result is very consistent if I set "TEST_COUNT" to 5. Otherwise, mostly when it Increased, it spitted out Buggy results. Which I suspect, is because the Test was long enough to meet an 'unlucky' interrupt During delayMicroseconds(x) Execution.
Have a Nice Day 