[TriEmbed] TimerOne correction: arguments > abt 8k microseconds are silently set to 8k microseconds as others said
Pete Soper
pete at soper.us
Tue Sep 9 22:07:05 CDT 2014
I confused the situation about the "TimerOne" library "initialize"
routine constraints last night.
There is no doc in the library code itself, but I confirmed empirically
what somebody asserted last night: about eight seconds is as much delay
as you will get, period. Arguments to TimerOne.initialize over about
8000000 give you about 8000000 usec delay, period.
Then I made the mistake of looking at the code. There is no
sophistication at all. Here's are the money lines:
... (other, shorter delay setups)
if (cycles < TIMER1_RESOLUTION * 1024) {
clockSelectBits = _BV(CS12) | _BV(CS10);
pwmPeriod = cycles / 1024;
} else {
clockSelectBits = _BV(CS12) | _BV(CS10);
pwmPeriod = TIMER1_RESOLUTION - 1; // Set the delay as
long as possible with *one hardware interrupt*
}
There is no interposing of interrupt service with the Arduino libraries.
So the TimerOne library code doesn't get control and then do the user
code callbacks when the delay is completed if it's longer than
TIMER1_RESOLUTINON*1024 microseconds. And its detachInterrupt code
doesn't do any detaching at all, it just disables the hardware interrupt!
I'm sorry I opened my mouth about this. The Arduino code is profoundly
simpler than I thought and the TimerOne library is consistent with that
environment.
-Pete
More information about the TriEmbed
mailing list