Searching \ for 'Button Pressing Behavior' 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=button+pressing
Search entire site for: 'Button Pressing Behavior'.

Truncated match.
PICList Thread
'Button Pressing Behavior'
1999\05\08@214605 by David Olson

flavicon
face
Friends,

I've got a routine that polls a switch and turns an LED on or off. I solved
some of my earlier problems (subject: [OT] Newbie Toggle Woes...) by adding
a debouncing scheme. I'm using the Kunz (1999) method of TMR0 and checking
three times. Works great.

However, if I hold the button down (RA1 is high), I get a flashing LED
(RB1) - because it's toggling on and off.

I've been staring at this thing for a few hours (trying stuff) and I can't
seem to come up with a way to recognize if the switch is being held down. I
am using a file register for the switch for status bits (and other future
information), so I could probably set some more checking bits.

The way I want it to behave is after it's debounced, and set on or off, stop
checking until RA1 is low. I can't seem to figure out where to do this (I
think the answer is in there). Almost like I need a "while" loop.

I'm bummed. Trying to translate my higher-level language skills to ASM is a
challenge. It would be cool if Tony Nixon would add a module in PinNPoke
that is "What you did there works like this here" or "You're not in Kansas
anymore".

Also, I'm dying for a subroutine that I can pass parameters. This whole
switch routine has to work for 4 switches. I'm thinking that if I throw the
switch information in a "generic" register, I'll get what I want.

Any clues? Not looking for code - just looking for a nudge to "discover" the
best way.

TIA

-DO

1999\05\08@220854 by Wagner Lipnharski

picon face
Just to use the opportunity:
An easy way to have a key and a indicator led connected to a single
microcontroller port pin is connect the LED (anode) with a resistor (330
Ohms) to +VCC (+5Vdc) and the catode to the port pin, the key goes to
the same port pin to ground via another resistor (100 Ohms).  By this
way, whenever you want to read the key, just flip the port pin to up
level and read it.  The LED can serve as an indicator of the function
selected by the key.  Suppose the LED is off (port pin high), pressing
the key will turn on the LED (3/4 brighness) and will drop the port pin
level, reading the port pin would indicate a low level, so it would
means "key pressed", then your software will "latch" that information
flipping the port pin to low level (LED goes to 100% brightness)
indicating key was read as "pressed".  A 49ms low level and 1ms high
level to read the key is enough to keep the LED as brigh as possible and
run the debounce routine.  After the debounce, pressing the key again
would signal the software to deactivate the LED.  It would works as a
flip-flop switch with indicator, with a single port pin.  The 100 Ohms
resistor (that creates the 3/4 LED intensity) is to inform you when the
software effectivelly read the key pressed and confirmed the "pressed"
status by bypassing the 100 Ohms resistor to ground.

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\05\10@081511 by Caisson

flavicon
face
> Van: David Olson <spam_OUTdolsonTakeThisOuTspamPROGRESS.COM>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: Button Pressing Behavior
> Datum: zondag 9 mei 1999 3:45
>
> Friends,

Hello David,

> I've got a routine that polls a switch and turns an LED on or off. I
solved
> some of my earlier problems (subject: [OT] Newbie Toggle Woes...) by
adding
> a debouncing scheme. I'm using the Kunz (1999) method of TMR0 and
checking
> three times. Works great.
>
> However, if I hold the button down (RA1 is high), I get a flashing LED
> (RB1) - because it's toggling on and off.
<Snip>

> Also, I'm dying for a subroutine that I can pass parameters. This whole
> switch routine has to work for 4 switches. I'm thinking that if I throw
the
> switch information in a "generic" register, I'll get what I want.
>
> Any clues? Not looking for code - just looking for a nudge to "discover"
the
> best way.

Pseudo-code:

 1) Set a Loop-counter to some preset value.
 2) Poll the input-port your switch(es) are connected to.
 Mask off all port-bits that do not have a (required) switch attached.
(Your "argument" !)
 Check if the result is the same as last time.  If not,  goto 1)
 Decrement Loop-counter.  If not Zero goto 2)
     (if it is, the key is stable for {preset value} scan's !)

Resulting byte contains a One on places where a switch is connected, but
not pressed, and a Zero on all other places.

To check for a Key-press :
 call this routine and test for pressed key's (Zero-bits) in the returned
byte

To wait for Key-release :
 call this routine and repeat (calling the routine) if any key is pressed

I'm using this setup in several devices, and it works like a charm.

For your program:

 Check for a Key-Press
 if so :  Toggle the Led & wait for Key-Release
 repeat from top

Greetz,
 Rudy Wieser

1999\05\10@085719 by paulb

flavicon
face
David Olson wrote:

> However, if I hold the button down (RA1 is high), I get a flashing LED
> (RB1) - because it's toggling on and off.

 (Rubs hands together - figuratively!)  Oooh!  The Debounce algorithm!

 Four switches eh?  OK, match them with four bits in a register which
we call "previous", and a 4-bit variable called "count".  It should be
fairly obvious that one byte can be used for both.

 You examine the switches and pass through the algorithm every two
milliseconds or so.  The rest of the time you go do something else, you
do *not* wait in the routine.

 On each pass, you note whether all of the switches match "previous"
(XOR).  If they do, you set "count" to $F.  If they do not, you
decrement "count".

 If in doing so, "count" becomes zero, then you examine the switches,
one at a time, to see which does not match "previous".

 The first one that does *not* match previous has the corresponding bit
in "previous" set to match the current state of the switch, the *action*
corresponding to this switch being actuated or released is performed
accordingly, and "count" is incremented (back to 1) (or may be reset to
$F).

 Depending on how you wish your timing loop to perform, you may at this
point proceed to your "other" task for a further 2 ms, or loop back and
find any other switch that does not match "previous".  In either case,
if there was only one switch changed (and most of the time, there will
only be one), the next iteration finds the switches match "previous",
and "count" is reset to $F.

 Is this clear enough?
--
 Cheers,
       Paul B.

1999\05\10@092401 by Tjaart van der Walt

flavicon
face
"Paul B. Webster VK2BZC" wrote:

>   Four switches eh?  OK, match them with four bits in a register which
> we call "previous", and a 4-bit variable called "count".  It should be
> fairly obvious that one byte can be used for both.
>
>   Depending on how you wish your timing loop to perform, you may at this
> point proceed to your "other" task for a further 2 ms, or loop back and
> find any other switch that does not match "previous".  In either case,
> if there was only one switch changed (and most of the time, there will
> only be one), the next iteration finds the switches match "previous",
> and "count" is reset to $F.
>
>   Is this clear enough?

Very. A nice variation would be to sample slightly slower, to
check the counter before you reset it to $F, and also check if
"new" is the default state. Now you can react differently to "long"
keypresses than "short" ones.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
tjaartspamKILLspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : .....tjaartKILLspamspam.....sms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\10@100045 by David Olson

flavicon
face
Thanks for all that replied. I'll give it a go. It's great to get a variety
of responses - sort of ala carte.

I promise that this will be my last button-based post. I'll move on to
something more creative next time.

-DO

1999\05\10@130146 by Dwayne Reid

flavicon
face
Wagner Lipnharski suggested:

>Just to use the opportunity:
>An easy way to have a key and a indicator led connected to a single
>microcontroller port pin is connect the LED (anode) with a resistor (330
>Ohms) to +VCC (+5Vdc) and the catode to the port pin, the key goes to
>the same port pin to ground via another resistor (100 Ohms).

<big snip>

This has a potentially fatal flaw - the LED resistor and the switch resistor
form a voltage divider which means that the 'switch pressed' voltage at the
pin drops to about 1 Vdc instead of 0 Vdc.

The soloution is simple - put both resistors in series, with the mid point
of the resistors going to the switch.

dwayne


Dwayne Reid   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\05\10@183954 by James Cameron

flavicon
face
Wagner,

I tried this on a recent Technical Aid to the Disabled project, but I
had some problems with EMF noise triggering.  Even though there is a LED
there to Vcc, the input line is effectively floating when not driven
either way.  It can jump up to the trigger voltage of the PIC input
before the LED activates and begins to draw current.

Adding a resistor to ground of about 10k fixed the problem.

--
James Cameron                                    (cameronspamspam_OUTus.netrek.org)

OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.

1999\05\10@191302 by paulb

flavicon
face
James Cameron wrote:

> Even though there is a LED there to Vcc, the input line is effectively
> floating when not driven either way.

 I thought about that.  Obviously you need *another* resistor, 47k or
so, across the LED or LED/ resistor combination.  Or a soft pull-up.
--
 Cheers,
       Paul B.

1999\05\11@060946 by Caisson

flavicon
face
> Van: James Cameron <@spam@quozlKILLspamspamUS.NETREK.ORG>
> Aan: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Onderwerp: Re: Button Pressing Behavior
> Datum: dinsdag 11 mei 1999 0:37
>
> Wagner,
>
> I tried this on a recent Technical Aid to the Disabled project, but I
> had some problems with EMF noise triggering.  Even though there is a LED
> there to Vcc, the input line is effectively floating when not driven
> either way.  It can jump up to the trigger voltage of the PIC input
> before the LED activates and begins to draw current.

Yes, that was one of the things I found out some time ago too.  The reason
behind this is that a LED behaves as a sort of a Zener-diode.  When it's
off no electrical connection seems to exist between the two legs of the
LED.  So, you can't use a LED in a circuit that should function as a
Pull-up.  The way to go is to place a Pull-up (or down) resistor parallel
to the LED (& series resistor), as you did/found out.

Greetz,
 Rudy Wieser

1999\05\11@102830 by David Olson

flavicon
face
One of the nice things that this approach gives me is some port
conservatism. However, since this design will sit on an RS-485 bus I think
I'm better off with a 16C72, which would give me the chance to fire up the
LED's on their own port. Then again, if I'm up to the task of the comms in
software, I could go with a 509 and use this method. A board with a MAX48x
and a 509 would make a nice small package (haven't looked at the port
possibilities yet). I'm trying to make this as small as possible.

-DO

[Everybody's replied - here's the latest]

{Quote hidden}

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