Post by thread:[PIC:] RB0 INT, internal pullup, etc. Augh!

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

> 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

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

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

{Quote hidden}> > 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 > It would rather be: {Quote hidden}> org 0x04 > ISR > movf PORTB > andlw b'1111 1110' ;ignore state of RB0 > movwf tempPORTB ;put in temp file > rlf tempPORTB,f ;rotate and store in F > > 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 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.

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}>> >> 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 >> >It would rather be: >> org 0x04 >> ISR >> movf PORTB >> andlw b'1111 1110' ;ignore state of RB0 >> movwf tempPORTB ;put in temp file >> rlf tempPORTB,f ;rotate and store in F >> >> 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 > >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.

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

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.

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

{Quote hidden}>-----Original Message----- >From: pic microcontroller discussion list >[spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU] On Behalf Of Jinx >Sent: 23 July 2004 02:15 >To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU >Subject: Re: [PIC:] RB0 INT, internal pullup, etc. Augh! > > >> 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 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 listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> > > 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 .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

> 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_OUTTakeThisOuTmitvma.mit.edu

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

On Sun, 1 Aug 2004 11:55:24 -0400, csblondinspam_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.

Howard Winter wrote : > On Sun, 1 Aug 2004 11:55:24 -0400, @spam@csblondinKILLspamSYMPATICO.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.

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

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

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