Searching \ for '[PIC] 18F high/low interrupt - return from high ba' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: '18F high/low interrupt - return from high ba'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 18F high/low interrupt - return from high ba'
2005\11\07@095352 by alan smith

picon face
I was looking over the high and low interrupts on the 18F series, but I need to have one thing clarified for me.  If I am in the middle of a low priority interrupt, and the high priority occurs, it will stop processing the low and jump the the high vector.  Does the stack automatically keep track so it will return back to the low where it stopped?  What happens if the low had just fetched a btfss/btfsc instruction....when it returns, I assume there is no context savings, or will it complete the branch first, putting onto the stack the address that it would have gone to had the high priority interrupt not occured.


               
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.  

2005\11\07@102513 by Jan-Erik Soderholm

face picon face
alan smith wrote :

> If I
> am in the middle of a low priority interrupt, and the high
> priority occurs, it will stop processing the low and jump the
> the high vector.  Does the stack automatically keep track so
> it will return back to the low where it stopped?

Yes.

>  What
> happens if the low had just fetched a btfss/btfsc
> instruction.

Doesn't matter.

> when it returns, I assume there is no context
> savings, or will it complete the branch first,

It will complete *any* instruction.

> putting onto
> the stack the address that it would have gone to had the high
> priority interrupt not occured.

Yes. I can't see how it would work otherwise...

You do know the "problem" with the shadow regs
(used in "fast return from interrupt") when using
dual int levels ?

Also, as far as I know, the dual interrupt levels
on the PIC18s aren't that much used. One level
is enought most of the time.

Jan-Erik.



2005\11\07@105654 by alan smith

picon face
You mention the problems....enlighten me if you can?  The problem I have right now, the target device is a 16F877 where one function is acting as a frequency counter, where it uses the rising edge interupt on port B0 to capture the incoming pulses, but there is a second interupt where it uses tmr0 (recall the thread about the one second interval....I did have the wrong crystal frequency used for the calculations, the 4.9152 was on the board) for a one second interupt, where it then measures the frequency in Hz (how many pulses occured in the one second interval) and it works fine up to about 200Hz.  I know the PIC is capturing the pulses up to the frequency of interest (500Hz) by looking at the input frequency and toggled an output port bit when it saw the pulse (both on the analyzer showed they tracked).  At frequencies approaching over 200Hz, it starts to deviate.  What I am thinking is that the intertupts are "fighting" each other...whoever is first wins of course.  So if!
 I setup
the high level interupt for TMR0, I would be more assured that I would be able to capture the pulse count more accuratly.  Maybe. I need to find/order a 4.9152Mc crystal to put on a board with a 18F part with the dual level interrupts to verify that theory.

Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com> wrote:
> putting onto
> the stack the address that it would have gone to had the high
> priority interrupt not occured.

Yes. I can't see how it would work otherwise...

TRUE....it has to work that way....but since the btfss/btfsc instructions say...branch here or branch there....will the stack have the branched address to return to??  I'm thinking yes....



You do know the "problem" with the shadow regs
(used in "fast return from interrupt") when using
dual int levels ?

               
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.  

2005\11\07@112102 by Jan-Erik Soderholm

face picon face
alan smith wrote :

> You mention the problems....enlighten me if you can?

That there is only one copy of the shadow regs used to
save/restore WREG, STATUS and BSR during the interrupt.
So only use "retfie, fast" from the high prio interrupt. The
low prio interrupt must save/restore the context much like on
the PIC16 line.

The shadow regs on the PIC18 can make short IRS's
considerable faster then on the PIC16, since context
saving is done "on th fly".

And since the PIC18 both runs faster, and have a "better"
instruction set, things can generally be done faster on them.

> The
> problem I have right now, the target device is a 16F877 where
> one function is acting as a frequency counter, where it uses
> the rising edge interupt on port B0 to capture the incoming
> pulses,

Aren't a timer used in "counter-mode" usualy used for that ?

> but there is a second interupt where it uses tmr0
> and it works fine up to about 200Hz.
> I know the PIC is capturing the pulses up to the
> frequency of interest (500Hz) by looking at the input
> frequency and toggled an output port bit when it saw the
> pulse (both on the analyzer showed they tracked).  At
> frequencies approaching over 200Hz, it starts to deviate.  
> What I am thinking is that the intertupts are "fighting" each
> other...whoever is first wins of course.  So if!

I'd look into using a timer as a counter instead to capture the
input pulses. That way one of the interrupt sources goes away.

Jan-Erik.



2005\11\07@123510 by olin piclist
face picon face
alan smith wrote:
> You mention the problems....enlighten me if you can?  The problem I
>  have right now, the target device is a 16F877 where one function is
> acting as a frequency counter, where it uses the rising edge interupt
> on port B0 to capture the incoming pulses, but the I setup
> the high level interupt for TMR0, I would be more assured that I would
> be able to capture the pulse count more accuratly.

I'm not totally sure what you're asking since your message was a bit
unclear, but how about using a CCP module for capturing the pulses for the
frequency counter.  These are great for measuing pulse period since the
timer value is captured in hardware when the pulse comes in, then the
software can take some time to read it as long as it gets there before the
next pulse.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\07@132353 by Neil Baylis

picon face
I agree that you shouldn't use an interrupt to count your input signal. Just
connect it to a couner input, e,g, TMR0 input. Then set the counter to
interrupt on overflow, if necessary so you can deal with overflow. All you
need to do then, is to create a gate signal that will control how long you
allow the signal to get into the counter. How you generate the gate depends
on how much precision you need.

I made mine this way, (Counts to 100 MHz on a PIC18F1220). All my interrupts
are high priority. Furthermore, each high priority interrupt services only
one interrupt and then does a return. If there was another interrupt
pending, it will immediately re-interrupt, and get serviced accordingly.

Neil

2005\11\07@141339 by alan smith

picon face
Yes I do agree that the CCP might be a better way, but of course I didn't design the hardware, just doing the firmware in this case.  However, given the customer choices of either dropping a new and different chip (nothing in a 44 PLCC package in a 18F series is compatible that I can find) OR moving signals around.....the latter may be more appealing to him.  Least he can stay with the same chip that he uses in several different products.  I'll wire up a board using that method and see if the results are better (I am thinking they should be)


               
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.  

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...