Searching \ for 'Newbie Toggle Switch Woes' 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/index.htm?key=newbie+toggle+switch
Search entire site for: 'Newbie Toggle Switch Woes'.

Truncated match.
PICList Thread
'Newbie Toggle Switch Woes'
1999\04\10@234358 by David Olson

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

1999\04\11@020712 by Quentin

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

1999\04\11@084926 by Howard McGinnis

flavicon
face
At 11:42 PM 4/10/99 -0400, you wrote:
>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.

You don't have the watchdog enabled, do you?

Howard McGinnis
spam_OUThmcginniTakeThisOuTspamdigital.net
Electronic Visions, Inc.
1650 Barrett Drive
Rockledge FL 32955
(407) 632-7530
http://ddi.digital.net/~hmcginni
.....mcginnisKILLspamspam@spam@e-visions.com

1999\04\11@085334 by David Olson

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

1999\04\11@085958 by David Olson
flavicon
face
> Howard wrote...
> At 11:42 PM 4/10/99 -0400, you wrote:
> >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.
>
> You don't have the watchdog enabled, do you?

Yup. I did! Now it works better.

I'm noticing that the switch behavior is inconsistent - I sometimes have to
hold the button down for a bit in order to get it to latch. I'm assuming
that since I've not debounced anything here that there's where my trouble
is.

Anybody have a favorite debouncing scheme?

Thanks Howard!

-DO

1999\04\11@144726 by MEDICINTEKNIK KB

picon face
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 <qscspamKILLspamICON.CO.ZA>
Till: .....PICLISTKILLspamspam.....MITVMA.MIT.EDU <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Datum: den 11 april 1999 08:07
€mne: Re: Newbie Toggle Switch Woes


{Quote hidden}

1999\04\11@212846 by Mail

flavicon
face
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
saverspamspam_OUTpta.lia.net


{Original Message removed}

1999\04\12@121205 by Andy Kunz

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

How hard (what resistance) do you have pin RA.0 tied high?

Is the WDT enabled?

Andy

1999\04\12@121210 by Andy Kunz

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

1999\04\12@124209 by Andy David

flavicon
face
> >Anybody have a favorite debouncing scheme?

       I like the vertical counters scheme that Scott Dattalo describes
       at
www.interstice.com/~sdattalo/technical/software/pic/debounce.html
       it very efficiently handles multiple switches and, as usual, Scott
       provides a very well written example.




- Andy.

----------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham.
@spam@akdavidKILLspamspamUltronics.co.uk          http://www.ultronics.com/
----------------------------------------------------------

1999\04\12@124221 by Gerhard Fiedler

picon face
At 12:00 04/12/99 -0400, Andy Kunz wrote:
>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.

wouldn't it be enough to have two samples, separated by a time longer than
the max. switch bounce? anybody knows how long such a bounce time can get?

ge

1999\04\12@132924 by David Olson

flavicon
face
I'm not near my schematic right now but, I believe it's a 4.7k resistor.
Again, the PICDEM may not be the best playground, though I'd like to sort
out some of these "nuances" or "nuisances" before I get involved with
application-specific boards.

I did fix the WDT - that was the culprit with my shutdown.

-DO

> {Original Message removed}

1999\04\12@135021 by David Tait

flavicon
picon face
I have a couple of "Hello World" type button pushing programs
here:

http://www.man.ac.uk/~mbhstdj/files/icsptest.zip

The debounce stuff is not very elegant though (a belt and braces
approach).

David

1999\04\12@141328 by David Olson

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

1999\04\12@150343 by Andy Kunz

flavicon
face
>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?

Limiting the current to conserve power, yes (especially when the key is
pressed).

The reason I asked is because a high value resistor would allow the thing
to pick up on noise easier.  A lower value keeps the noise threshold down
by having so much more current flowing all the time.

Andy

1999\04\12@154941 by Justin Crooks

flavicon
face
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 <KILLspammtdesignKILLspamspamFAST.NET>
> To: RemoveMEPICLISTTakeThisOuTspamMITVMA.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

1999\04\12@160448 by Gerhard Fiedler

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

1999\04\12@180846 by paulb

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

1999\04\13@125729 by David Olson

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

1999\04\13@185623 by paulb

flavicon
face
Hello David, list (was going to make this private but maybe...)

David Olson <spamBeGonedolsonspamBeGonespamPROGRESS.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.

1999\04\13@193229 by Justin Crooks

flavicon
face
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 <TakeThisOuTdolsonEraseMEspamspam_OUTPROGRESS.COM>
> To: RemoveMEPICLISTspamTakeThisOuTMITVMA.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

1999\04\13@194516 by David Olson

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

1999\04\13@195102 by David Olson

flavicon
face
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]

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