View previous topic :: View next topic |
Author |
Message |
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
considerable time lag in isr |
Posted: Mon May 02, 2011 10:43 am |
|
|
HI There,
I'm using the INT_EXT input to set/reset when my pwm should be active. I came up with following isr code:
Code: |
#INT_EXT
void SyncInt() {;
static int1 PulseState = 0;
PulseState=input(SYNC_IN);
output_bit(SYNC1,PulseState);
output_bit(SYNC2,PulseState);
SyncActv = PulseState;
if ( PulseState ) {
ext_int_edge( H_TO_L ); //set interrupt to kick in on falling edge
setup_ccp1(CCP_PWM); //enable pulse witdth modulator
setup_ccp2(CCP_PWM); //enable pulse witdth modulator
} else {
ext_int_edge( L_TO_H ); //set interrupt to kick in on rising edge
setup_ccp1(CCP_OFF); //enable pulse witdth modulator
setup_ccp2(CCP_OFF); //enable pulse witdth modulator
}
} |
Now for some reason I see a time lag of 18 - 36 uS between the rising edgo on PIN_B0 and until the pic starts the pwm.
Is there any chance to minimize this timelag, it shouldn't be so huge as far as I'm concerned.
I have a work around that's implemented in hardware already so my application doesn't depend on this timelag being ~0 I just wanted to see how big the timelag is and am surprised to see it's so much... Any clues?
Thank you. |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon May 02, 2011 11:07 am |
|
|
Depending on your clock speed that delay may be quite reasonable. Interrupts are slow. The faster way to do this is to know about when you expect the edge to happen and poll the input. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
![](templates/subSilver/images/spacer.gif) |
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
|
Posted: Mon May 02, 2011 11:14 am |
|
|
Uhm okay, well, polling isn't appropriate here as I said, I already have a solution for this problem. I however wouldn't have expected the interrupt handling to be that slow. As 36uS at 20MHz are 2880 instructions which is more than I would expect from an interrupt handler to call (and execute) the isr.
Is that really realistic? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon May 02, 2011 11:58 am |
|
|
Quote: | As 36uS at 20MHz are 2880 instructions |
Download the 16F877 data sheet (you didn't specify your PIC):
http://ww1.microchip.com/downloads/en/DeviceDoc/30292c.pdf
Look at the summary of the PIC's features on Page 3.
What does is say is the length of the instruction cycle at 20 MHz ? |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Mon May 02, 2011 12:17 pm |
|
|
Also, page 162 gives detailed info on this (be sure to see note 1) _________________ Google and Forum Search are some of your best tools!!!! |
|
![](templates/subSilver/images/spacer.gif) |
collink
Joined: 08 Jan 2010 Posts: 137 Location: Michigan
|
|
Posted: Mon May 02, 2011 12:59 pm |
|
|
And, just to complete this whole discussion: What they mean is: it takes 4 clocks per instruction so one instruction takes 0.2uS at 20MHz. 36uS is thus 180 instruction times not 2880. You were only off by a factor of 16. 180 instructions seems a bit more reasonable doesn't it? |
|
![](templates/subSilver/images/spacer.gif) |
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
|
Posted: Mon May 02, 2011 1:08 pm |
|
|
Hey guys,
Thanks for the replies and yes, it looks more reasonable now. And I'm using a 16F883 here.
Thanks again for shining some light into the dark
Ron |
|
![](templates/subSilver/images/spacer.gif) |
|