Post by thread:[PIC]18F452 interrupt service routine

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.

On 1/7/06, Robertino Benis <spam_OUTrbenisTakeThisOuTairyz.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

> 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 <.....joshybearKILLspam@spam@gmail.com> wrote: > On 1/7/06, Robertino Benis <rbenisKILLspamairyz.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).

> > 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.

> 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

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/

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}> 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. > >

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

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

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}> 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 > > >

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}

> 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

> 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

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)

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}

> 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

> >> 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

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

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

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