Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

High Interrupt Latency for PIC18F4520

Status
Not open for further replies.

mdeepamenon

Junior Member level 2
Joined
Apr 13, 2006
Messages
24
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,497
frequency input for pic18f4520

Hi,
We are working on PIC18F4520 micro controller with an external oscillator of 22.1184 MHz. We are using CCP2 capture interrupt which will capture a falling edge at the CCP2 pin input. The ISR for the CCP2 module will be called once the falling edge occured. We found that there is a latency between the occurance of the falling edge and execution of the first instruction in the ISR is 13 micro Seconds. This is a huge amount of latency due to which we are loosing synchronisation. Please suggest a way to reduce the interrupt latency. A latency of around 8 micro Seconds would be ideal for our case.

Thanks and Regards,
Deepa
 

pic18f4520 ccp2

Why the odd crystal frequency? Are you using the high priority interrupt?
Are you using the 4xPLL?
 
pic18f4520 + high priority interrupt

First of all, I have not run across a compiler that uses more than a dozen or so machine cycles in context saving for an ISR. In your case, with the 22MHz oscillator, that would amount to about 2-3us at best.

While some microseconds have passed for context saving before getting on with the ISR code your value in the CCPR2H and CCPR2L registers, which holds the TIMER1 value at the moment of capture, will still be valid.

Bear in mind, any other subsequent capture events that occur while inside the ISR will be missed. I believe that you will find that the datasheet makes this clear. So there are some capture timing limits if you expect to process the data.

If you have no capture events occur while inside the ISR, interrupt latency has no effect on the accuracy of your capture readings.
 
pic18f4520 registers

Hi,
Thanks for the reply.
There is a particular reason for selecting the clock frequency and it can not be changed.
The CCP2 interrupt is having highest proirity.
I am using MPLAB IDE Version 7.6 and Hi-Tech PICC Compiler Version 8.53 PL3.
I think it is necessary to put a few words about the ISR design.
The CCP2 ISR is hit when a falling edge is occured in the CCP2 input pin.
In the ISR, I will disable the CCP2 interrupt and wait for a rising edge.
The rising edge will ideally occur 17.3 micro Seconds after the falling edge.
Now, the problem is, it takes 13 micro seconds just to enter into the ISR and I am left with approximately 4 micro Seconds to disable the interrupt and execute the instructions for waiting for the rising edge. This time is not sufficient even though the code inside the ISR is optimized to the maximum. The only way to capture the rising edge is to decrease the initial interrupt latency.
Please suggest a method to decrease the latency.
Thanks and Regards,
Deepa
 

pic18f4520 speeded up

As I said before, 13us is too much time considering your oscillator speed. I think you are mistaken about something. If you are using MPLAB then post the code for the ISR section here and let's take a look.

Your PIC can also run @40MHz which will certainly speed up any code overhead.
 
how can we decrease interrupt latency

Use inline assembly code for interrupt service routine. This will save the C compilers overheads.

Cheers

Ravi
 
interrupt pic18f4520

hello


may be you are calling a function in the interrupt one.

We had already have this problem and solve it by remove all call to function

bye
 
decreasing interrupt latency

I have programs which calls a function in the interrupt routine, seems working fine.
 
interrupt routines for pic18f4520

Thanks all for the reply. The problem was because of high initial context saving. The hi-tech c compiler was using a lot of temperory variables in the assembly equivalent program. To save all these variables a large amount of time was being spent. so we have removed a lot of code from the interrupt routine to the main routine and got the problem solved.
Thanks and Regards,
Deepa
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top