Searching \ for '[PIC]18F452 interrupt service routine' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ints.htm?key=interrupt
Search entire site for: '18F452 interrupt service routine'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]18F452 interrupt service routine'
2006\01\07@213124 by Robertino Benis

picon face
Hi

I have one simple (and most likely quite stupid) beginner's question:  

How long is too long to keep an interrupt pin high on PIC 18F452? Does this
question make sense? I was not able to find that in PIC sheet from
Microchip.

I was testing with a 'push-on' switch that caused some odd behavior in
interrupt handling routine (interrupt pin: RB0/INT0).

My interrupt handling routine would change some values of variables in RAM
which would change how long the test LED lights and then switches off. Maybe
the routine was just badly written, but it may have something to do with how
long was that INT0 pin kept HIGH...

Any thoughts/comments?

Thank you...  
r.




2006\01\07@220437 by Josh Koffman

face picon face
On 1/7/06, Robertino Benis <spam_OUTrbenisTakeThisOuTspamairyz.com> wrote:
> How long is too long to keep an interrupt pin high on PIC 18F452? Does this
> question make sense? I was not able to find that in PIC sheet from
> Microchip.
>
> I was testing with a 'push-on' switch that caused some odd behavior in
> interrupt handling routine (interrupt pin: RB0/INT0).

Perhaps you're triggering again once the ISR exits.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\01\07@221411 by Robertino Benis

picon face


> Perhaps you're triggering again once the ISR exits.

That may be possible. So, if the pin stays up high long enough, after the  
interrupt service routine exits - interrupt is triggered again, and  
service routine is reentered. That would explain why sometimes I see the  
LED not changing flashing frequency...

So basically: how long that pin can stay high depends on how long it takes  
for the interrupt service routine to finish.

What is the best way to just send a "short" pulse to INT0 (caused by the  
push switch)?

Thanks again.


On Sat, 07 Jan 2006 19:04:37 -0800, Josh Koffman <.....joshybearKILLspamspam@spam@gmail.com>  
wrote:

> On 1/7/06, Robertino Benis <rbenisspamKILLspamairyz.com> wrote:
>> How long is too long to keep an interrupt pin high on PIC 18F452? Does  
>> this
>> question make sense? I was not able to find that in PIC sheet from
>> Microchip.
>>
>> I was testing with a 'push-on' switch that caused some odd behavior in
>> interrupt handling routine (interrupt pin: RB0/INT0).

2006\01\07@230923 by David VanHorn

picon face
>
> What is the best way to just send a "short" pulse to INT0 (caused by the
> push switch)?


THIS is where switch debouncing is needed.
It would probably be interesting to set up a counter to increment every time
the ISR fires, and then to toggle the switch once.

You could do it by AC coupling the switch, so that it is in series with a
small capacitor.

2006\01\07@233256 by Jinx

face picon face
> How long is too long to keep an interrupt pin high on
> PIC 18F452 ?

There's no maximum time Robertino. It won't get bored

> Does this question make sense ?

No, but we know what you mean

> I was not able to find that in PIC sheet from Microchip

Section 8.6 of DS39564B (the 18F452 manual) states that
INTx inputs are edge-triggered. That means it doesn't matter
how long the pin is up/down (or level triggered), the interrupt
is generated just on the rising or falling edge. What is most
probably causing your problem is contact noise

You should see the recent thread "[PIC] Comments on keypad
design ?" which covered debouncing switches. In your case I'd
suggest you have something like a 100nF (= 0.1uF) capacitor
with a 100k resistor in parallel with this from INT0 to ground. One
side of the switch connects to INTx and the other goes to Vdd
through a 10k  resistor. This 10k + 100nF is a filter that will take
out most if not all noise. The 100k discharges the 100nF when
the switch is released. Component values can be changed to suit
the application (eg for response time), but remember that the
voltage on INTx must get to the trigger voltage. So, for example,
you can't have the pull-down (100k in my example) lower than
the pull-up (10k in my example)

Table 1-3 shows that INTx pins are ST (Schmitt Trigger) when
used as external interrupt sources. Section 22.2 DC Characteristics
at the back of the manual shows that VIL for ST is 0.2 x Vdd
and VIH is 0.8 x Vdd

2006\01\08@002324 by Herbert Graf

flavicon
face
On Sat, 2006-01-07 at 19:10 -0800, Robertino Benis wrote:
>
> > Perhaps you're triggering again once the ISR exits.
>
> That may be possible. So, if the pin stays up high long enough, after the  
> interrupt service routine exits - interrupt is triggered again, and  
> service routine is reentered. That would explain why sometimes I see the  
> LED not changing flashing frequency...
>
> So basically: how long that pin can stay high depends on how long it takes  
> for the interrupt service routine to finish.
>
> What is the best way to just send a "short" pulse to INT0 (caused by the  
> push switch)?

I think you'd be solving the wrong problem.

The problem is switches are "noisey", and push button switches are the
worst. Depending one what you've got, the easiest is to debounce the
switch with hardware. Try google for that.

Debouncing can be done in software, but it can get tricky.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\08@003734 by Rolf

face picon face
Since you say you are a beginner, and I am one as well, I thought I
would make sure that you are resetting the INT0IF in the interrupt routine.

Dumb mistake I have made a few times already.

While I am at it.... make sure that no other interrupts are enabled, or
at least they are handled (???IF = 0) if they are enabled.

Rolf

Robertino Benis wrote:
{Quote hidden}

2006\01\08@004841 by Harold Hallikainen

face picon face
As I recall, the external interrupts are edge triggered, so it would not
matter how long the pin stayed in either state. It sets the IF flag on the
edge, not the level. If your ISR does its work and clears the IF while the
pin is still high, that's fine. Assuming a positive edge tigger, the edge
when the pin goes low is ignored, and the following positive edge is
detected. You mention you have a switch driving the external interrupt
pin. Are you dealing with switch bounce? You could generate a bunch of
interrupts on one switch closure, and again when the switch is released,
due to bounce. You can debounce in hardware prior to the interrupt line,
or, instead, poll the switch using a timer interrupt and require the
switch to be in the same position for some number of calls of the timer
interrupt.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

2006\01\08@193431 by Robertino Benis

picon face
Hi

>> What is most probably causing your problem is contact noise

You were right.

Putting 0.1uF capacitor in parallel with 100K resistor and connecting them
to the INT0 and the ground helped filtered that bounce out, as u suggested.

Also thank you for the pointers to the datasheet form Microchip.

I haven't put any counter(s) into the ISR routine, because I would first
need to add an LCD or something to see/read the value :)

Interrupt is now processed (almost) every time correctly. Unless I somehow
push that switch button "awkwardly" then it may get triggered twice (or at
least it looks like it was twice).

There must be some better push switch than that (this is the current guy:
www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&sto
reId=10001&catalogId=10001&productId=106112 , JAMECO part #106112).

I'll look for something more robust and hopefully less noisy.

Thanks,
Robertino


2006\01\08@200407 by Rolf

face picon face
Someone posted this a while back, and I found it exceptionally useful.

The author concludes that there is only one hard-ware mechanism for a
reliable debounce, and that there are few good software versions.

Additionally, there is no such thing as a bounce-free switch.

An RC mechanism is not reliable.

I have recently implemented a mechanism for 4 buttons based on his
recommendations, and it has been very reliable.

http://ganssle.com/debouncing.pdf

Rolf


Robertino Benis wrote:
{Quote hidden}

2006\01\08@201723 by Robertino Benis

picon face

Hi

This document you just pointed out, http://ganssle.com/debouncing.pdf, also
describes RC fileter as quite efficient (Page 12, RC debouncers).

There is quite obvious, significant improvement from last nite, on my board
at least. However, as you said - it's not exactly perfect.

Any thougts about MC14490 (Contact Bounce Eliminator)? It's around 3.5 USD a
piece (on their web site):

https://www.onsemi.com/PowerSolutions/product.do?id=MC14490

Is that much better then simple RC filter which I tested (by Jinx
suggestion) with interrupt service routine?

Thanks,
r.

{Original Message removed}

2006\01\08@201827 by Jinx

face picon face

> Additionally, there is no such thing as a bounce-free switch.
>
> An RC mechanism is not reliable.

I'd disagree with that a little. An optical interrupter followed
by an RC and ST is immune to practically all noise. I had to
make some for a marine envronment and they work as well
now as they did 15 years ago, despite being exposed to salt
air / water and dust and who knows what else. There is no
contact as such though, which is cheating I suppose

The Ganssle document is useful for mechanical switches, thanks

2006\01\08@202355 by Jinx

face picon face
> Unless I somehow push that switch button "awkwardly" then it
> may get triggered twice (or at least it looks like it was twice)

It might help if you clear INT0IF right before you leave the ISR,
if you aren't already doing that. The flag could get set by contact
noise during the ISR, and when GIE is re-enabled with RETFIE
as you leave, PC will jump straight back into the ISR. If you
have a short-ish ISR and RC debouncing this may not be the
case, but that might depend on the quality of the switch

2006\01\08@205338 by Jinx

face picon face
part 1 784 bytes content-type:text/plain; (decoded 7bit)


> Any thougts about MC14490 (Contact Bounce Eliminator)? It's around
> 3.5 USD a piece (on their web site):

If you were thinking of a chip solution, a cheaper option might
be a monostable made from NOR (eg 4001, 7402) gates. Using
a 4001 with 1M for R and 100nF for C you might expect a
period of around 50ms. The first L-H transition sets the o/p high
and any further triggers (ie noise) are ignored until the timing
period is over. Unfortunately, switches also make noise when
they release too, so an RC filter on the i/p would help avoid
re-triggering on release. You could filter the signal ad nauseum
with both s/w and h/w (even a couple of transistors arranged as
a Schmitt Trigger) but could still be caught out by a rubbish
switch


part 2 531 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\01\08@211401 by Robertino Benis

picon face
Hi

It already works really well (comparing with the last night, when there was
no RC filter - heaven and hell difference).
I just got about 45 times in a row that interrupt was processed as expected
(caused by the switch) as indicated by the test LED flashing frequency
change.

I am cleaning the interrupt flag right before RETFIE with BCF INTCON, 01h
(which should clear INT0IF bit).

If this keeps working well, I might just try replacing that big switch with
something smaller and with some better push-to-'click' feel, before doing
anything else with extra IC gates.


Thanks,
r.  






{Original Message removed}

2006\01\08@214920 by Jinx

face picon face
> I am cleaning the interrupt flag right before RETFIE with BCF
> INTCON, 01h (which should clear INT0IF bit)

It would be better to use the flag name, BCF INTCON,INT0IF
so that you avoid typos, make it easier for yourself to read in the
future and so that it's clear to anyone else

> If this keeps working well, I might just try replacing that big switch
> with something smaller and with some better push-to-'click' feel,
> before doing anything else with extra IC gates

Tact switches can be had with that "click" to them, and they
seem to be better than those that are "soft". And at least they
give the user some feedback. Probably the worst are rotary
and slide switches

2006\01\08@223730 by Harold Hallikainen

face picon face

>
>> Any thougts about MC14490 (Contact Bounce Eliminator)? It's around
>> 3.5 USD a piece (on their web site):
>
> If you were thinking of a chip solution, a cheaper option might
> be a monostable made from NOR (eg 4001, 7402) gates. Using
> a 4001 with 1M for R and 100nF for C you might expect a
> period of around 50ms. The first L-H transition sets the o/p high
> and any further triggers (ie noise) are ignored until the timing
> period is over. Unfortunately, switches also make noise when
> they release too, so an RC filter on the i/p would help avoid
> re-triggering on release. You could filter the signal ad nauseum
> with both s/w and h/w (even a couple of transistors arranged as
> a Schmitt Trigger) but could still be caught out by a rubbish
> switch
> --


For hardware debounce, I like RC filters driving a schmitt trigger. Since
the interrupt inputs are, as I recall, schmitt trigger inputs, you could
have a pull-up resistor on the switch (or use a SPDT to switch the line
between +5 and ground), then an R to the pin with a C to ground at the
pin. The edge becomes slow moving so bounce has a smaller voltage change
across the capacitor than the hysteresis of the input.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

2006\01\09@063407 by Gerhard Fiedler

picon face
Rolf wrote:

> The author concludes that there is only one hard-ware mechanism for a
> reliable debounce, and that there are few good software versions.

I pretty much always debounce in firmware. Usually I need something like a
system a timer interrupt anyway, so I just use that to poll and add a
simple "safety wait". Very simple, cheap and robust.

Gerhard

2006\01\09@080759 by olin piclist

face picon face
Robertino Benis wrote:
> How long is too long to keep an interrupt pin high on PIC 18F452? Does
> this question make sense?

No.  What is an "interrupt pin"?

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

2006\01\09@100928 by alan smith

picon face
You either need to one-shot with debounce the input switch, or don't leave the ISR till the switch is released....not a good design practice tho, I would think.  If you set it up so its on the INT pin, look for the falling edge (can't do the debounce in software now tho) then it will not trigger till its released, and pressed again, assuming you have a pullup in the signal.  Might just end up using like a reset chip, that accepts an external switch as well as for powerup and feed that to the interupt input.


               
---------------------------------
Yahoo! DSL Something to write home about. Just $16.99/mo. or less

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