How fast is the timer2 interrupt?

[Rid]

Hallo everybody!

I have a little Problem with the timer2 in the PIC18F282. In my Projekt I whant to make an frequency generator. You can generate a frequency with an outputpin. The range is 100Hz to 1kHz. You have a digital 8bit Port for the Input. Now I what to divise the 900Hz into 255 steps. One step is 3.5Hz/bit. Now I have a conter in the interrup routine. I compeare the counter with an array. In the array is the value to compare with the counter. Is the conter >= the array value, the Outputpin is changing the stat.

Now, the Problem:
input f
255 1000 Hz
254 996.5 Hz
The diffrent time (3.5us/2) is between the 2 steps very small. Now i must have for this problem a fast interrup routine. I test it with the diffrent setup_timer2() settings. But with the 8MHz Quarz i have minimum 15us and with a 12 MHz 10us/interrupt. When i set the setup_timer2 settings to the fastest value, the PIC is not running. I think it make so many the interrup routine, that he can nothing to do beseide.

1. Can every body say me, how fast can i call the timer2 interruptfunction?
(The Quarz is normaly 8MHz but it is not a reasen for this)
2. And can you say me, how much can I do in the interruptfunction?
(I had a Problem with the interrupttime. It is changing when i make to much. What can I do and what not?)

When u have the same Problem, or u know how fast can I call the timer2 interrupt please write me back.

Thanks to all!


The PIC Programmer RID

PS: Sorry for my english.

[Ttelmah]

On the 18F chips, the 'slow' interrupt global handlers, do a _lot_. There are typically 17 registers that have to be saved (and restored on exit), then the test to see if the interrupt is enabled, and which interrupt occured (typically another four instructions if only one interrupt is in use), and then the actual jump to the handler. On returning from the handler, there is also the instruction to clear the interrupt itself. Hence there is an 'overhead' of about 23 instructions between an interrupt being detected, and actually arriving in the handler, and about 20 instructions between leaving the handler and returning to normal program flow.
The '8MHz', _is_ the 'reason for this'. If you quadruple the clock rate (using H4), the delays involved here will reduce (you have already found this).
Part two, then relates to this as well. The interrupt flag is not cleared till you leave the handler subroutine. So the shortest interval that can be used, and still detect the interrupt, is the total time to save all the registers in the global routine, _plus_ the time in the handler subroutine itself. The shortest interval that can be repeated, is this time plus the time to restore the registers and exit.
Now you can shorten the time a little by using the fast interrupt, but then you have to be sure that the registers that are needed, are saved. This depends on the compiler vesion, with older compilers expecting _you_ to do the required saving, while the last few releases handle this automatically. This reduces the overheads by about four instructions only.
The fastest method is to write your own int global handler _on the slow interrupt!_, and only save the required registers yourself. The reason for using the 'slow' interrupt, is that it involves one less jump, and is actually one instruction 'faster', if it is the only interrup handler present.
Using an array in the interrupt routine, will make things worse. Unfortunately, accessing an entry in an array, involves calculating the physical address from the index, then putting this into the table address registers, and then accessing the required data. Doing this, probably about doubles the times involved in the total routine.
So, I'd expect the minimum interval that will successfully trigger (with a short handler), to be perhaps thirty or more instruction times, unless you spend a lot of effort writing your own global handler. This gives the 15uSec for 8MHz. Using a custom written handler, upping the clock rate to 40Mz, and getting rid of array accesses in the interrupt subroutine, would allow a 'fastest' interval of perhaps 4uSec.

Best Wishes

[ckielstra]

As Ttelmah explained into detail it will be impossible to get a resolution higher than 4us in the PIC with the interrupt driven approach you suggested.

Is there a special reason you want to solve this problem in software? The PIC has inbuilt hardware support for exactly the purpose you want without stressing the processor: the capture/compare module. Another advantage is that you get 16-bit counters so you can increase your resolution and/or frequency range.

Search this forum for code examples. If you can't find a solution we are willing to help you.

[ckielstra]

Searching this forum I found a reference to the AD9833 chip which can generate frequencies up to 12.5MHz with 0,1Hz resolution (28-bit resolution). Costs around US$6 when buying in quantities of 10 pieces.
http://www.analog.com/en/prod/0,,770_843_AD9833%2C00.html