Searching \ for '[PIC:] RB0 INT, internal pullup, etc. Augh!' 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/devices.htm?key=pic
Search entire site for: 'RB0 INT, internal pullup, etc. Augh!'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] RB0 INT, internal pullup, etc. Augh!'
2004\07\21@225556 by csb

flavicon
face
Hello,
This is my 3rd program for the 16F84A (written from scratch!). It was to test the RB0/int function. It finally works, but I haven't quite understood the reason it didn't work at first. Here's what it does:
RB1-7 connected to leds & 1k resistor to ground. One of them lights on at a time, when switch on RB0 is pressed it turns off and the next one turns on.
RB0 used as an interrupt on rising edge.
After initialising (ports, options & interrupts) the program goes in an endless loop waiting for a RB0 interrupt.
When it does, the ISR rotates PORTB left through carry, turns off RB1 (RB0 was 1 because of switch, shifted into RB1), if the last led turned on was RB7 restart at RB1. Anyway. The first time I tried I had RB0 grounded through a 10k resistor (to give a low signal when switch is open), and the switch is a wire that I plug/unplug in the supply row of my breadboard. (I vaguely heard about switch bouncing between 0 and 1?)  It was working weirdly (the first time I plug the wire in V+, the led shifts, normally, but the other pulses don't work. Now here's my question: Is it because after the first pulse the resistor couldn't pull the pin back to 0V? That's my hypothesis because when I used a 1k instead of a 10k it worked. But as far as I know it might be anything. I re-read the section on PORTB and Interrupts from the datasheet many times, and I still don't get what's going on with the weak pull-ups, internal whatevers &c. Can someone please demistify this?

csb

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\07\21@233513 by Jinx

face picon face
> When it does, the ISR rotates PORTB left through carry

Are you using  rlf portb ?

If so, this is not advisable because of the possibility of the read-
modify-write problem

http://www.piclist.com/techref/readmodwrite.htm

Better to use a shadow register

movf   portb,w       ;read the port into W
movwf  shadow    ;copy it to a shadow RAM register
rlf   shadow,w       ;rotate that register
movwf  portb       ;write it to the port

or similar, whatever it is you need to change LED

> (I vaguely heard about switch bouncing between 0 and 1?)

You'll get a lot of electrical noise doing this. ie the wire will make
minute
scratching contact (resulting in many 0s and 1s) before it finally makes
firm contact. Simplest way to get around this is to use a delay. Either
change the LED on the interrupt and then delay (with INT disabled or
ignored in this period), or start the delay on the interrupt and at the end
of it change the LED. More sophisticated schemes can be used

> Is it because after the first pulse the resistor couldn't pull the pin
back
> to 0V?

With no capacitance apparent, probably not

> when I used a 1k instead of a 10k it worked

Shoudn't make a lot of difference. Even with the PortB pullups on, a 10k
will pull the pin down. The p/u are very weak, from memory only 250uA

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\07\21@235036 by Jinx

face picon face
> > when I used a 1k instead of a 10k it worked
>
> Shoudn't make a lot of difference

Sorry, like to back-pedal there, was thinking of something else

I haven't tested this but 10k is probably too high to get the pin
down to a low input of 0.16Vcc (0.8V if Vcc = 5V) or 0.2Vcc (1V).
If the p/u is 250uA (I think) that implies a p/u R of 20k so you'd
need 3k8 or less to get down to 0.8V and 5k or less to get to 1V

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\07\22@105750 by CSB

flavicon
face
> > When it does, the ISR rotates PORTB left through carry
>
> Are you using  rlf portb ?

Here's what the ISR looks like:

       org 0x04
ISR                     ;RB0int service routine
       rlf             PORTB,F                                 <-------------
                       ;bit 1 holds switch state (high), lighting up
                       ;led1 additionned to the other one (whichever)
       bcf             PORTB,RB1       ;turn it back off       <-------------

       btfss   STATUS,C        ;have we gone past led 7 (shifted
                                               ;RB7 to carry)
       goto    skiprewind      ;skip if not

       bcf             STATUS,C
       bsf             PORTB,RB1       ;start again at RB1 (led 1)
skiprewind
                       ;now put back INTCON the right way
       bcf             INTCON,INTF     ;clear ext. int. flag
       bsf             INTCON,GIE      ;enable ints

       RETFIE

But I thought of trying, instead of the above
       org     0x04
ISR
       movf            portb
       andlw           b'1111 1110'            ;ignore state of RB0
       movwf   tempPORTB               ;put in temp file
       rcf             tempPORTB,W     ;rotate and store in w

       btfss           STATUS,C                ;was last led on RB7 (now in carry)
       goto            skip
       bcf             STATUS,C        ;erase carry
       bsf             tempPORTB,RB1   ;start again at RB1
skip
       bcf             INTCON,INTF
       bsf             INTCON,GIE
       RETFIE

along with a delay (not in it yet) for debouncing, just before re-enabling ints. Any idea of how much time to wait?
Indeed it does bounce, I had some fun just holding the wire barely scratching the v+ rail, and watching the leds go round and round...

thanks for helping,
csb

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@111034 by CSB

flavicon
face
{Quote hidden}

It would rather be:
{Quote hidden}

Here I forgot to put in
       movf            tempPORTB
       movwf   PORTB
which is kind of important.
>         bcf             INTCON,INTF
>         bsf             INTCON,GIE
>         RETFIE
> ...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@171831 by Bob Barr

flavicon
face
While it will make no difference in this particular program, it's good
programming practice, at a minimum, to preserve and restore the STATUS
register and the W value across interrupt execution. (This will be
absolutely necessary in more complicated programs.) You'll find
example code of how to do this in the interrupt section of the
device's datasheet.

Also, you shouldn't explicitly set GIE within the interrupt code.
Execution of the RETFIE will set it on completion of the interrupt
code.


Regards, Bob


On Thu, 22 Jul 2004 11:09:12 -0400, CSB wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@181850 by Jinx

face picon face
> ISR
>        movf            portb

movf  portb,w   or  movfw  portb

>        bcf             STATUS,C        ;erase carry

Carry will be over-written

> along with a delay (not in it yet) for debouncing, just before
> re-enabling ints. Any idea of how much time to wait?

For this, I'd make it fairly long, perhaps 250-500ms. If it was a
pushbutton, most people seem to use 50-100ms. There have
been several discussions about debouncing buttons, keys and
switches. Where you put the delay in this case doesn't make
much difference. It could be inside or outside of the ISR. GIE
should be off during the delay and INTF cleared

As Bob Barr (hi Bob) said, GIE is turned on with RETFIE and
context saving, and the driving-me-crazy problems that can
happen if registers are destroyed, is worth remembering

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@204054 by CSB

flavicon
face
Thanks a lot for your help, Jinx & Bob, now I've got it running smoothly, it doesn't double-rotate the leds anymore. Here's briefly what I did in the ISR:

       1-save STATUS & W
       2-load portb in a temp file, rotate, update portb
       3-wait 100ms for the switch to stop bouncing,
       4-wait for steady state (open switch): a loop in which every time RB0 is low, counter is decremented
       5-after 256 of those loops, restore STATUS & W, then RETFIE

I've tested with a real pushbutton switch, also a rudimentary wire-wire switch, and it works very well. I've also included "good programming practices"... although I have no intention of using this routine elsewhere, I agree it's a good reflex to have.
I also discovered the real use of RETFIE. At first I only thought it popped off PC, and I thought the difference between it and RETURN was only a different opcode. but now I know. Would RETFIE be replacable (functionnally) by a manual set of GIE bit and ordinary RETURN?

Thanks again,
csb

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@204938 by CSB

flavicon
face
replaced the 100ms delay (a big ugly piece of code) by the same wait for steady state used to detect low state. I'm pleased to report it works perfectly, and it's only 4words long! (instead of 23)
csb

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\22@211448 by Jinx

face picon face
> Would RETFIE be replacable (functionnally) by a manual set of
> GIE bit and ordinary RETURN?

Yes

RETURN is top-of-stack -> PC

RETFIE is top-of-stack -> PC and 1 -> GIE

You could detect an event and use RETURN if that interrupt wasn't
needed again or enable it some time later by setting gie

> Thanks again

No problem

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\23@032252 by hael Rigby-Jones

picon face
{Quote hidden}

It's not quite equivalent.  If you set GIE before a RETURN in your ISR, you
run the risk of any pending interrupts causing you to re-enter the ISR.
With this particular program that may not be so much of a problem (apart
from any stack depth limitations), but in a normal ISR using a context save
this will casue no end of grief.  This is essentialy the reason that the
RETFIE instruction is present, it sets the GIE bit *after* the return.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\07\23@053550 by Jinx

face picon face
> > > Would RETFIE be replacable (functionnally) by a manual set
> > > of GIE bit and ordinary RETURN?
> >
> >RETFIE is top-of-stack -> PC and 1 -> GIE

> It's not quite equivalent.  If you set GIE before a RETURN

Quite so, I didn't point out that the RETFIE sequence above is not
the same order in which CSB phrased the question

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\07\29@145242 by Wouter van Ooijen

face picon face
> Would RETFIE be replacable (functionnally) by a manual set of
> GIE bit and ordinary RETURN?

No, the order is wrong: RETURN first and then set GIE. Otherwise you
could get interrupted within the interrupt (which could cause stack
overflow).

So you kind-of could replace it, but where would you put the set-GIE?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


'[PIC:] RB0 INT, internal pullup, etc. Augh!'
2004\08\01@115549 by csblondin
flavicon
face
> So you kind-of could replace it, but where would you put the set-GIE?
>

Never mind that, I wasn't really thinking of putting it in, I only wanted to know if they did the same thing, bar the timing considerations. Though having an interrupt happening between the set GIE and RET would need quite a big piece of luck!

csb

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\01@121718 by Howard Winter

face
flavicon
picon face
On Sun, 1 Aug 2004 11:55:24 -0400, csblondinspamspam_OUTSYMPATICO.CA wrote:

> Though having an interrupt happening between the set GIE and RET would need quite a big piece of luck!

Errr - not really!  If PICs work the way of other micros I've used (and I'm open to being corrected here), the
GIE only masks the interrupt-causing event from being seen, it doesn't "stop it happening".  So if an
interrupt-causing event happened while GIE was clear, as soon as you set it the interrupt will occur.
Consequently there's a really good chance of it happening just when you don't want it, which is why the RETFIE
sets GIE "after" the return.

Enabling an interrupt too early is a classic "trap for the unwary"  :-)

Cheers,



Howard Winter
St.Albans, England

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\01@152304 by Jan-Erik Soderholm

face picon face
Howard Winter wrote :

> On Sun, 1 Aug 2004 11:55:24 -0400, @spam@csblondinKILLspamspamSYMPATICO.CA wrote:
>
> > Though having an interrupt happening between the set GIE
> > and RET would need quite a big piece of luck!

The interrupt *event* could very well happen (and set the
corresponding xxIF flag), but that's all that happens when GIE is
"disabled".

> Errr - not really!  If PICs work the way of other micros I've
> used (and I'm open to being corrected here), the
> GIE only masks the interrupt-causing event from being seen,
> it doesn't "stop it happening".

Correct. The xxIF flags will always be set. You could, if you
want, have GIE "disabled" all the time, and poll the xxIF bits
instead (but I'm not sure why :-) ).

> So if an
> interrupt-causing event happened while GIE was clear, as soon
> as you set it the interrupt will occur.

Correct.
You can have a "queue" of interrupts (as seen by a number of xxIF
flags beeing set), and they will be serviced one after another when
the RETFIE is executed from the iterrupt before.

Of course, your ISR *could* be written to service all pending
interrupts without any RETFIE in between. It's a matter of taste...

What I'm not sure of, is if there will be *any* instructions
executed after the RETFIE instruction when there is a "pending"
interrupt ? That is, in the non-interrupt code.

And you must also make sur that you don't by accident
clears any xxIF bits of interrupts that hasn't already
been serviced. If so, they will of course be missed.

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\01@181802 by Jinx

face picon face
> Correct. The xxIF flags will always be set. You could, if you
> want, have GIE "disabled" all the time, and poll the xxIF bits
> instead (but I'm not sure why :-) ).

I've needed to do that a few times, for example during comms
and display driving, ie interacting with other devices. Often the
PIC is and needs to be committed to one task and interrupt flags
are polled when time permits. Obviously this depends on where
the interrupts come from and their importance time-wise. One
app required reading quadrature encoders, two gyros, an LCD
and a lot of maths. Satellite PICs were used as encoder processors,
not a GIE in sight, and the whole thing ran very smoothly, which I
don't think would have been as easy to do with so many grabby
and frequent interrupts enabled

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\01@210637 by csblondin

flavicon
face
> interrupt-causing event happened while GIE was clear, as soon as you set it the interrupt will occur.
> Consequently there's a really good chance of it happening just when you don't want it, which is why the RETFIE
> sets GIE "after" the return.

...don't know where I got that, I thought a cleared GIE "disconnected" the T0IF-INTF-RBIF flags from their interrupt source, and that they would only change through the software, until the GIE was set again. In that case, an interrupt happening during an ISR would be 'forgotten about'... Ah! now it makes sense.

Thanks a lot guys, I'm sure that'll come in handy pretty soon. (frequency counter coming up...)

csb

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\01@211715 by Jinx

face picon face
> I thought a cleared GIE "disconnected" the T0IF-INTF-RBIF
> flags from their interrupt source, and that they would only change
> through the software, until the GIE was set again

There is a manual note which says "Interrupt flag bits are set
when an interrupt condition occurs, regardless of the state of
its corresponding enable bit or the global enabe bit. User s/w
should ensure the appropriate interrupt flag bits are clear prior
to enabling an interrupt. This feature allows for s/w polling"

IOW, as you've discovered, you can't stop IF bits being set, but
s/w won't jump to an ISR if IE and GIE are clear. If you enable the
IE and GIE with an IF set, then s/w will jump to the ISR

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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