Searching \ for '[PIC] Comments on keypad design?' 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: 'Comments on keypad design?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Comments on keypad design?'
2005\12\27@103455 by Josh Koffman

face picon face
Hi all. In my current project I'm going to be using a large keypad -
something around 64 switches most likely. I'm looking for advice on
the best way to handle this. I've had a few ideas, though there are
some qualifications I should talk about first. The main one is
multiple keypresses. Not only does my device need to detect and handle
multiple keypresses, but it may have to deal with chaining as well
(press A, press B, release A, press C). I might be able to get away
without chaining if it's too much hassle.

On the software side, I'm looking at setting up 8 status registers,
then having a bit set when a key is successfully detected and
debounced. When it comes time to perform an action based on the keys,
a simple movf keystat1, f will then let me check the Z bit to see if
anything has changed. If it has, I can then do an individual bit
check. In fact, I might also setup a global "something has changed"
register. Each bit will represent one of the 8 status registers. Then
I can zero check that global register, then figure out exactly which
registers have changed...hmmm...

Anyway, here are some ideas I've had:

8x8 matrix. This would likely be the least hardware intensive method.
The downside is that handling all the scanning and debouncing states
might be a bit intensive. I suppose I could simplify it by just
treating it like 4 independant 4x4 matricies. I've never done a matrix
this large, it's a bit daunting.

Massive shift register. It would be easy to shift in 64 bits.
Debouncing might be an issue though. At the very least this might
simplify some of the board layout. Undecided on this one.

Slave PIC button processors. Using a couple of lower 40 pin PICs, I
could make a couple of button processing engines. An advantage to this
is that every button gets its own I/O line. The slave handles all the
debouncing, and just responds to the master's request for new buttons
pressed. Downside is that I'm now developing for more than one
processor and the chance of problems goes up.

Alright...that's it for now. All comments appreciated! Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\27@113654 by Wouter van Ooijen

face picon face
> 8x8 matrix. This would likely be the least hardware intensive method.
> The downside is that handling all the scanning and debouncing states
> might be a bit intensive. I suppose I could simplify it by just
> treating it like 4 independant 4x4 matricies. I've never done a matrix
> this large, it's a bit daunting.
>
> Massive shift register. It would be easy to shift in 64 bits.
> Debouncing might be an issue though. At the very least this might
> simplify some of the board layout. Undecided on this one.

For ease of programming a SR chain seems top for me. You might want to
look at SRs that have a delayed output, to avoid clock skew problems.
You will need a pull-up for each switch. But an 8x8 matrix is only a
little bit more work. But you will need a diode on each switch to be
able to detect multiple key presses correctly.

For debouncing: just take care that you scan slower than the longest
devounce time (50ms is a good upper limit if the switches do not
document this). So with a 20 Hz scan frequency you can forget about
bouncing.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\27@113726 by Mchipguru

picon face
You might try resistor networks with A/D converter to sense button presses in a polled manner. I have dons small numbers of keys with this and it does lend itself to chording as well as chaining and has an added bennifit of debounce due to the speed of the A/D conversion. You will have to break the keys into groupings as the resolution becomes a factor but with muxed A/D converters on several pics this may be an alternative.
Larry Nelson Sr

{Quote hidden}

> --

2005\12\27@121936 by Josh Koffman

face picon face
On 12/27/05, mchipguruspamKILLspamcharter.net <.....mchipguruKILLspamspam.....charter.net> wrote:
> You might try resistor networks with A/D converter to sense button presses in a polled manner. I have dons small numbers of keys with this and it does lend itself to chording as well as chaining and has an added bennifit of debounce due to the speed of the A/D conversion. You will have to break the keys into groupings as the resolution becomes a factor but with muxed A/D converters on several pics this may be an alternative.

My concern with this idea is that I will need to do a bunch of greater
than/less than matching due to drift, right? That, combined with the
ADC timing might make it rather slow and intensive.  some of the
buttons will have to be detected and acted upon with very little
perceived delay. Or am I wrong?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\27@123512 by Josh Koffman

face picon face
On 12/27/05, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
> For ease of programming a SR chain seems top for me. You might want to
> look at SRs that have a delayed output, to avoid clock skew problems.
> You will need a pull-up for each switch. But an 8x8 matrix is only a
> little bit more work. But you will need a diode on each switch to be
> able to detect multiple key presses correctly.

Ok, I'll admit it, I never really understood the need for diodes. If
I'm controlling the scan, how do they help? Assume that I'm driving
columns and reading rows. If I drive column A, then read in all the
rows, I know that any high line must be from a column A key, right?
Maybe I'm just not visualizing the schematic correctly in my head.
I've tried googling around, but I can't seem to come up with an
example. Help?

> For debouncing: just take care that you scan slower than the longest
> devounce time (50ms is a good upper limit if the switches do not
> document this). So with a 20 Hz scan frequency you can forget about
> bouncing.

Doesn't this assume that the keypresses will always happen directly
after a scan, so by the time the next scan rolls around it's stopped
bouncing? I guess having a low scan rate does ensure that even if a
key is bouncing over one scan, by the time the next scan rolls around
it's finished bouncing. I currently have a 400Hz interrupt handling my
encoders, I was going to add a debounce routine in there. If I can
just ditch the debounce though, it'll save me processor time.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\27@125700 by David VanHorn

picon face
>
>
> 8x8 matrix. This would likely be the least hardware intensive method.
> The downside is that handling all the scanning and debouncing states
> might be a bit intensive. I suppose I could simplify it by just
> treating it like 4 independant 4x4 matricies. I've never done a matrix
> this large, it's a bit daunting.


Why do you feel debounicng is an issue?

Simple debounce algorithm:

Once per N millisec:
Read in the switches.
compare new switch state to old switch state
If different,
  store new switch state in old switch state
  load X in switch timer  ;restarts debounce counter
  exit
If not different
 decrement switch timer
 If switch timer = 0  ;Switches have stopped bouncing
   then store new switch state to switch status
   signal application to read switch status.
   exit
 Else
 exit

X * N = switch debounce time.

Personally, I've not seen any problem with switch bouncing when scanned in a
time frame of around 10 mS, but your switches may vary.  I'd add hardware
filtering to prevent electrical noise and such.

In your application, that's 8 bytes for switch status (output)  and a bit
for a "Hey read the switches" flag, plus 8 bytes for old switch state.  You
might add another 8 for new switch, or you could just read that off the
switches and save those bytes.

2005\12\27@130441 by olin piclist

face picon face
Josh Koffman wrote:
> Ok, I'll admit it, I never really understood the need for diodes.

Imagine on your 8x8 keypad that 3 of 4 buttons at the corner of a rectangle
are pressed (closed).  Now, can you determine whether the fourth button is
closed or not?  Work it out.  This is just one small example of the problem,
which you will probably see when you work it out.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\27@131221 by Wouter van Ooijen

face picon face
> Ok, I'll admit it, I never really understood the need for diodes. If
> I'm controlling the scan, how do they help? Assume that I'm driving
> columns and reading rows. If I drive column A, then read in all the
> rows, I know that any high line must be from a column A key, right?

Take a chessboard, the scan is pulling the letters-side selectively low
(first A, then B, etc), you read the numbers-side, with pull-ups. Now
press keys A1, B1, B2. Pulling A low will pull 1 low dircetly, but also
2 (via A1, B1, B2). Now you can't detect whether A2 is pressed or not.
When diodes are used the one at B1 would prevent this.

> > For debouncing: just take care that you scan slower than the longest
> > devounce time (50ms is a good upper limit if the switches do not
> > document this). So with a 20 Hz scan frequency you can forget about
> > bouncing.
>
> Doesn't this assume that the keypresses will always happen directly
> after a scan,

No, but it assumes that bouncing takes at most one scan interval. Think
like this: the scan before the counce will read 'not pressed', the one
after it will read 'pressed'. There can be at most one during the
bounce, which will read either 'pressed' or 'not pressed', but who
cares?


Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\27@131720 by Harold Hallikainen

face picon face
Just last week I saw an ad for a keyboard controller chip that had an SPI
interface. I THINK it was Maxim, but I can't find the ad now, nor can I
find it on their website. Anyway, if you can find it, that's another
possibility.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\12\27@135501 by Mchipguru

picon face
I coded things in assy and did not have problems but it was a user interface on a radar detector and again on a speedometer / tachometer system. when the A/D conversion was complete the code checked for a button press (voltage drop) then did comparisons based on voltage measurement with fairly wide tolerences (5 buttons, 8 bit conversion). The A/D ran in the background and the "state machine" ran the button routine when the A/D done flag was there from the main loop. Fast for a user interface does not need to be fast as far as processor capabilities are concerned. The processor ended running a 20 mhz crystal because of some more critical timing issues.
Larry
{Quote hidden}

> --

2005\12\27@145928 by Harold Hallikainen

face picon face

> I coded things in assy and did not have problems but it was a user
> interface on a radar detector and again on a speedometer / tachometer
> system. when the A/D conversion was complete the code checked for a button
> press (voltage drop) then did comparisons based on voltage measurement
> with fairly wide tolerences (5 buttons, 8 bit conversion). The A/D ran in
> the background and the "state machine" ran the button routine when the A/D
> done flag was there from the main loop. Fast for a user interface does not
> need to be fast as far as processor capabilities are concerned. The
> processor ended running a 20 mhz crystal because of some more critical
> timing issues.
> Larry


I did this in a 15 button system. I used SIP resistor networks for the
voltage divider to get pretty good tempco matching. The pushbuttons just
selected off the divider and drove the A/D input. I used SPDT switches
"looping through" the unselected switches to avoid problems when multiple
buttons were down. This also gave a priority order to the switches.

The asm code was pretty simple. I put the ADC value in w, then added the
negative of a half step of the voltage divider. If the result was
negative, the input voltage was zero. I then successively added negative
"full steps" to w, checking for a negative result on each, and branching
to the appropriate code.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\12\27@153911 by Peter Todd

picon face
On Tue, Dec 27, 2005 at 12:56:59PM -0500, David VanHorn wrote:
> >
> >
> > 8x8 matrix. This would likely be the least hardware intensive method.
> > The downside is that handling all the scanning and debouncing states
> > might be a bit intensive. I suppose I could simplify it by just
> > treating it like 4 independant 4x4 matricies. I've never done a matrix
> > this large, it's a bit daunting.
>
>
> Why do you feel debounicng is an issue?
>
> Simple debounce algorithm:

<snip>

Here's another one that I often use. It's even simpler, though at the
cost of configurability.

bool old[x,y];
bool new[x,y];
bool cur[x,y] is the actual hardware inputs

for each x-y
       if current != new
               new = current;
       if current == new
               old = current;
               potentially do a triggered action, if old != current

Finally make sure this routine happens no more often then say twice the
maximum frequency of bounces.

The way this works is by "propegating" the values from current, to new,
then finally to old. A value is never transferred to old until it's been
read with the same value twice, once to store it in new, and again to
store it in old.

This is the method I tend to use in my PIC applications, it's very
simple and only needs two bits for each switch being monitored.

--
spamBeGonepetespamBeGonespampetertodd.ca http://www.petertodd.ca

2005\12\27@171643 by William Chops Westfield

face picon face
On Dec 27, 2005, at 7:34 AM, Josh Koffman wrote:

> I'm going to be using a large keypad -
> something around 64 switches most likely.

You don't say what the application is, but somewhere around that
size I stop thinking about keypads and start thinking of traditional
computer keyboards or touch screens...  It used to be that custom
keypads were preferred over keyboards because a large segment of the
population would be unable to type, but I think those days are long
past; especially in any technical community...

BillW

2005\12\27@195334 by Jinx

face picon face


> Just last week I saw an ad for a keyboard controller chip

The problem with all the k/b controllers I've seen Harold is that
they don't do complex functions, like multiple keys down. The
obsoleted SAA3000 range from Philips for example could have
several 8x8 keypads attached, each of which were selectable with
a further 7 keys, giving you SHIFT/Alt/Ctrl-like functions but it
couldn't handle more-than-one-key-down in the invidual 8x8s


2005\12\27@195537 by Josh Koffman

face picon face
On 12/27/05, William Chops Westfield <TakeThisOuTwestfwEraseMEspamspam_OUTmac.com> wrote:
> You don't say what the application is, but somewhere around that
> size I stop thinking about keypads and start thinking of traditional
> computer keyboards or touch screens...  It used to be that custom
> keypads were preferred over keyboards because a large segment of the
> population would be unable to type, but I think those days are long
> past; especially in any technical community...

Actually...I'm making a keyboard. There's a software application I use
that emulates a real piece of gear. The buttons on the on screen
application are mapped to actual keyboard presses (though some are
rather ridiculous ie @' (note the ')). As an introduction to USB, I'm
making a control panel that mimics the real device, but connects up to
my computer and controls the virtual device via USB.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\27@200020 by Josh Koffman

face picon face
On 12/27/05, Wouter van Ooijen <RemoveMEwouterspamTakeThisOuTvoti.nl> wrote:
> Take a chessboard, the scan is pulling the letters-side selectively low
> (first A, then B, etc), you read the numbers-side, with pull-ups. Now
> press keys A1, B1, B2. Pulling A low will pull 1 low dircetly, but also
> 2 (via A1, B1, B2). Now you can't detect whether A2 is pressed or not.
> When diodes are used the one at B1 would prevent this.

Alright, thanks to Olin and Wouter, I think I finally understand this.
I guess I thought the diode bypassed the switch somehow...that's why I
was asking for an example schematic. Just to make sure I haven't
screwed things up in my head, the diode should be in series with the
switch, right? ASCII art:

                                      Col 1
                                       |
             -----|<-----*SW*-----+
Row 1 ----+-------------------------------------------To more switches
Row 2 ----  etc
Row 3 ----

Now that I think of it, if I have the rows pulled up, and then I drive
the column low, the diode will need to be in the other direction,
correct?

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\27@221612 by Kevin

picon face
> On Tue, Dec 27, 2005 at 12:56:59PM -0500, David VanHorn wrote:
> > >
> > >
> > > 8x8 matrix. This would likely be the least hardware intensive method.
> > > The downside is that handling all the scanning and debouncing states
> > > might be a bit intensive. I suppose I could simplify it by just
> > > treating it like 4 independant 4x4 matricies. I've never done a matrix
> > > this large, it's a bit daunting.
> >
> >
Don't forget to check out
www.piclist.com/techref/microchip/picboard.htm
The source code is a pretty good tutorial
www.piclist.com/techref/microchip/picboardasm.htm
Not sure it is completely what you are looking for, but
definately worth a read.

~Kevin

2005\12\27@222812 by Josh Koffman

face picon face
On 12/27/05, Kevin <kbenEraseMEspam.....dca.net> wrote:
> Don't forget to check out
> www.piclist.com/techref/microchip/picboard.htm
> The source code is a pretty good tutorial
> www.piclist.com/techref/microchip/picboardasm.htm
> Not sure it is completely what you are looking for, but
> definately worth a read.

Thanks for the tip - it's not quite what I want though. I started
thinking about a similar project a few years ago, and I was going to
use Tony's stuff as an example. However, times have changed and my new
laptops don't have PS/2 ports anymore. I know I could use a USB-PS/2
convertor, but I really need to learn some USB skills anyway.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\28@014924 by rosoftwarecontrol

flavicon
face
using touch screen, you will not need 64 key.

64 keys, worth touch screen


----- Original Message -----
From: "Josh Koffman" <EraseMEjoshybearspamgmail.com>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistEraseMEspamEraseMEmit.edu>
Sent: Tuesday, December 27, 2005 10:34 AM
Subject: [PIC] Comments on keypad design?


{Quote hidden}

> --

2005\12\31@085554 by Bill & Pookie

picon face
Debounce everything, even software switches.  Especially mechanical
switches.

Bill

Just kidding about software switches, but some times I wonder????

{Original Message removed}

2005\12\31@121130 by Bob Blick

face picon face
On 31 Dec 2005 at 5:55, Bill & Pookie wrote:
> Debounce everything, even software switches.  Especially mechanical
> switches.

There's no need to debounce switches unless you poll them faster
than the bounce time. And the only reason you'd need to poll them
that fast is if you need low latency, like with a trigger. I generally poll
20 times per second and that works just fine.

Cheers,

Bob

2005\12\31@122136 by olin piclist

face picon face
Bob Blick wrote:
> There's no need to debounce switches unless you poll them faster
> than the bounce time. And the only reason you'd need to poll them
> that fast is if you need low latency, like with a trigger. I
> generally poll 20 times per second and that works just fine.

This is fine if you're only worried about bouncing on transitions.  If you
are doing filtering or the switch could bounce in one of the states (like a
momentary pushbutton), then you need to sample faster and apply debouncing
or filtering logic.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\31@132007 by Wouter van Ooijen

face picon face
> > There's no need to debounce switches unless you poll them faster
> > than the bounce time. And the only reason you'd need to poll them
> > that fast is if you need low latency, like with a trigger. I
> > generally poll 20 times per second and that works just fine.
>
> This is fine if you're only worried about bouncing on
> transitions.  If you
> are doing filtering or the switch could bounce in one of the
> states (like a
> momentary pushbutton), then you need to sample faster and
> apply debouncing
> or filtering logic.

This is new to me. You say a pushbutton (lika an ordinary keyboard key)
could bounce *while being pressed down*? And if so, how would you
recognise such a bounce?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\31@134920 by Shawn Wilton

picon face
Best article I've ever read about Debouncing, and it has the best algorithm
I've ever seen as well.

http://ganssle.com/debouncing.pdf


On 12/31/05, Wouter van Ooijen <RemoveMEwouterspam_OUTspamKILLspamvoti.nl> wrote:
{Quote hidden}

> -

2005\12\31@141023 by Mike Singer

picon face
Josh Koffman wrote:> Hi all. In my current project I'm going to be using a large keypad -> something around 64 switches most likely. I'm looking for advice on> the best way to handle this.
Josh,
Why not develop the concept of a PIC10FXXX button: a separate unit oftwo buttons and PIC10FXXX software emulating SPI or I2C. Each suchunit should have its own bus address.
It would cost a buck or so for two buttons. This would give youextremely flexible and expandable system: just add a button "as yougo". You can place a button wherever you like.
The family devices would be "one button – one lamp" and "two lamps".I bet, the PCB for dozen such devices, buttons and preprogrammed PICswould sell well over PICList.

Best Wishes,Mike.

2005\12\31@142710 by Peter

picon face

On Sat, 31 Dec 2005, Bill & Pookie wrote:

> Debounce everything, even software switches.  Especially mechanical switches.
>
> Bill
>
> Just kidding about software switches, but some times I wonder????

I think it's called 'locking'. As in atomic access. VERY necessary.

Peter

2005\12\31@144348 by Wouter van Ooijen

face picon face
> Best article I've ever read about Debouncing, and it has the
> best algorithm I've ever seen as well.
> http://ganssle.com/debouncing.pdf

How is it better than just check every 50 ms?

{Quote hidden}

The ganssle document is nice, but it does not mention down-state
bouncing.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\31@145440 by Herbert Graf

flavicon
face
On Sat, 2005-12-31 at 19:20 +0100, Wouter van Ooijen wrote:
> > > There's no need to debounce switches unless you poll them faster
> > > than the bounce time. And the only reason you'd need to poll them
> > > that fast is if you need low latency, like with a trigger. I
> > > generally poll 20 times per second and that works just fine.
> >
> > This is fine if you're only worried about bouncing on
> > transitions.  If you
> > are doing filtering or the switch could bounce in one of the
> > states (like a
> > momentary pushbutton), then you need to sample faster and
> > apply debouncing
> > or filtering logic.
>
> This is new to me. You say a pushbutton (lika an ordinary keyboard key)
> could bounce *while being pressed down*? And if so, how would you
> recognise such a bounce?

Olin is correct.

While I've never seem "membrane" type switches bounce while pressed
(that's not to say they don't, just that I've never seen it), normal
more mechanical type switches can bounce while depressed, especially
when they're a little dirty or corroded.

By "more mechanical" I mean those cheap push button switches that are
basically just two pieces of spring metal coming together. As the button
is pressed, movements in the button back and forth (no person can hold
100% still) move the two pieces of metal back a forth, causing a
possible bounce.

Personally I always debounce. Whether it's software or hardware
debouncing (or both) depends on what I've got.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\12\31@145518 by Shawn Wilton

picon face
There's a real easy test for down-state bouncing.

What's nice about that algorithm is that it will only trigger once.  I've
used it in many projects and it never misses a key press, never triggers
more than once, and best of all, doesn't require any timers (h/w or s/w).
It just loops through, and after it pushes the 1 through, you get your key
press.

On 12/31/05, Wouter van Ooijen <RemoveMEwouterTakeThisOuTspamspamvoti.nl> wrote:
{Quote hidden}

> -

2005\12\31@160725 by Jinx

face picon face
> > This is new to me. You say a pushbutton (lika an ordinary
> > keyboard key) could bounce *while being pressed down*?
> > And if so, how would you recognise such a bounce?

> I mean those cheap push button switches that are basically just
> two pieces of spring metal coming together

Little tact switches can be very noisy when they get dirty, or just
not work at all. I've got a couple that need replacing on a unit I
made few years ago. Tried meths and CRC down them but they
refuse to clean. The actuator has to be pushed at an angle to
make a contact. As tact switches are (supposed to be) self-
cleaning, it's the ones that don't get used a lot that "fail" first

Ideally you'd always choose good quality components, but I'm
guessing the tact switch market is pretty cut-throat (with all that
implies). And often a tact switch might be the only convenient
solution size-wise

Whenever possible I use RC filtering on the switch lines to remove
noise, then use a debounce delay and/or a release detect. If you
don't try to clean up the signal externally it means more work for
the s/w, which somebody has to write. Particularly in a case like
Josh's, where you've got 8x8 and a lot of scanning to do. And
being a matrix, RC might be tricky to implement for multiple keys

If I were able to, I'd use non-bouncing switches - eg optical or
membrane - rather than tact

2005\12\31@173849 by olin piclist

face picon face
Wouter van Ooijen wrote:
> This is new to me. You say a pushbutton (lika an ordinary keyboard
> key) could bounce *while being pressed down*?

Yes, depending on how the switch is constructed.  If the pushbutton directly
activates the switch closure, then wiggling it can cause noise or bounce.

> And if so, how would you recognise such a bounce?

By it being much shorter time than a real release and press.  I usually
figure a human can't do much of anything in less than 50mS and use that as
my debounce time.  The kind of noise I'm talking about could be higher
resistance or complete open for microseconds, usually not milliseconds,
certainly not 50mS.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\31@181028 by David VanHorn

picon face
I hit an interesting sort of "bounce" while working with Litton glass break
sensors years ago..

The symptom was that the sensors would randomly trip for no apparent reason.
When you'd arrive and check resistances, everything would be fine.

The sensors were gold plated rings sitting on gold plated pins in a sealed
cavity.  Through many hours of work, we would isolate a defective sensor,
send it back, and they would report that it was just fine.

After much frustration, I decided to sit and watch one system till it
tripped. I was scoping the voltage across the loop, which would increase
with increasing loop resistance.  This took several days of constantly
watching the scope, but it finally happened.  The voltage would rise up in a
very erratic fashion, and then fall back down, more or less at random, till
the slightest vibration happened, then everything would go back to quiet.

This brought me to understand a little-known property of mechanical
switches, called "wetting current".  This is the minimum current required
for the switch to actually be closed.   When I found out about this, I
increased the loop current used in the system from about 2mA to about 20mA
and the problem dissapeared.    This mod was reported back to Litton, and
incorporated into the design of the control interface, apparently we weren't
the only ones having problems.

The switches we sent back weren't exactly defective, but they had slightly
higher values of actual wetting current than normal. The act of removin them
from the system, and the pounding of shipping erased any evidence that might
have been present.

Ain't hardware fun?

2005\12\31@192817 by Russell McMahon

face
flavicon
face
> This brought me to understand a little-known property of mechanical
> switches, called "wetting current".  This is the minimum current
> required
> for the switch to actually be closed.   When I found out about this,
> I
> increased the loop current used in the system from about 2mA to
> about 20mA
> and the problem dissapeared.    This mod was reported back to
> Litton, and
> incorporated into the design of the control interface, apparently we
> weren't
> the only ones having problems.

AFAIR (possibly wrongly) Gold has a *higher* wetting current
requirement than some other less expensive contact materials.


       Russell McMahon

2005\12\31@193515 by David VanHorn

picon face
>
> AFAIR (possibly wrongly) Gold has a *higher* wetting current
> requirement than some other less expensive contact materials.


Could be.  It was a fun problem to track down.  Me and my NLS-215 scope
against Litton Corp. :)

2005\12\31@200714 by Bob Axtell

face picon face
David VanHorn wrote:

>>AFAIR (possibly wrongly) Gold has a *higher* wetting current
>>requirement than some other less expensive contact materials.
>>    
>>
>
>
>Could be.  It was a fun problem to track down.  Me and my NLS-215 scope
>against Litton Corp. :)
>  
>
Don't be surprised. Big companies are made up of folks just like you,
using tools just
like you do.They make mistakes too, but there is a door down the hall
with lawyers in it
to help them cover it up.

In my career, I have embarassed several big companies. It was worth the
effort. It really
was. But I also saved a few companies from being defrauded, using the
same kind of
analysis.

If your engineering analysis is sound, based on universal principles,
and you have the
facts straight, your idea will suceed. Just like day follows night.

--Bob

--
Note: To protect our network,
attachments must be sent to
EraseMEattachspamspamspamBeGoneengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2005\12\31@201851 by Spehro Pefhany

picon face
At 06:10 PM 12/31/2005 -0500, you wrote:


>The switches we sent back weren't exactly defective, but they had slightly
>higher values of actual wetting current than normal. The act of removin them
>from the system, and the pounding of shipping erased any evidence that might
>have been present.
>
>Ain't hardware fun?

Yup. That's why relays & switches often have *minimum* current ratings on the
contacts.

Interesting that it showed up at a current as high as 2mA, but I suppose
the contact pressure was very slight in a breakage sensor. What was the
approximate voltage on the contact, Dave?

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com




2005\12\31@205437 by Bob Blick

face picon face
On 31 Dec 2005 at 12:21, Olin Lathrop wrote:

> Bob Blick wrote:
> > There's no need to debounce switches unless you poll them faster
> > than the bounce time. And the only reason you'd need to poll them
> > that fast is if you need low latency, like with a trigger. I
> > generally poll 20 times per second and that works just fine.
>
> This is fine if you're only worried about bouncing on transitions.  If you
> are doing filtering or the switch could bounce in one of the states (like a
> momentary pushbutton), then you need to sample faster and apply debouncing
> or filtering logic.


Hi Olin,

You're going to have to back that up with details or we'll all just
decide you're blowing smoke (or inhaling it, this is New Year's Eve,
after all :)

Cheerful regards,

Bob

2005\12\31@220234 by David VanHorn

picon face
>
>
> Interesting that it showed up at a current as high as 2mA, but I suppose
> the contact pressure was very slight in a breakage sensor. What was the
> approximate voltage on the contact, Dave?


Gads I don't remember.

The circuit was pretty interesting, they had the alarm loop configured as
one leg of a wheatstone bridge, with a pair of optoisolators across the
center, to kick the logic.   The logic counted a settable number of pulses
within a settable amount of time, and if exceeded, toggled a relay with form
C outputs.


'[PIC] Comments on keypad design?'
2006\01\01@083253 by olin piclist
face picon face
Bob Blick wrote:
>> This is fine if you're only worried about bouncing on transitions.
>> If you are doing filtering or the switch could bounce in one of the
>> states (like a momentary pushbutton), then you need to sample faster
>> and apply debouncing or filtering logic.
>
> You're going to have to back that up with details or we'll all just
> decide you're blowing smoke (or inhaling it, this is New Year's Eve,
> after all :)

Others have already elaborated.  The kind of switches where your finger is
mechanically tied to the contacts that close can have noise or bounce when
the finger is wiggled.  Usually the ones with a solid click feel don't have
this problem or at least a lot less.  On some switches the thing you touch
just trips a mechanical bi-stable assembly one way or the other, and they
don't have this problem.

Try using two wires as a switch holding the wires an inch or so from the
connection point.  Use the "switch" to connect a small speaker to a 5V
supply thru a 200ohm resistor.  You'll hear noise as you rub the wires even
though they are "connected".  Similarly, your inevitable hand movement on
the right type of switch can cause the same effect.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\01@131846 by Peter

picon face

On Sat, 31 Dec 2005, Wouter van Ooijen wrote:

> This is new to me. You say a pushbutton (lika an ordinary keyboard key)
> could bounce *while being pressed down*? And if so, how would you
> recognise such a bounce?

Any switch can have 'noise'. If you have a debouncing routine running
then they key is polled fast and a bounce will register as a key break
that is too short, and will not change the output state. Same for make.

Peter

2006\01\01@132059 by Peter

picon face


On Sat, 31 Dec 2005, Wouter van Ooijen wrote:

> The ganssle document is nice, but it does not mention down-state
> bouncing.

Down state bouncing seldomly occurs with new keys. It happens with
'rubber' keys and oxydized contacts or weak springs.

Peter

2006\01\01@134652 by Mike Singer

picon face
Peter wrote:
> Any switch can have 'noise'. If you have a debouncing routine...

SPDT + Schmit trigger input + 2 resistors may not need software debouncing.
There was a thread some years ago.

Regards,
Mike.

2006\01\01@135232 by Peter

picon face

On Sun, 1 Jan 2006, Russell McMahon wrote:

> AFAIR (possibly wrongly) Gold has a *higher* wetting current requirement than
> some other less expensive contact materials.

No ? Afair gold has the lowest wetting current requirement. Think about
it, it is soft so point contacts are almost impossible, and it does not
oxydize.

Peter

2006\01\01@135420 by Peter

picon face

On Sat, 31 Dec 2005, Bob Axtell wrote:

> If your engineering analysis is sound, based on universal principles,
> and you have the facts straight, your idea will suceed. Just like day
> follows night.

Except it can take long enough for the company to admit the problem, let
alone fix it, that your project is doomed. Been there.

Peter

2006\01\01@180418 by David VanHorn

picon face
>
>
> No ? Afair gold has the lowest wetting current requirement. Think about
> it, it is soft so point contacts are almost impossible, and it does not
> oxydize.


try Mercury.

2006\01\01@180626 by David VanHorn

picon face
>
> Except it can take long enough for the company to admit the problem, let
> alone fix it, that your project is doomed. Been there.


How about a certain major maker of modem chips who shall remain nameless
(ROCKWELL) who decided that they would have their US modem sets answer the
line with a british answer tone, which all their chips would accept, but
most competitors wouldn't.

It was outside the standdard but this certain major maker of modem chips who
shall remain nameless (ROCKWELL) just didn't seem to care.

2006\01\01@221211 by Scott Dattalo

face
flavicon
face
Josh,

There have been several people recommending debouncing algorithms for your
switches. You may wish to consider:

http://www.dattalo.com/technical/software/pic/debounce.html

This routine efficiently filters multiple switches.

I just went back and revisited this code to see if there was a way to make
it better and found three improvements.

First, the old routine (it's been on my web site for ~7 years now) was 13
instructions (excluding the return). That should've been an indicator
alone - everyone knows that only 12 instructions are required for optimum
algorithms; just ask Dmitriy! So the new routine saves an instruction.
Second, the old routine sampled the switch state twice. This is fine when
the switches have been cached in RAM, but it's a potential problem if you
want to in-line the routine and not cache the switch state. Third, the new
routine now returns the state of switches that have just been filtered.
This is useful if you want to do something on a switch change. For
example,

  call   de_bounce   ; de-bounce the switches
  andlw  0xff        ; Any new changes?
  skpz
   call  handle_switch_changes

Scott

2006\01\01@234439 by Josh Koffman

face picon face
On 1/1/06, Scott Dattalo <scottSTOPspamspamspam_OUTdattalo.com> wrote:
> First, the old routine (it's been on my web site for ~7 years now) was 13
> instructions (excluding the return). That should've been an indicator
> alone - everyone knows that only 12 instructions are required for optimum
> algorithms; just ask Dmitriy! So the new routine saves an instruction.
> Second, the old routine sampled the switch state twice. This is fine when
> the switches have been cached in RAM, but it's a potential problem if you
> want to in-line the routine and not cache the switch state. Third, the new
> routine now returns the state of switches that have just been filtered.
> This is useful if you want to do something on a switch change. For
> example,

Hi Scott,

What do you think the best way to combine your debounce routine with
my matrix scanning routine would be? I'm thinking I would setup my
routine to scan and then dump the output in 8 bytes (64 switches).
Then I could call your routine to debounce those input bytes. I will
have to do a bit of work to the variables so that the various passes
don't stomp on each other. Perhaps I should use some indirect
addressing. Thoughts?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\01\02@082143 by Bill & Pookie

picon face
After ten years programming a machine in a noise environment, have adopted
the practice to debounce every digital input from a sensor as well as I/o
lines from other controllers.  Even find myself wanting to debounce flags
that I set myself under software control.

Also after reading the i/o lines, exclusive or them so that true is a '1'
value.  This makes the program much more readable.  and use '1' for outputs
true, then exclusive or them before putting them in ports.

Bill

{Original Message removed}

2006\01\02@085004 by olin piclist

face picon face
Bill & Pookie wrote:
> Even find myself wanting to debounce flags that I set myself under
> software control.

I was with you up to here, but this is just plain silly.

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\02@094131 by Bill & Pookie

picon face
I have been bitten so many times by  unbounced stuff that I got a bit
"compulsive obsessive"..  And appreciate being silly sometimes.

Bill

{Original Message removed}

2006\01\02@103429 by Howard Winter

face
flavicon
picon face
Peter,

On Sun, 1 Jan 2006 20:20:58 +0200 (IST), Peter wrote:

>
>
> On Sat, 31 Dec 2005, Wouter van Ooijen wrote:
>
> > The ganssle document is nice, but it does not mention down-state
> > bouncing.
>
> Down state bouncing seldomly occurs with new keys. It happens with
> 'rubber' keys and oxydized contacts or weak springs.

Right, but if you rely on that you are building obsolescence into your software, since mechanical switches do
change as they age, but are still usable even with a noisy signal if you debounce properly.

Cheers,


Howard Winter
St.Albans, England


2006\01\02@103737 by Howard Winter

face
flavicon
picon face
Mike,

On Sun, 1 Jan 2006 20:46:51 +0200, Mike Singer wrote:

> Peter wrote:
> > Any switch can have 'noise'. If you have a debouncing routine...
>
> SPDT + Schmit trigger input + 2 resistors may not need software debouncing.

Yes, but building a keypad/board with anything other than NO contacts is difficult and expensive!  It's fine
in a high-cost, high-reliability environment, such as ATMs, but not in something with a lot of buttons and a
sensitive cost.

Cheers,


Howard Winter
St.Albans, England


2006\01\02@104507 by Howard Winter

face
flavicon
picon face
On Sun, 1 Jan 2006 18:04:17 -0500, David VanHorn wrote:

> Someone else said:

> > No ? Afair gold has the lowest wetting current requirement. Think about
> > it, it is soft so point contacts are almost impossible, and it does not
> > oxydize.

But it does melt (and evaporate) - I wonder if arcing of the contacts would cause pitting because of this,
rather than oxidation as with other metals?

>
> try Mercury.

I did - tastes *awful*!  :-)

I presume the reason they used Mercury in arc-rectifiers was that you don't get wear of the contact surface
and even if you get surface oxidation it's not a problem because the moving contact will push through it (but
thinking about it, the envelope would be full of Mercury vapour anyway).

Cheers,


Howard Winter
St.Albans, England


2006\01\02@123458 by Scott Dattalo

face
flavicon
face
On Sun, 2006-01-01 at 23:44 -0500, Josh Koffman wrote:

> Hi Scott,
>
> What do you think the best way to combine your debounce routine with
> my matrix scanning routine would be? I'm thinking I would setup my
> routine to scan and then dump the output in 8 bytes (64 switches).
> Then I could call your routine to debounce those input bytes. I will
> have to do a bit of work to the variables so that the various passes
> don't stomp on each other. Perhaps I should use some indirect
> addressing. Thoughts?

Hi Josh,

My routine requires 3-bits per switch, or 4-bits if you wish to track when
a switch changes states (which is something you requested in your original
post). You have 64 switches, so 64*4 = 256 bits = 32 bytes are required. I
don't think you need to bother saving the raw, scanned values. The
de-bounce routine is so short that you can just call it whenever a scanned
value is obtained.

I think the easiest approach is to turn the routine into a macro and
in-line it with your scan code. Unroll the scan loop to simplify things
even more. I don't know the details of your code, but you probably can
even write a macro to scan your matrix.


  mMatrixScan 0
  mDeBounce   PORTB, clock_A0, clock_B0, cva_0
  movwf       changes0

  mMatrixScan 1
  mDeBounce   PORTB, clock_A1, clock_B1, cva_1
  movwf       changes1

 ....

  mMatrixScan 7
  mDeBounce   PORTB, clock_A7, clock_B7, cva_7
  movwf       changes7

The mMatrixScan macro scans one group of 8 switches. Here it's assumed
that PORTB contains the un-filtered switch state. The mDeBounce macro
filters one group of 8 switches. Its inputs are the variables needed for
the algorithm. At the end of the macro W will contain the change of state.
And this is stored in the 'changesX' variable.

Here's the routine in macro form

mDeBounce macro _csa, _count_A, _count_B, _cva

   ;Increment the vertical counter
       MOVF    _count_B,W
       XORWF   _count_A,F
       COMF    _count_B,F

   ;See if any changes occurred
       MOVF    _csa,W
       XORWF   _cva,W

   ;Reset the counter if no change has occurred
       ANDWF   _count_B,F
       ANDWF   _count_A,F

   ;If there is a pending change and the count has
   ;rolled over to 0, then the change has been filtered
       XORLW   0xff            ;Invert the changes
       IORWF   _count_A,W      ;If count is 0, both A and B
       IORWF   _count_B,W      ;bits are 0

   ;Any bit in W that is clear at this point means that the input
   ;has changed and the count has rolled over.

       XORLW   0xff
       XORWF   _cva,F
 endm

If you're using an 18F device, then it would be reasonable to use indirect
addressing. For the mid-range family, this routine will get a little
unwieldy with indirect addressing and double in size.

Scott

2006\01\02@172318 by Peter

picon face

>> No ? Afair gold has the lowest wetting current requirement. Think about
>> it, it is soft so point contacts are almost impossible, and it does not
>> oxydize.

> try Mercury.

Mercury oxydizes. If the mercury layer is thin enough that it is not
replaced by liquid then you have a problem (Mercury oxide is solid
afair).

Peter

2006\01\02@180415 by Peter

picon face

On Mon, 2 Jan 2006, Howard Winter wrote:

> Peter,
>
> On Sun, 1 Jan 2006 20:20:58 +0200 (IST), Peter wrote:
>
>> On Sat, 31 Dec 2005, Wouter van Ooijen wrote:
>>
>>> The ganssle document is nice, but it does not mention down-state
>>> bouncing.
>>
>> Down state bouncing seldomly occurs with new keys. It happens with
>> 'rubber' keys and oxydized contacts or weak springs.
>
> Right, but if you rely on that you are building obsolescence into your
> software, since mechanical switches do change as they age, but are
> still usable even with a noisy signal if you debounce properly.

I do not follow you here. Rely on what ? Some new rubber keys cannot
make their mind up whether they are up or down after 10 pushes.
Metal/metal pushbuttons can start to show signs of old age after six
months. I was advocating debouncing for both up and down, in software.
Maybe I made myself misundestood ;-)

Peter

2006\01\02@181300 by Peter

picon face

On Mon, 2 Jan 2006, Howard Winter wrote:

> On Sun, 1 Jan 2006 18:04:17 -0500, David VanHorn wrote:
>
>> Someone else said:
>
>>> No ? Afair gold has the lowest wetting current requirement. Think about
>>> it, it is soft so point contacts are almost impossible, and it does not
>>> oxydize.
>
> But it does melt (and evaporate) - I wonder if arcing of the contacts
> would cause pitting because of this, rather than oxidation as with
> other metals?

They are not good for high current. But there is almost nothing else for
low current, low noise, afaik. Pt should work too but I am not sure
about conductivity and hardness and such. Mercury wetted something is
better but cannot be used for connectors for obvious reasons.

Peter

2006\01\02@182131 by David VanHorn

picon face
>
>
> Mercury oxydizes. If the mercury layer is thin enough that it is not
> replaced by liquid then you have a problem (Mercury oxide is solid
> afair).


It's been used in sealed relays for many years, exactly for this purpose.
Rhodium is good too.

2006\01\02@182412 by David VanHorn

picon face
There is a world of difference between what the processor can see in a
scanned keyboard, and the classic demonstration of this using the switch to
clock a digital counter that can do 10-100 MHz counting.

Other factors come into play like pullup resistors on the rubber keys, since
they are variable resistors. If the pullup is too hard then you'll get
symptoms like that, or if the rubber is wearing out, or damaged in some way.

2006\01\03@001300 by Mike Singer

picon face
Howard Winter wrote:
> Yes, but building a keypad/board with anything other
> than NO contacts is difficult and expensive!  It's fine
> in a high-cost, high-reliability environment, such as
> ATMs, but not in something with a lot of buttons and a
> sensitive cost.

Howard,

I agree with you about high-volume production, but I can't about such
things as table simulators, cause Josh wrote:

> There's a software application I use that emulates a
> real piece of gear. ... I'm making a control panel that
> mimics the real device.

Few bucks for the set of ready-to-use reliable buttons would not kill
the project's budget. Instead, in my opinion, that will save much more
expensive developers time.
And usually buttons of real device are not concentrated in one place,
they are scattered all over the device. In this case a matrix would
not be a good choice, I think.
Better let the developer think of app-level problems, not contact
bouncing issues.

Regards,
Mike.

2006\01\03@064843 by Howard Winter

face
flavicon
picon face
Peter,

On Tue, 3 Jan 2006 01:04:14 +0200 (IST), Peter wrote:

{Quote hidden}

Ah yes, I see what you mean now!  I thought you were saying that debouncing wasn't needed with "new keys"
because they don't bounce.

Sorry - it seems we are in violent agreement!  :-)

Cheers,


Howard Winter
St.Albans, England


2006\01\03@081529 by Alan B. Pearce

face picon face
>After ten years programming a machine in a noise
>environment, have adopted the practice to debounce
>every digital input from a sensor as well as I/o
>lines from other controllers.  Even find myself
>wanting to debounce flags that I set myself under
>software control.

Been there, done that.

The memorable instance for me was when dealing with a computer system that
was being built to work in a freezing works (abattoir, killing chain) so had
to withstand a noisy environment with motor speed controls etc. Set up in
the lab it worked fine, until someone plugged in a small fluorescent lamp
(which was often used as a test source of mains spikes) and kept flicking
the on/off switch for rather more times than was necessary. The resultant
printing out of messages about lack of sync between the carcase chain
detector and some other signal that it used for syncing caused someone to
reset the machine rather than wait for the ASR33 to grind through an
innumerable number of lines of printout.

I got the job of putting in a one shot circuit on the relevant sensor line
that acted in a similar manner to the UART start bit detection filter -
pulse has to be present for a certain period of time to be considered a
valid pulse.

2006\01\03@082050 by Alan B. Pearce

face picon face
>> try Mercury.
>
>I did - tastes *awful*!  :-)

No fillings in your teeth then ... ;)

>I presume the reason they used Mercury in arc-rectifiers
>was that you don't get wear of the contact surface
>and even if you get surface oxidation it's not a problem
>because the moving contact will push through it (but
>thinking about it, the envelope would be full of Mercury
>vapour anyway).

Mercury in arc rectifiers is possibly for that reason.

But you can get relays with mercury wetted contacts for very low current
applications.

Anyone that thinks gold contacts do not corrode or get dirty should talk to
telephone engineers in geothermal regions. I know the telephone exchange in
Rotorua, NZ, went to extraordinary lengths to keep the sulphurous air out of
the exchange back in the days of using relays. The area around Rotorua is
very similar to Yellowstone Park in the USA.

2006\01\03@084336 by Howard Winter

face
flavicon
picon face
Alan,

On Tue, 3 Jan 2006 13:20:48 -0000, Alan B. Pearce wrote:

> >> try Mercury.
> >
> >I did - tastes *awful*!  :-)
>
> No fillings in your teeth then ... ;)

Plenty - that's what I meant...  :-)

>...
> But you can get relays with mercury wetted contacts for very low current
> applications.

Do you mean that mercury forms the contact?  I remember one house we lived in many years ago had a relay which
switched the storage-heater supply under control of a timeswitch, and it consisted of a horizontal glass tube
with two electrodes at one end and with a blob of mercury in it.  To switch on the tube was tilted towards the
electodes, and the mecury ran down and shorted between them, to switch off it tilted the other way and the
mercury ran away and uncovered the electrodes.  Is this what's known as "mercury wetted contacts"?  This was
not a low current application!

> Anyone that thinks gold contacts do not corrode or get dirty should talk to
> telephone engineers in geothermal regions. I know the telephone exchange in
> Rotorua, NZ, went to extraordinary lengths to keep the sulphurous air out of
> the exchange back in the days of using relays. The area around Rotorua is
> very similar to Yellowstone Park in the USA.

Presumably if you need a telephone exchange it means that people live there, in this sulphurous atmosphere?

Cheers,


Howard Winter
St.Albans, England


2006\01\03@095357 by olin piclist

face picon face
Howard Winter wrote:
> I remember one house we
> lived in many years ago had a relay which switched the storage-heater
> supply under control of a timeswitch, and it consisted of a horizontal
> glass tube with two electrodes at one end and with a blob of mercury in
> it.  To switch on the tube was tilted towards the electodes, and the
> mecury ran down and shorted between them, to switch off it tilted the
> other way and the mercury ran away and uncovered the electrodes.  Is
> this what's known as "mercury wetted contacts"?

No, that's an outright "mercury switch".

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\03@100947 by Keith

flavicon
face
New guy here, been lurking so far.

Mercury switches using a blob were / are used in thermostats and some silent
light switches. very reliable but very toxic.

Keith

{Original Message removed}

2006\01\03@104213 by Alan B. Pearce

face picon face
>Mercury switches using a blob were / are used in
>thermostats and some silent light switches. very
>reliable but very toxic.

Well, only if you break them.

2006\01\03@124024 by David VanHorn

picon face
I have a fun rotary fitting for microwave coax, that uses mercury.  This is
so that the antenna can rotate in any direction an unlimited amount.
Otherwise you'd eventually wear out the coax, and you'd have to "unwind"
every so often..

I've used them before for VHF DF, with a 5 element quad antenna spinning at
about 120 RPM, in the bed of a pickup truck.

2006\01\05@231125 by Josh Koffman

face picon face
On 1/2/06, Scott Dattalo <spamBeGonescottSTOPspamspamEraseMEdattalo.com> wrote:
> My routine requires 3-bits per switch, or 4-bits if you wish to track when
> a switch changes states (which is something you requested in your original
> post). You have 64 switches, so 64*4 = 256 bits = 32 bytes are required. I
> don't think you need to bother saving the raw, scanned values. The
> de-bounce routine is so short that you can just call it whenever a scanned
> value is obtained.
>
> I think the easiest approach is to turn the routine into a macro and
> in-line it with your scan code. Unroll the scan loop to simplify things
> even more. I don't know the details of your code, but you probably can
> even write a macro to scan your matrix.

Hi Scott,

Thanks for the code. I haven't had the chance to try it yet. At the
moment I'm focusing on getting my front panel PCB laid out and made. I
need an actual matrix keypad to test with anyway. I'm currently trying
to find the time to visit a friend who owns the full version of Eagle
as the free version won't let me do a board as large as I need it
(roughly 8" square).

I will keep you all posted!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams


'[PIC] Comments on keypad design?'
2006\02\06@232805 by Josh Koffman
face picon face
(Original email from Scott follows my reply)

Well, I'm finally ready to start playing with this code. The boards
are done, The main USB stuff seems to be working ok, and I have the
encoders all up and running. It's not in a case yet, but Spehro will
be helping me with that, and we've both been too busy to connect. So I
guess I have no excuses...I must get on with the debouncing!

I've been reading over the following routine, and before I implement
it, I just want to be sure of a couple of things.

1. At the end of the macro, the changes will be in W and I can save
them out. A 0 bit would mean the corresponding input has changed,
while a 1 bit means it's held steady, correct? This will only happen
when it changes state, right? For example, if I hold down a key for
100 iterations of the macro, I will get a 0 at the first transition,
then it will all be ones, then a 0 at the end when I release, correct?

2. My inputs have pull ups, so when no buttons are pressed, I should
end up with 0xFF in all the CVA registers. Would a good way to check
if I have a key pressed in that bank (not a transition, one that is
held, depending on the answer to the above question) just be to add
one to the CVA and see if I trip the Z flag?

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On 1/2/06, Scott Dattalo <KILLspamscottspamBeGonespamdattalo.com> wrote:
{Quote hidden}

2006\02\07@002453 by Scott Dattalo

face
flavicon
face
On Mon, 2006-02-06 at 23:28 -0500, Josh Koffman wrote:

> Well, I'm finally ready to start playing with this code. The boards
> are done, The main USB stuff seems to be working ok, and I have the
> encoders all up and running. It's not in a case yet, but Spehro will
> be helping me with that, and we've both been too busy to connect. So I
> guess I have no excuses...I must get on with the debouncing!
>
> I've been reading over the following routine, and before I implement
> it, I just want to be sure of a couple of things.
>
> 1. At the end of the macro, the changes will be in W and I can save
> them out. A 0 bit would mean the corresponding input has changed,
> while a 1 bit means it's held steady, correct? This will only happen
> when it changes state, right? For example, if I hold down a key for
> 100 iterations of the macro, I will get a 0 at the first transition,
> then it will all be ones, then a 0 at the end when I release, correct?

Josh,

There is an error in one of the comments of the debounce routine I wrote.

>    ;Any bit in W that is clear at this point means that the input
>    ;has changed and the count has rolled over.

Should read:

>    ;Any bit in W that is set at this point means that the input
>    ;has changed and the count has rolled over.

In other words, at the end of the macro, any set bits in W indicates
that a change has occurred. So if you press and hold a key, you will
see 4 iterations of the switch bit being zero, then 1 iteration of it
being zero, and then N iterations back at 0. When you release the
switch you'll see a similar thing. In both cases, the cva field matches
the csa field after 4 consecutive samples of the two being different



> 2. My inputs have pull ups, so when no buttons are pressed, I should
> end up with 0xFF in all the CVA registers. Would a good way to check
> if I have a key pressed in that bank (not a transition, one that is
> held, depending on the answer to the above question) just be to add
> one to the CVA and see if I trip the Z flag?

Yes, a good way to see if any switches are pressed is to do something like:

   incfsz cva,W
    goto  PressedSwitch
NoSwitchesPressed:

I've written a regression test in gpsim (my simulator) that tests all of
the corner cases for the debounce routine. I thought that I had checked
this into CVS, but I didn't. At the risk of overloading everyone's mailbox
I'll go ahead and include it here (besides, maybe someone will ask how
those assertions work).

       list    p=16f873                ; list directive to define processor
       include <p16f873.inc>           ; processor specific variable
definitions
       include <coff.inc>              ; Grab some useful macros

       __CONFIG (_CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _HS_OSC &
_WRT_ENABLE_ON & _LVP_OFF & _CPD_OFF)
       radix   dec

;------------------------------------------------------------------------
;
; debounce.asm - an efficient switch debouncing algorithm.
;
; This program tests a PIC de-bouncing algorithm (see below for a
; description of the algorithm). The test is designed to excercise
; all of the states of the algorithm. gpsim (the GNUPIC simulator)
; style assertions are used to verify that the algorithm works
; properly.



;----------------------------------------------------------------------
; Global Variables
;----------------------------------------------------------------------
GPR_DATA                UDATA

cva             RES     1    ; Debounced output from debounce routine
csa             RES     1    ; Unfiltered input to debounce routine
count_A         RES     1    ; MSB of 2-bit counter.
count_B         RES     1    ; LSB of 2-bit counter.

 GLOBAL cva, csa, count_A, count_B

 GLOBAL start
;----------------------------------------------------------------------
;   ********************* RESET VECTOR LOCATION  ********************
;----------------------------------------------------------------------
RESET_VECTOR  CODE    0x000              ; processor reset vector
       movlw  high  start               ; load upper byte of 'start' label
       movwf  PCLATH                    ; initialize PCLATH
       goto   start                     ; go to beginning of program



MAIN    CODE
start:

       CLRF    STATUS      ;Point to BANK 0

       CLRF    count_A
       CLRF    count_B
       CLRF    cva

  .assert "(count_A == 0) && (count_B==0) && (cva==0)"

  ;First verify that a 0 input produces a 0 output
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==0)"

  ;Now set one of the inputs
       MOVLW   1
       MOVWF   csa

  ;Pass through the four debounce states. After the fourth
  ;state, cva should go from 0 to 1.
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==1) && (cva==0) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==0) && (cva==0) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==1) && (cva==0) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==1) && (W==1)"

  ;The current value has just changed from a 0 to a 1. Now
  ;verify that if the input stays at 1 the output doesn't change
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==1) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==1) && (W==0)"

  ;Now check that a 0 input is debounced:
       CLRF    csa
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==1) && (cva==1) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==0) && (cva==1) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==1) && (cva==1) && (W==0)"

       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==0) && (W==1)"


  ;Now check multiple bit filtering

       MOVLW   0x0f
       MOVWF   csa
       MOVLW   0xf0
       MOVWF   cva

       CALL    de_bounce
  .assert "(count_A == 0x00) && (count_B==0xff) && (cva==0xf0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 0xff) && (count_B==0x00) && (cva==0xf0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 0xff) && (count_B==0xff) && (cva==0xf0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 0x00) && (count_B==0x00) && (cva==0x0f) && (W==0xff)"

  ; Now check that glitches are filtered.
       CLRF    cva
       CLRF    csa


  ; 1-sample glitch
       BSF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==1) && (cva==0) && (W==0)"
       BCF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==0) && (W==0)"

  ; 2-sample glitch
       BSF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==1) && (cva==0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==0) && (cva==0) && (W==0)"
       BCF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==0) && (W==0)"

  ;3-sample glitch
       BSF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==1) && (cva==0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==0) && (cva==0) && (W==0)"
       CALL    de_bounce
  .assert "(count_A == 1) && (count_B==1) && (cva==0) && (W==0)"
       BCF     csa,0
       CALL    de_bounce
  .assert "(count_A == 0) && (count_B==0) && (cva==0) && (W==0)"


       nop
 .assert  "\"*** PASSED debounce test\""

       GOTO    $
;*************************************************************
; de_bounce
;
; The purpose of this routine is to debounce, i.e. digitally low pass filter
;inputs. The algorithm handles upto 8 bits at a time. An input is considered
;filtered if it has not changed states in the last 4 samples.
;
; 2-bit cyclic vertical counters count the 4 samples. As long as there is no
;change, the counters are held in the reset state of 00b. When a change is
detected
;between the current sample and the filtered or debounced sample, the
counters
;are incremented. The counting sequence is 00,01,10,11,00... When the
counters
;roll over from 11b to 00b, the debounced state is updated. If the input
changes
;back to the filtered state while the counters are counting, then the
counters
;are re-initialized to the reset state and the filtered state is unaffected.
;In other words, a glitch or transient input has been filtered.
;
;The algorithm will return in W the state of those inputs that have just
;been filtered.
;
; Here's the C-psuedo code:
;
;static unsigned clock_A,clock_B,debounced_state;
;unsigned debounce(unsigned new_sample)
;{
;  unsigned delta;
;  unsigned changes;
;
;  delta = new_sample ^ debounced_state;   //Find all of the changes
;
;  clock_A ^= clock_B;                     //Increment the counters
;  clock_B  = ~clock_B;
;
;  clock_A &= delta;                       //Reset the counters if no changes
;  clock_B &= delta;                       //were detected.
;
;  changes = ~(~delta | clock_A | clock_B);
;  debounced_state ^= changes;
;
;  return changes;
;}
;
; The 2-bit counters are arranged "vertically". In other words 8 counters
;are formed with 2 bytes such that the corresponding bits in the bytes are
;paired (e.g. MSBit of each byte is paired to form one counter).
; The counting sequence is 0,1,2,3,0,1,... And the state tables and Karnaugh
;maps are:
;
;State Table:     Karnaugh Maps:
;pres  next      B
; SS  SS         0   1
; AB  AB       +---+---+    +---+---+
;--------   A 0|   | 1 |    | 1 |   |
; 00  01       +---+---+    +---+---+
; 01  10      1| 1 |   |    | 1 |   |
; 10  11       +---+---+    +---+---+
; 11  00      A+ = A ^ B     B+ = ~B
;
; Here's the PIC code that implements the counter:
;       MOVF    SB,W    ;W = B
;       XORWF   SA,F    ;A+ = A ^ B
;       COMF    SB,F    ;B+ = ~B
;
;
;
; 13 instructions
; 14 cycles
; Inputs:
;   csa - The current sample
; Outputs
;   cva - The current value (filtered version of csa)
;   W   - Bits that have just been filtered.
;
; RAM used
;   count_A,
;   count_B - State variables for the 8 2-bit counters
;
de_bounce:
   ;Increment the vertical counter
       MOVF    count_B,W
       XORWF   count_A,F
       COMF    count_B,F

   ;See if any changes occurred
       MOVF    csa,W
       XORWF   cva,W

   ;Reset the counter if no change has occurred
       ANDWF   count_B,F
       ANDWF   count_A,F

   ;If there is a pending change and the count has
   ;rolled over to 0, then the change has been filtered
       XORLW   0xff            ;Invert the changes
       IORWF   count_A,W       ;If count is 0, both A and B
       IORWF   count_B,W       ;bits are 0

   ;Any bit in W that is set at this point means that the input
   ;has changed and the count has rolled over.

       XORLW   0xff
       XORWF   cva,F

       RETURN

       END


2006\02\07@094001 by Josh Koffman

face picon face
On 2/7/06, Scott Dattalo <EraseMEscottspamEraseMEdattalo.com> wrote:
> In other words, at the end of the macro, any set bits in W indicates
> that a change has occurred. So if you press and hold a key, you will
> see 4 iterations of the switch bit being zero, then 1 iteration of it
> being zero, and then N iterations back at 0. When you release the
> switch you'll see a similar thing. In both cases, the cva field matches
> the csa field after 4 consecutive samples of the two being different

Um...I'm guessing there's a typo here? Should be 1 iteration of it
being 1 instead of "1 iteration of it being zero", correct?

> I'll go ahead and include it here (besides, maybe someone will ask how
> those assertions work).

Alright, I'll bite. How do assertions work? :) I'm guessing this is a
gpasm thing and I only use MPASM.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\02\07@130525 by Scott Dattalo
face
flavicon
face
Josh Koffman wrote:
> On 2/7/06, Scott Dattalo <@spam@scott@spam@spamspam_OUTdattalo.com> wrote:
>
>>In other words, at the end of the macro, any set bits in W indicates
>>that a change has occurred. So if you press and hold a key, you will
>>see 4 iterations of the switch bit being zero, then 1 iteration of it
>>being zero, and then N iterations back at 0. When you release the
>>switch you'll see a similar thing. In both cases, the cva field matches
>>the csa field after 4 consecutive samples of the two being different
>
>
> Um...I'm guessing there's a typo here? Should be 1 iteration of it
> being 1 instead of "1 iteration of it being zero", correct?

Damn... Maybe I should avoid writing any comments! You're correct.

>
>>I'll go ahead and include it here (besides, maybe someone will ask how
>>those assertions work).
>
>
> Alright, I'll bite. How do assertions work? :) I'm guessing this is a
> gpasm thing and I only use MPASM.

Actually, the assertions are a gpsim thing. Both MPASM and gpasm can
issue an assert directive (which is really just a macro for a .direct
directive). The assertion gets placed into the .coff/.cod file.

gpsim deciphers these directives and turns them into breakpoint
assertions. A breakpoint assertion is a special gpsim execution
breakpoint that has an expression associated with it. Normal execution
breakpoints halt the simulation whenever they're encountered. Assertion
breakpoints only halt the simulation when they're encountered AND they
evaluate to false. You can think of them as conditional breakpoints.

As you can imagine, these are useful for regression tests and code
validation.

Scott

2006\02\07@150123 by Josh Koffman

face picon face
On 2/7/06, Scott Dattalo <spamBeGonescottspamKILLspamdattalo.com> wrote:
> Actually, the assertions are a gpsim thing. Both MPASM and gpasm can
> issue an assert directive (which is really just a macro for a .direct
> directive). The assertion gets placed into the .coff/.cod file.
>
> gpsim deciphers these directives and turns them into breakpoint
> assertions. A breakpoint assertion is a special gpsim execution
> breakpoint that has an expression associated with it. Normal execution
> breakpoints halt the simulation whenever they're encountered. Assertion
> breakpoints only halt the simulation when they're encountered AND they
> evaluate to false. You can think of them as conditional breakpoints.
>
> As you can imagine, these are useful for regression tests and code
> validation.

That's pretty cool! I had no idea that was possible.

What I'd really like is to be able to make a variant of a breakpoint
for when I'm using my ICD2. If I want the values in my watch window to
update, I can either set a breakpoint (which halts everything
completely), press the pause button, or enter "Jog" mode which updates
the watch after each step, leading to slow execution. What I'd really
like is to set a position in my program where every time execution
passes that point, the watch window is updated. That would allow me to
do tests on my large switch matrix and watch which registers change.
Is that even feasible?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\02\07@164230 by Scott Dattalo

face
flavicon
face
Josh Koffman wrote:

> What I'd really like is to be able to make a variant of a breakpoint
> for when I'm using my ICD2. If I want the values in my watch window to
> update, I can either set a breakpoint (which halts everything
> completely), press the pause button, or enter "Jog" mode which updates
> the watch after each step, leading to slow execution. What I'd really
> like is to set a position in my program where every time execution
> passes that point, the watch window is updated. That would allow me to
> do tests on my large switch matrix and watch which registers change.
> Is that even feasible?

The breakpoint assertions I discussed applied only to the simulator (and
specifically to my simulator). The ICD is a different beast. One way to
achieve this watch window feature is with a simple serial port debugging
tool. I usually instrument my programs with a little RS232 debugging
routine so that I can monitor certain state variables or whatever. This
is similar to the "jog" feature of the ICD, but I have control when
things are updated.

If you're willing to stay in simulation land, then you may consider
building a gpsim switch matrix module and simulating a portion of your
system. I just checked in a patch the other day from a user who
introduced switch capacitance to the switch module (there already was a
concept of switch resistance), so you could model capacitive loading
(which may or may not be important to you). In my opinion, it may be
more effort than it's worth to build a model, but if this is a project
that you think will have a long life span and used as the basis for
other projects, then it may be worth it.

Scott

2006\02\07@203940 by Josh Koffman

face picon face
On 2/7/06, Scott Dattalo <.....scottspam_OUTspamdattalo.com> wrote:
> The breakpoint assertions I discussed applied only to the simulator (and
> specifically to my simulator). The ICD is a different beast. One way to
> achieve this watch window feature is with a simple serial port debugging
> tool. I usually instrument my programs with a little RS232 debugging
> routine so that I can monitor certain state variables or whatever. This
> is similar to the "jog" feature of the ICD, but I have control when
> things are updated.

I normally would do something like this. Unfortunately, I needed the
I/O. It would be convenient, since I'm already using the ICD to have
it update my watch automatically once in awhile. Ah well!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

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