[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