Timer2 above 60khz

[tmeyer]

Hello all

I have been playing with pics for years just as a hobby making simple devices. But I have recently been trying to understand the math behind the timers. When I use the below code and the program (with a period of 78 or above in setup_timer2(T2_DIV_BY_1,78,1)) everything works fine. The frequency of the interrupt matches the math.

However, when I put in 77 it should generate an interrupt frequency of 64,102hz. Note that I am actually measuring for 1/2 that (32,051hz) since I am using two interrupts to toggle the pin I am measuring PIN_C4.

After being "spot on math vs actual" from period values of 78 and above, the scope and counter diverge from math at 77 showing 29,450hz instead of expected 32,051hz. And the faster I make frequency of interrupts by lowering period value the worse the spread between measured and actual gets. I also moved the prescaler and periods around but still broke away from the math at around the same 30Khz point measured, 60khz actual interrupt frequency.

Anyone know why? This example is on a 18F258 with 20mhz clock. Same issue on a 16f684 with 20mhz clock but things break down 10khz later at around 40khz on scope, 80khz actual interrupt frequency. Multiple clock crystals, multiple different chips. Same results.

I've got to be missing something pretty basic. I even used the code generating wizard to make sure I wasn't doing something stupid. I am using a regulated power source so no issues there.

Thanks if anyone can tell me why. I searched everywhere for explanation but maybe don't know how to phrase the question.

[Ttelmah]

Problem is entering and exiting an interrupt takes time....

At 20MHz, the chip does 5MIPS. It typically takes about 35 instructions to
detect an interrupt has happened, save the registers, then enter the
interrupt.
Your output toggle, takes another two instructions. Then clearing the
interrupt and restoring the registers another thirty instructions. By the time
the code arrives back in the 'main' about 70 instructions have passed. Remember a call, return etc., all take two instruction times, so more
than this in actual instruction times.

So at 20MHz, the maximum rate would be around perhaps 65KHz.
At this point, the code would be 100% occupied handing this interrupt.
No time to do anything else.

You are finding it runs out of time (remember it needs one instruction
time back in the 'main', to then respond to the interrupt), at 79 instruction
times between the triggers.

This is why chips have hardware to do useful things for you. So the PWM,
allows you to generate output pulse trains using no processor time. More
flexibly, the CCP can support having the hardware set a pin or clear a
pin after an interval. This is why to do anything actually useful, you need
to use the hardware.

There is a trick that can be used, which is to not physically call an interrupt:

[tmeyer]

Thanks for taking the time to answer me! Your explanation makes perfect sense - I guess I would have though there would be some disclaimer somewhere about the maximum frequency that could be generated by processing the interrupt. There is a note in the datasheet (at least on the 16f684) about max PWM frequency. They are giving hobbyists like me way too much credit (I run a Ford Truck Dealership as my day job).

For the sample code below (which I haven't had time to try), I don't need to enable interrupts to test for their presence?

Thanks again - much appreciated.

Trey

[newguy]

No you don't need to enable interrupts to test to see if one has "fired". Interrupts are simply hardware-induced function calls if they're enabled. If they're not enabled, they still "fire" but the function isn't called. All you're doing by testing for the interrupt flag in a loop is essentially bypassing the (slow) formal interrupt call mechanism.