I get 16.38 kHz on my DMM. Assuming that it's not trying to say 16.384, that's ~120ppm (thanks Wolfram|Alpha!). So I don't see why my clock should have been so far off. Perhaps any inaccuracies in the chip get amplified with the prescaler? For the clock, I was prescaling by 1024 to get a 1Hz interrupt...

EDIT: Hmmmmmm. Setting OCR2A to 33 instead of 0 (this is really useful), I get 952.5 Hz instead of 1000 Hz. Or I was, until the DMM decided to quit on me. Aaaaaarg.

You can't usefully do that with no prescaler. Servicing an interrupt takes at least 19 clock cycles (see: http://www.gammon.com.au/interrupts), then your digital writes will take time, plus the time to leave the ISR.

Please post technical questions on the forum, not by personal message. Thanks!

You can't usefully do that with no prescaler. Servicing an interrupt takes at least 19 clock cycles (see: http://www.gammon.com.au/interrupts), then your digital writes will take time, plus the time to leave the ISR.

Not using timer interrupts, just using output compare to make its frequency measurable on a pin. Well, half it's frequency is the best that can be done.

OK, I'm calling you on this one, dhenry. From the datasheet, which you keep recommending people read:

Since we do indeed use an interrupt vector, that is 7 cycles minimum. Add onto that the code in the ISR to, at the very least, save the status register (SREG) and that is another 3 cycles. On top of that you have to push any registers you are planning to use, unless your ISR doesn't do anything.

So, no, it is not "as low as 2".

I was wrong about the 19 cycles. That is the time take, from looking at actual code generated, to leave the ISR. It is 23 cycles to enter it. That would probably vary depending on what the ISR does. The more things it does, the more registers the compiler has to save (and restore later).

Figures, disassembly, etc. on this page:

http://www.gammon.com.au/interrupts

Please post technical questions on the forum, not by personal message. Thanks!

It's interesting--with OCR2A set to 0 or 1, I get, as expected, half of 32768--1638(4). But when I up OCR2A to ~31,32,33 to get a 1kHz frequency, I get a 1kHz frequency (or close to it)--not 500Hz. I think that's because in the interrupt, I have

if (toggle2){ digitalWrite(9,HIGH); toggle2 = 0; } else{ digitalWrite(9,LOW); toggle2 = 1; }which is what it was originally. At the relatively high frequencies, the minuscule gap between HIGH and LOW is... something, and at lower frequencies it... isn't. Not really sure what I'm saying exactly, but I know what I mean.

Well, with the original code (using the toggle) I find that OCR=1 generates 1/2 of 16384Hz (interestingly, so does OCR=0). At least, it should. I'm reading 8190, which is ~250ppm off--way more than the ~40 expected from the temperature. That could well be errors in the DMM--I don't really see what else, unless the crystal is picking up parasitic capacitance through the air from the breadboard rails underneath it.

That translates to 21 seconds per day slow, if I define a second as 8292 interrupts. (Or I could just code it as 8190, and assume that my meter isn't off.) That's not ideal, but it's not the second-every-five-minutes loss I was having before.

One thing I've determined: The calculator I linked to earlier rounds the answer it spits out--when I say I want 4 kHz, for example, it tells me I can use no prescaler and OCR=8 and have 0% error, but the fact is I will have error because everything's in factors of two. Nominal 8 kHz is actually 8192 Hz. This is possibly why the clock was so slow earlier.

Because the reason I wanted an interrupt in the first place is so I can sleep the chip in the meantime. I don't know if it's really worth the 17 mA, especially when there'll be lots of LEDs on anyway. But that was my idea.