Fast Interrupt - output pulse with input

prayami · Joined: 22 Dec 2004 Posts: 78

Hi...I am using 18F4525 with 10Mhz crystal and PLL so 40Mhz Clock.

For first step, I am applying input to CCP1 of 50Hz. And want to generate
same output pulse on PIN C5. Program is simple and it is generating
output pulse correctly. But if I check the timing of the output pulse then
it is 4us on the rising edge.

I have checked the disassembly and there are only three instructions. So
it should be 0.3us or may be little more but not 4us.

How much minimum time require to serve the interrupt ?
I don't know assembly, so if it is require to write fast interrupt then How
can I write it?
Here is the code...

treitmey · Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA

Can you describe what your overall design is. I don't understand why you take in a signal and want to make a copy of it.

Why don't you just route that signal to where you need it?

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks for reply...

Because in the next step, I want to do phase shift in the output pulse
from the input. So for this program, you can say phase shift is zero.

Our input will be from 1Hz to 150Hz.

As interrupt is serving slow, there is all ready 5us delay between input
pulse and output pulse.

The problem is at 150Hz max frequency input, 5us is too much in our
application. Because we want 0.1 degree resolution. so 5us is affecting
a lot in our application.

I don't know, why it is taking this much time. Actually there are aroung
four instructions before output changes. So there can be max 0.4us
or nearer difference in the input and output but not 5us.

Please give me some idea to achieve this task.

Ttelmah · Guest

Does the system have to do anything else, other than time delay the waveform?. If not, then forget the interrupt, poll the input, and control the output when it changes.
The problem you are seeing is the interrupt latency. There are a number of 'parts' to this. Firstly, there is up to four clock cycles latency in the hardware, before the interrupt is even seen. then the software, has to save a copy of every register that may be in use in the main code (typically about 30 instructions), then test what interrupt has occured, and whether this interrupt is enabled (perhaps another 8 instructions), jump to the handler code (another couple of instruction times), and then finally execute your code (just a handful of instructions as described). Given that each instruction costs 4 instruction times, you have something in the order of 4.5 to 5uSec delay.
If you poll, instead of using an interrupt, and the system has to do nothing else, you should be able to get this below 0.5uSec fairly easily. However if you want real accuracy, approach it completely differently. Look at something like a hardware shift register, and change the clock frequency to this to alter the shift.
If there are no other interrupts in use, and all the code in the interrupt is distinct from that outside (so the interrupt protection never gets executed, and disables interrupts in the main code), the delay will remain pretty near to fixed (it'll vary slightly depending on the clock relationship between the signals).
You could also consider doing the job in hardware. Program the delay interval into one CCP, and program the other to reset the corresponding counter on it's change, which you source from the signal. set this to count to just '1', and on the next edge, the timer will reset, and then the output of the second CCP, will change after the programmed period. Only some chips allow the CCP's to be setup this way, and you will need to reverse the active 'edge' for the signal, as soon as the timer starts, to catch the next edge.

Best Wishes

bfemmel · Joined: 18 Jul 2004 Posts: 40 Location: San Carlos, CA.

prayami wrote:

wireless · Joined: 02 Nov 2003 Posts: 16 Location: London England

Prayami

I think the delay you describe is due to the interrupt start-up code which saves a large number of variables.

If you are only using one interrupt source can I suggest you look at the #INT_GLOBAL pre-processor command. This does not generate any start-up or clean-up code and so does not save any registers.

All you need to do is replace your #int_ccp with #int_global.

I have had similar problems with a decoder for high speed manchester coded data .

Good luck

Terry

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks ...for replying....

But, There will be total 5 interrupts will be there and enough code inside
the while loop. So I can't write code inside while loop. I have to use
interrupt.
And thus can't use #INT_GLOBAL as well.

So as you guys stated. I think there is no way left to reduce the delay
between two pulses from 4us.

Ttelmah · Guest

If one of the other interrupts also occurs, the delay is going to be even worse, and will vary....
Consider something really low level. If you just need to delay the signal by an amount, use something like one of the really cheap PICs, sitting in a polled loop, which delays by an amount defined by an integer presented on it's input pins. Have it do nothing else at all. The main chip then does the other jobs, and sets the required delay value fed to this. There are programmable delay chips on the market to do this, but most are more expensive than the PIC used this way.

Best Wishes

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks....Ttelmah.....

I think , we have to use another processor then.

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands