Post by thread:Newbie Toggle Switch Woes

I'm working on the PIC equivalent of "Hello World" and using stuff from the Easy PIC'n book and a PICDEM-1. Now I realize that routines in the book are not for the PICDEM-1, which may be where my troubles start - at this point, I label the PICDEM as moderately useless. Anyway... I'm trying to get a toggle switch routine to work. I've created a register for the on/off status and it appears that the bits are being set and cleared properly. The problem comes when the button is pressed. RA1 is clearly pulling low and the LED will come on for a few seconds - then it shuts off. It's behaving like the switch is being pressed again. Am I missing a control-of-flow point here with the btfsc's or does my PICDEM board have some bizarre behavior? - like a leak? Here's my code: list p=16f84 radix hex porta equ 0x05 portb equ 0x06 swst equ 0x0c ;switch status register st equ 0 ;switch bit org 0x000 start movlw b'11111111' ;set porta for input tris porta movlw b'11110111' ;set bit 3 for output tris portb clrf swst ;clear switch register bcf portb,3 ;turn the LED off switch btfsc porta,1 ;is the switch pressed? goto switch ;no, check again btfsc swst,st ;is this already on? goto off ;yes, turn it off on bsf portb,3 ;turn the LED on bsf swst,st ;set the status bit goto switch ;go wait for another press off bcf portb,3 ;turn the LED off bcf swst,st ;clear the status bit goto switch ;go wait for another press end

David Olson wrote: > start movlw b'11111111' ;set porta for input > tris porta > movlw b'11110111' ;set bit 3 for output > tris portb > clrf swst ;clear switch register Welcome to the wonder world of PIC's! I notice you Tris all the unused pins as inputs, did you connect them to ground? If not, Tris all your unused pins as outputs, and do not tie them to ground. There is an ongoing discussion about whether to make unused pins as inputs and tie them to ground, or tris the pins as outputs and just let them float. Find out what works best for you. Also, your input pin for the switch, did you use a pull up resistor to keep the input pin high when the switch is not made? The rest of your code is fine. You can make the code a whole lot shorter, but as you are still learning, I am not going to tell you, figure it out yourself. Tip: PortA and PortB are also registers. Quentin

Quentin, thanks for the input. > Welcome to the wonder world of PIC's! > I notice you Tris all the unused pins as inputs, did you connect them to > ground? > If not, Tris all your unused pins as outputs, and do not tie them to > ground. With the PICDEM, it appears all pins are used - portb to LED's and porta to switches and pots. I checked them and they're running low - about .6v when the circuit is hot. > There is an ongoing discussion about whether to make unused pins as > inputs and tie them to ground, or tris the pins as outputs and just let > them float. Find out what works best for you. It's amazing just how many opinions there are out there! > Also, your input pin for the switch, did you use a pull up resistor to > keep the input pin high when the switch is not made? The PICDEM has it tied to a 4.7k pullup and to Vdd. > The rest of your code is fine. You can make the code a whole lot > shorter, but as you are still learning, I am not going to tell you, > figure it out yourself. Tip: PortA and PortB are also registers. The reason I'm snooping out this method is that I eventually will have the switch's status in EPROM to retain the state if I lose power beyond the brownout protection. In other words, if I have a disorderly shut down, I'd like the switches to remember where they were. If it's a "proper" shut down, the status will be cleared - I realize that this is probably easier to say than do. As for the shorter part, I'll label that as a "duh!" - I'm used to higher-level languages and this assembly stuff is a bit more of a challenge. In addition, I find myself crying for a monitor where I can fire off some "print" statements once and a while. Oh well, one person's monitor is another person's scope and DMM. -DO -DO

I was at a PIC seminar 2 ¸ years ago, and they suggested that you leave unused pins as outputs. At the seminar last month the suggestion was (different spokesperson) to let unused pins be inputs, and tie them low (or high). So... Anyway, an unused open input floating also causes the problem of an unexpected current consumption in sleep mode. Sven -----Ursprungligt meddelande----- FrŒn: Quentin <qscKILLspamICON.CO.ZA> Till: .....PICLISTKILLspam.....MITVMA.MIT.EDU <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> Datum: den 11 april 1999 08:07 €mne: Re: Newbie Toggle Switch Woes {Quote hidden}>David Olson wrote: > >> start movlw b'11111111' ;set porta for input >> tris porta >> movlw b'11110111' ;set bit 3 for output >> tris portb >> clrf swst ;clear switch register > >Welcome to the wonder world of PIC's! >I notice you Tris all the unused pins as inputs, did you connect them to >ground? >If not, Tris all your unused pins as outputs, and do not tie them to >ground. > >There is an ongoing discussion about whether to make unused pins as >inputs and tie them to ground, or tris the pins as outputs and just let >them float. Find out what works best for you. > >Also, your input pin for the switch, did you use a pull up resistor to >keep the input pin high when the switch is not made? > >The rest of your code is fine. You can make the code a whole lot >shorter, but as you are still learning, I am not going to tell you, >figure it out yourself. Tip: PortA and PortB are also registers. > >Quentin >

The Idea is right but you must have some form of debounce code try something like this> flags equ 10h flags register sw equ 0 bit ra0 on port led equ 1 bit ra1 on port same equ 1 store result in same register w equ 0 store result in w register switch btfsc porta,sw test for switch pressed goto switch switch not pressed decfsz counter,same time how long switch is held goto switch not held long enough loop back movlw 255 reload debounce timer movwf counter btfsc flags,0 test led status goto ledoff switch led off bsf flags,0 set led status on bsf porta,led switch on led goto test1 go test if switch released ledoff bcf flags,0 set led status off bcf porta,led switch led off test 1 btfss porta,sw test if switch released goto test1 switch not released goto switch switch released return to switch Regards Mark Esilva saverspam_OUTpta.lia.net {Original Message removed}

David, Thank you very much. Code too! Seems silly that a simple illuminating LED can bring such joy. While I'm debouncing, Andy Kunz asked the question about the size of my resistors (I hope it wasn't personal) and I recall them to be 4.7k tied to Vdd. Now, what determines the size of the resistor? You'll have to excuse my innocence - I'm a software guy trying to swim with the hardware sharks and while I have read a bunch of books, sometimes the obvious, and potentially embarrassing, question is necessary. I'm assuming here that we are current limiting to reduce the current potential of the RA.0 pin? But, couldn't there be a problem with over-resisting and have our HIGH not high enough? Friends, as always, I appreciate your input. -DO > {Original Message removed}

I find this to be overkill. I design the hardware to interrupt on keypress. I start the timer, and when the timer is done, I read the keypress. I use a keypad that gurantees debounce time <10 ms, which makes life about as easy as can be. I then wait until the key is definitely released before allowing another to be read. About as simple as can be. I guess it depends how robust your application needs to be... adjust your code accordingly. ---------- > From: Andy Kunz <KILLspammtdesignKILLspamFAST.NET> > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: Newbie Toggle Switch Woes > Date: Monday, April 12, 1999 10:00 AM > > >Anybody have a favorite debouncing scheme? > > I use TMR0 to debounce. I only test the switch after "n" TMR0 overflows, > and only count the state as changed after it has been consistently in that > state for "y" times. > > You want to set it up so you get at least 3 samples over a 10-30mS period. > > Andy

At 14:12 04/12/99 -0400, David Olson wrote: >While I'm debouncing, Andy Kunz asked the question about the size of my >resistors (I hope it wasn't personal) and I recall them to be 4.7k tied to >Vdd. Now, what determines the size of the resistor? You'll have to excuse my >innocence - I'm a software guy trying to swim with the hardware sharks and >while I have read a bunch of books, sometimes the obvious, and potentially >embarrassing, question is necessary. > >I'm assuming here that we are current limiting to reduce the current >potential of the RA.0 pin? But, couldn't there be a problem with >over-resisting and have our HIGH not high enough? when you have an input and a pull-up resistor which is connected to a switch (i guess that's your case, isn't it?), the "theoretical" maximum value for the resistor is given by the max. specified input current and the minimum "hi" voltage (both from the data sheet). the voltage across the resistor must be lower than (Vdd - Vih), so the resistor must be smaller than (Vdd-Vih)/Iin (that's around (5V - 2V)/1uA = 3MOhm). usually you choose a much smaller value, to have some safety margin and to be less sensitive to noise. that's a trade-off between power consumption and noise sensitivity. with 4k7 you're pretty much on the "safe" side. the resistor is not "current limiting to reduce the current potential of the RA.0 pin," it's primarily limiting the current that flows through the switch to ground when it is closed. so the minimum value is given by the maximum current you can provide for that from your pwer supply. with the 3MOhm that would be 1.7uA (at 5V), with your 4k7 that would be close to 1mA. that's usually too much for battery driven (or otherwise power-restricted) circuits, but other than that it's fine. ge

David Olson wrote: > Now, what determines the size of the resistor? You'll have to excuse > my innocence - I'm a software guy trying to swim with the hardware > sharks and while I have read a bunch of books, sometimes the obvious, > and potentially embarrassing, question is necessary. Others have answered. The limits on how *low* the value can go are purely on how much current you can afford and for how much current the switch is rated. We can assume the bakelite-cased ones are rated according to the stamped-on figures, and membranes and keyboard units for about a milliamp or two (quite arbitary). The three constraints on how *high* your pullup may be are the input impedance (PICs: many megohms) including the switch leakage (???) and the possibility of moisture in the assembly; the potential (mostly capacitive) impedance of noise sources, and not mentioned, the "wetting" current of the contacts. Most contact materials are prone to the development of non-conductive oxide, sulphide etc. coatings. Approaches to avoid this include material choice; carbon for example as used on membrane contacts has a non-contaminating oxide and is reasonably inert whilst silver has troublesome sulphides. Protection by vacuum (reed switches) or grease is another possibility, but a traditional approach is to use a "wetting" current which causes a tiny arc with each operation which thus bares the contact surface. Additionally a wiping action may be built into the switch (keyboard switches do this) to mildly abrade the contact with every operation. Wetting currents of the order of a milliamp are probably appropriate for small contacts, so the 4.7 k ohm resistors specified sound good. For normally-open pushbuttons, you can generally afford this current even on battery supplies but if critical, ten times the resistance will probably work just as well. -- Cheers, Paul B.

Justin, I know your mention of hardware is actually for the switch to generate an interrupt but, would you consider a NAND gate latch setup? Or is this too much or unnecessary hardware? I've build a sample circuit like this before but I've never tested its resiliency with a range of switches that have varying debounce times. Any information I've gathered from this approach has not pointed to this being a "better" solution. Unfortunately, I need this to be as robust as possible and with the solution being through software, I could at least "tune" the debounce if switches are chosen outside a comfortable range. I'm in the investigation phase right now and I'm using some simple SPST, normally open, momentary switches - I will ultimately move this to a setup that is rubber keypad/PCB contact assembly, for which I really appreciate the note from Paul Webster on switch/key design - that was great. -DO > {Original Message removed}

Hello David, list (was going to make this private but maybe...) David Olson <spamBeGonedolsonspamBeGonePROGRESS.COM> wrote: > would you consider a NAND gate latch setup? Or is this too much or > unnecessary hardware? It's a concept thing. A PIC is a cheap device to "do things". It is intended to reduce designs to the absolute minimum of parts. Using an IC to pre-process data *for* the PIC is very much against the grain if the PIC can do it for itself, and switch de-bouncing is a perfect example. I'd go for Andy's proposal. If nothing else (and there is nothing else), he knows his stuff. My summary: * Do not use an interrupt for pushbuttons. Always use polling. (*Possible* exception: PIC is used in Sleep mode: Use PORTB change interrupts.) Interrupts are for events that are brief and need immediate attention. This fails to describe a pushbutton by a factor of 10,000 or more! * Forget switch paramaters (exception: it's not a pushbutton but a sensor e.g.; opto-interrupter, contact on assembly etc.). You can't physically actuate a pushbutton more than ten times per second and almost certainly don't want to be able to, so the debounce cycle need be no shorter than 50mS. So make it 50mS! * Use a timer function you have. Surely you are keeping track of something, most likely counting seconds? Timer 0 counts four times per millisecond, or you can prescale it by four, so you have a rough one- millisecond clock. This can either be an interrupt, or polled; it most likely can tolerate jitter (but will *still* be as dead accurate as the crystal) and 1024 instructions is plenty of time to do some other job and poll as well. * You need a counter, and the "current state" of the button. Since the counter only has to count to 32 or so, you can combine these in one byte. Use the MSB as the "state". While ever the button matches the current state, preset the counter to say, 31. While ever (this is, on each millisecond poll) the button does not match the current state, decrement the counter and if it is now zero, perform the action (for button press or button release), set the "current" state to match the button and reload the counter. * Variations: 1} It is possible to make the action happen on the first detection of an altered state, but not to happen again until a full on/ off cycle is determined. 2} It is possible to make the counter count up for press, down for release, and having counted beyond the debounce value, to generate auto- repeat each time it overflows. Using a 7-bit count (eighth bit is the "current_state" memory) this would be eight per second at 1mS poll or four per second at 2mS poll (and debounce at count of 16). > I've build a sample circuit like this before but I've never tested its > resiliency with a range of switches that have varying debounce times. > Any information I've gathered from this approach has not pointed to > this being a "better" solution. This refers to the NAND gate R-S flipflop with a SPDT switch? Care to elaborate? > Unfortunately, I need this to be as robust as possible and with the > solution being through software, I could at least "tune" the debounce > if switches are chosen outside a comfortable range. "Tune"? Maybe, but in this case, overkill should work fine! ;-) -- Cheers, Paul B.

Paul pretty much summarizes everything in his reply to this. He does a great job. Most of my applications do something on keypress, then sleep, so I use the PORTB interrupt. If your PIC is on constantly, polling is the better solution. I agree with pretty much everything Paul states, except that using an interrupt is undesirable. Many applications "do something on keypress", so using a PORTB interrupt to start a debounce timer, and another interrupt when debounce complete, is a very convenient method for a lot of applications. I usually am tight on RAM, so using none at all for my keypad code (except for hardware flags) is rather convenient. ---------- > From: David Olson <TakeThisOuTdolsonEraseMEspam_OUTPROGRESS.COM> > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: Newbie Toggle Switch Woes > Date: Tuesday, April 13, 1999 10:55 AM > > Justin, > > I know your mention of hardware is actually for the switch to generate an > interrupt but, would you consider a NAND gate latch setup? Or is this too > much or unnecessary hardware? I've build a sample circuit like this before > but I've never tested its resiliency with a range of switches that have > varying debounce times. Any information I've gathered from this approach has > not pointed to this being a "better" solution. > > Unfortunately, I need this to be as robust as possible and with the solution > being through software, I could at least "tune" the debounce if switches are > chosen outside a comfortable range. > > I'm in the investigation phase right now and I'm using some simple SPST, > normally open, momentary switches - I will ultimately move this to a setup > that is rubber keypad/PCB contact assembly, for which I really appreciate > the note from Paul Webster on switch/key design - that was great. > --SNIP

Paul, Thanks for making this public - since I've not found a lot of information on this topic. By the way, for whoever's listening, I usually peruse the archives before I bother you all with a question. I've found the archives an invaluable font of information and I appreciate your contributions. [Some of my/yours stuff snipped for brevity] > It's a concept thing. A PIC is a cheap device to "do things". It is > intended to reduce designs to the absolute minimum of parts. Using an > IC to pre-process data *for* the PIC is very much against the grain if > the PIC can do it for itself, and switch de-bouncing is a perfect > example. > > I'd go for Andy's proposal. If nothing else (and there is nothing > else), he knows his stuff. My summary: This is my attitude as well. I'd rather do in software what can also be done in hardware and with this concept I'm noodling with, I'd rather keep my chip count low. However, if hardware means significantly more reliability, I'll investigate it. Amen on you guys know your stuff. I'm hardware handicapped. By the way, what do those little colored bands on those resistor thingies mean? (joke, sorry - I felt that some of the barbs tossed about today were directed at people like me). > * Forget switch parameters (exception: it's not a pushbutton but a > sensor e.g.; opto-interrupter, contact on assembly etc.). You can't > physically actuate a pushbutton more than ten times per second and > almost certainly don't want to be able to, so the debounce cycle need be > no shorter than 50mS. So make it 50mS! Agreed. There are no fingers fast enough and I can easily set "rules" for user-supplied switches. As for the switch parameter point of view, it seemed like the obvious thing to do. Well, that is from a business application point of view. You know, stuff things in databases and variables because you can.... I need to work on my PIC frugality - although with a 17-series chip, you can build a house in those things. > This refers to the NAND gate R-S flipflop with a SPDT switch? Care to > elaborate? Yes. Remembered the concept from a class long ago and while it uses a SPDT, I wondered if hardware was a better approach. I'd like to keep all my buttons as SPST NO. You (and Andy) confirmed that software may be the best route. > Cheers, > Paul B. I have an office in Melbourne and Sydney - I realize that your neighborhood is rather large but.... -DO

Justin, thanks for the note... [Justin wrote...] > Paul pretty much summarizes everything in his reply to this. He does a > great job. An understatement. > Most of my applications do something on keypress, then sleep, so I use the > PORTB interrupt. If your PIC is on constantly, polling is the better > solution. I agree with pretty much everything Paul states, except that > using an interrupt is undesirable. Many applications "do something on > keypress", so using a PORTB interrupt to start a debounce timer, and > another interrupt when debounce complete, is a very convenient > method for a > lot of applications. I usually am tight on RAM, so using none at all for > my keypad code (except for hardware flags) is rather convenient. Well, my idea has 2 switch blocks of 4 switches each living on an RS485 bus and each switch block will have it's own PIC. I'm hoping I won't have a RAM problem but, as soon I introduce the slave code, my RAM-bets may be off. This is an automotive idea so I have a constant supply of fluky power. Once the ignition is off, there's no need to keep the PICs hot. [My old message cleared out]