Reading Button Inputs
John Board
Posts: 371
Hi Y'all,
What is THE EASIEST way to get the input from a button, I have heard you can get the input without even needing an RCDecay circut.
Cheers,
P.S. If you don't reply because you think this question is stupid, feel free to do so
John
What is THE EASIEST way to get the input from a button, I have heard you can get the input without even needing an RCDecay circut.
Cheers,
P.S. If you don't reply because you think this question is stupid, feel free to do so
John
Comments
Very few questions are stupid. Some need a bit more research than others. Use "parallax button debounce" for google keywords. Lots of history to be sure. Have fun (most important or why bother) and ask away. Lotsa high end talent out here.
Frank
pub debounce(pin, ms) : scans dira[pin] := 0 ' force to input repeat ms waitcnt(cnt + clkfreq / 1000) ' wait 1ms scans += ina[pin] ' scan pin return (scans == ms) ' return true if good inputDo know the basics of SPIN. I am wanting to find a better way of getting button inputs.
Does this work without any extra circutry?
So, when responding, if you could not only give me a code example, but some schematics too.
Start with a single button.
Wire a pull up resistor (10k to 3.3V) to the Normally Open pin of the switch, and ground the Common.
Reading the button will normally return a 1.
When the button is pressed, the pull-up is grounded and reads zero.
So the logic is backwards -
1 means the button NOT pressed.
0 means the button IS pressed.
But then time frames become an issue.
What happens in human time is not the same as what happens in processor time.
In human time the switch closes and that's all there is.
In processor time, the contacts of the switch "bounce", closing and opening again several times.
Hence the "debounce" requirement.
In my first little ditty, I debounced my button input -- with an LED.
At least for this effort.
And the LED blink was on for a Long long LONG long time (in processor years anyway).
By the time that had finished (waitCnt of 1_000_000) the switch had long since settled down.
A keypad is a bit more complex.
Here is a make believe of the process - in positive logic. (Won't work in the real world)
The switches are wired as columns and rows.
The columns are wired to output ports so that one column at a time can be scanned.
The ROWS are wired back to input ports.
The pad is wired so that that column bit is presented to the entire column of buttons.
If one of the buttons is pressed, then that key returns the scan bit to one (and only one) of the input ports
Assume we have a 4 x 4 pad - 4 rows and 4 columns.
Each column is attached to an output port, and each row and input port.
Furthermore, assume we have pressed the top left button corresponding to column 4 row 1.
We scan the columns, one at a time, but putting a 1 (logic hi) on that column and reading
the 4 input ports (rows) to see if the 1 shows up.
Nothing happens until column 4, which is returned to input port for row 1.
At that point we MAY have a valid button pressed.
MAY, because there may be other buttons pressed also, and we need to eliminate that possibility
before we can be sure. So we scan the rest of the rows to see if any other key is pressed.
Only when we are finished with the entire scan can we know for sure if a single valid key is pressed.
If that seems to make any sense you are well on your way to understanding why nobody can answer
your question. It depends on the keypad and how it is wired internally.
Also, hardware is usually rin in inverted logic since it's easier that way.
The rows could be pulled up with a simple pull-up resistor (way back at the top of this speil) and a
logic low (0) used for the scan. Then you are looking for the logic 0 to be returned to the input bits.
After all of that - and it sounds pretty negative, I must admit - there is still hope.
If you bought your keypad from Parallax, there is probably an example driver for it.
If it's frome a Blackberry, probably not (but there outta be!)
So, what kind of keypad are we talking about here?
[EDIT] Thank goodness that I'm getting a new 4x4 one today from jaycar, it will work with the example code that I got for a 4x4 keypad.
The pin 18 is an LED pin on the Demo Board, Pin 2 is the receiving pin, and pin 3 is the "transmitting" pin.
Here is mine...
{{ Jan 30, 2011 Blinky51.spin }} CON _CLKMODE=XTAL1+PLL2X _XINFREQ =5_000_000 HI = 1 LO = 0 SlowWait = 5_000_000 FastWait = 1_000_000 PinOut = 07 ' has an LED PinIn = 06 ' has a switch wit a 10K pull up resistor PUB MAIN dira [PinOut] := 1 'output bit for LED outa [PinOut] := 0 dira [PinIn] := 0 'input bit for button repeat if ina[PinIn] == 1 ' if button IS NOT pressed repeat 1 'blink it fast outa[PinOut] := HI waitCNT (FastWait+cnt) outa[PinOut] := LO waitCNT (FastWait+cnt) else ' button IS pressed repeat 2 'blink it slow outa[PinOut] := HI waitCNT (SlowWait+cnt) outa[PinOut] := LO waitCNT (SlowWait+cnt)[ CODE] My code [ /CODE]
but without the spaces.
Thank you, that helps a lot.
As cavelamb has said, a 4x4 keypad is not the same thing as 16 buttons.
Here's the comments from Beau's keypad object found in the Propeller Tool's library folder.
{{ ***************************************** * 4x4 Keypad Reader v1.0 * * Author: Beau Schwabe * * Copyright (c) 2007 Parallax * * See end of file for terms of use. * ***************************************** }} { Operation: This object uses a capacitive PIN approach to reading the keypad. To do so, ALL pins are made LOW and an OUTPUT to "discharge" the I/O pins. Then, ALL pins are set to an INPUT state. At this point, only one pin is made HIGH and an OUTPUT at a time. If the "switch" is closed, then a HIGH will be read on the input, otherwise a LOW will be returned. The keypad decoding routine only requires two subroutines and returns the entire 4x4 keypad matrix into a single WORD variable indicating which buttons are pressed. Multiple button presses are allowed with the understanding thatBOX entries can be confused. An example of a BOX entry... 1,2,4,5 or 1,4,3,6 or 4,6,*,# etc. where any 3 of the 4 buttons pressed will evaluate the non pressed button as being pressed, even when they are not. There is no danger of any physical or electrical damage, that s just the way this sensing method happens to work. Schematic: No resistors, No capacitors. The connections are directly from the keypad to the I/O's. I literally plugged mine right into the demo board RevC. Looking at the Back of the 4x4 keypad... P7 P0 ││││││││ ┌─────── ││││││││ ───────┐ │ oo ││││││││ o │ │ │ │ O O O O O │ │ │ │ O O O O O │ │ {LABEL} │ │ O O O O O │ │ │ │ O O O O O │ │ │ │ O O O O O │ │ o o │ └────────────────────────┘ }I believe Beau's code requires the keypad to be connected to the Propeller chip with very short wires to work correctly. I added 0.1uF capacitors to either the columns or the rows (but not both) to use the code with a keypad attached with longish wires.
Not unless you consider a pull-down (10K) and a normally-open button as extra circuitry....
This is great, I found this code before you referenced it to me, however, it still has been great, today I soldered some headers onto my new 4x4 keypad, plugged it DIRECTLY into the I/0 pins on the demo board, and it worked great!
Thanks Beau!
And thanks y'all
-John