7Pin keypad
By Tgeahre
2008-06-07 06:31
2008-06-07 06:31
Oi all,
I decided to play with my keypad. it is a 1-9, 0, *, and # keypad. 3 columns and 4 rows. I got it from the picaxe store (Here) only one difference, there isn't a first or ninth pin. looks a lot like on page 1 of This pdf.
C2-R1-C1-R4-C3-R3-R2 (R = row- C = column)
I was trying to figure out exactyl how to hook this up. I don't know how to hook the pad up to a powersource. I know that it hookes up to the digital ins on my picaxe but I don't know how
could someone please help me with this.
Thnx
Tgeahre
you take the columns and
you take the columns and hook it up to output pins, and the rows you hook up with input pins (dont forget the pulldowns) (or vice versa). Than you scan the columns (one by one) and look for the rows whether some button is pressed.
btw from picaxe page:
ya that was where I got the
ya that was where I got the one I put up from, but i took off the NC's since they werent on the board they sent me.
I understand the workings now. plus I am quickly understanding the value of slaves. I was hoping to play with my 7segment display and my keypad at once, but the seven segment takes up 8 outputs as it is. do you know of a way to run the 7segment without the slave with less outputs (as for the time being I am limited to my single 28x1).
im getting the fealing that one IC just will never do the trick.
Both Together
Yes. There is a way to run the both together. There's nothing to stop the scanning output lines which are used to drive the keypad from also being the data lines to the LCD.
One thing, though: keypad input may make the LCD display a lot of rubbish, so you need to refresh it often.
A note on the keypad: if you intend at any stage to press multiple keys at a time, or if that might happen accidentally, put signal diodes in each of the driver lines. Otherwise, you get a phonomenon called ... well, it has a name, which escapes me right now, but you pres two keys on the same row and your decoder thinks you pressed something completely different.
Trouble is, then you can't use it to drive your LCD (well, you can, but you won't be able to query it).
so if I am right, you are
so if I am right, you are saying that as long as the refresh rate is high enough (the user may see a blink but nothing substansial) I can have the picaxe test the columns (i have more inputs then outputs at the moment) which are also connected to three of the 8 leds on the 7segment. I can use an interupt to make is so that when the input is finally let go, after the number is correctly output to the display, the number is too.
I don't completly understand how this methode will produce rubbish in the LCD but I will try it and maybe find out how at that time.
Thanks a lot everyone
Tgeahre
Rubbish
The method would produce rubbish on the screen when keys are pressed because the key presses will be interpreted as LCD data. If you're trying to write the LCD at the same time as keys are pressed, the data sent will probably be garble.
No. I'm absolutely not recommending a high refresh rate. Just a refresh after every key press. Failing that, get on the modular bandwagon http://letsmakerobots.com/node/551 and make an I2C interface to the LCD and/or the keypad. That way you can drive both devices using only two pins....!
Make it an I2C Module
Once you get this working, I'd be interested to see if you could make it an I2C Module. This is what idaniel was suggesting with the LMR Global Project. I've just finished an I²C controller PCB. I'm populating it and developing the software at the moment.
A few Ideas
I have a few Ideas on how to make this work on a limited ammount of outputs. after thinking about the solution you gave me earlier I realized that it was flauwed in 1 way,
suppose that the left column and the bottom middle LED of the 7-seg are both connected to out7.
if I push the 1 button I have to maintain the output to out7 in order to check for the user letting go of the button.
while out7 is on the bottom center led is still on this is not good as the number 1 onle uses the right leds
my end solution is mostly programming. give all columns two leads from the out pins. then after checking to see what number is being used, the Picaxe decides (from given inputs) which outs to use making sure to only use 1 ot the columns 2 output pins.
this will only work for the use of pushing a button and loosing the LCD after letting go but i can rethink if for use with modular use. change it to be 2 digits and allowing short term number storage using the pound # and asterisk * symbols for send and delete respectivly
any other suggestions?
Tgeahre
retraction
Distributed Processing!
Make TWO devices: one resonsible for handling the keypad and the other for the LCD! Use the I2C bus. Make the hardware and software open source.
well, I found a rather
well, I found a rather embarising thing to find. I was looking through the list of picaxe chips and noticed that the chip I have, the 28x1, had 16 outputs. meaning that I could have easilly used both the single digit LCD and the 12 key at the same time. with out any of these problems.... lika I said... embarising, lol
I am rethinking a lot of things right now. I tought I could use only one single 28x1 due to my new found 16 outs (14 for the 7 segs leaving out the decimals and 2 for the rows with some creative programming), but then realized I need 2 for the i2c so ill probably use a 28x1 with a serin-slave picaxe-08 for the axtra 3 or four outputs that I need. this gives me the room that I need to work with it and to work comfortably. I would goto a 40x but that doesn't have any more outputs then the 28x1.
I think I can possibly get the 28x1 to work by itself without a serin-slave but there is an easy chance of glitching and would rather have a module that WONT glitch for sure. ill draw up a plan and code for it anyway.
this will be fun. I have never don I2C before and will learn much. :)
(typed over much time but not reread, lol)
Click here for the full
Click here for the full image
IC and analog Alternatives
There have been keypad decoder ICs in the digital logic family, the numbers referenced being 74922 and 74923. Sadly these seem discontinued by most manufacturers. Newark appears to have some Fairchild MM74C922WM at a price of $6.22 each. I don't know what Newarks minimum order is if they have one. At any rate, it appears to be hooked up something like the keypad row and column pins connected into the IC, and 4 output lines give you a 4 bit number corresponding with the key pressed. As long as the clock is setup, enables set. Other keypad decoders have thrown a cheap mcu at it, which gives another device to program.
For the 7 segment LEDs, not LCDs, another logic IC, the 7447 might be used. This still appears to be manufactured, like the TI SN7447AN, and more findable at $1.85 one place. It is described as a "BCD to 7 segment" decoder. In this case, a 4 bit number is input, to have it displayed on the 7 seg LED. I think I have a couple 74LS47 devices used a while back, pretty easy to hook up.
Using thise logic ICs, it looks like you could go from 21 lines needed, down to 12.
Oh, another thought, found an analog solution to the keypad reading, see this URL :
http://www.picaxe.orconhosting.net.nz/matrix.jpg
I don't use the PICaxe, but it appears to have been mentioned here.
Dave
Good point
"For the 7 segment LEDs, not LCDs..."
Well spotted.
Read my comment here:
Read my comment here: http://letsmakerobots.com/node/131#comment-178 It's a description of using the 4511 chip which is a bcd to 7-segment display driver. Using this, you can use 4 pins for the data and 2 for the control (selecting display 1 or 2).The 4511 will keep the data until you set it to some other digit. Setting both control lines low, the 4 data pins are available for other things and won't affect the display, as long as the two enable lines are low.
Great Schematic
Oi all. I made up a new
Oi all. I made up a new schematic for this using a double digit 7seg, 2 4511 drivers, an ex. or, and using the keypad as an analogue input.
Here are the Higher quality images
This is ment to work on I2C and you will have the option to use output 5 as a way of signalling an interupt on the master pic.
So what do you guys think?
2-wire Keypad
I like the idea of using a sort of resistor ladder to connect the keypad.
Could I be very bold and propose an alternative connection pinout for I2C? The reason is that I've already started on my I2C devices and I have 2 boards etched. I thought it might be a good idea if your device was "compatible"? I'm using a 3-wire interface to the main computer which does not involve battery power. My three pins are:
1 - ground
2 - data
3 - clock
You've adopted a 5-wire strategy and you may want to stick with that. What would you say to moving your pins around so that the first three are compatible with my schema? Then, I'll modify my schema to include flexability for the two extra lines.
Pullups: I see you've put pullup resistors on the clk and data lines. These are normally provided at only one point in the lines. Since every bus has a master, my suggestion is that you leave them out, but add them to your bus master device. That way you won't have a load of pullups in parallel if you have multiple slaves.
Enjoy.
they are good opinions and I
they are good opinions and I thinkk the best thing to do on the pin amounts would be to arange the pins in order as
so that you can have the 5 or 3 pin layout.
also the pulup resistor idea is wise. I cant remember my logic on why I had it this way but I see the reason not too and will change that
Thnx
Tgeahre
Magic
Looks like we have a plan, then. Have you devised a protocol? I'm going to write this up on the boards later, but I'm thinking that the master will be able to inspect or modify any 8-bit address in the slave using the following conversation:
1) The bus master sends a 3 (or 4) byte message consisting of:
2) The slave responds with the data byte. Where the command was read, this is the data read. Where the command was write, this is the data written.
* The reasons are historical. This is a subset of an existing protocol and may be expanded later to include bit read / write, byte read / write commands. My protocol has a lot more functionality including code jumps, but this is enough to get started.
What say ye?
well so far I wasn't
well so far I wasn't planning on having the master write to the slave in this but I think I can come up with some nice things that could be helpful for it so I'll look that over later. what I do have though is rather nice I think. I haven't finnished the code as I don't know everything about I2C communication that I want yet but I am still reading up on it. I have finnished the program to print the numbers on the screen though it's not tested. I don't have the XOR so I cant really test it yet.
Here is the code I have:
symbol adc = b1
symbol seg1 = b2
symbol seg2 = b3
symbol num = b4
symbol latch = pin4
'reset
init:
let num = 00
goto add0
scan:
readadc 3, adc
if adc < 50 then scan
if adc < 57 then add1
if adc < 62 then add2
if adc < 68 then add3
if adc < 75 then add4
if adc < 80 then add5
if adc < 90 then add6
if adc < 104 then add7
if adc < 120 then add8
if adc < 140 then add9
if adc < 180 then init
if adc < 220 then add0
if adc = 255 then send
goto scan
'sets latches and routs to digit setting subroutines
display:
let latch = 1
on seg2 gosub led0, led1, led2, led3, led4, led5, led6, led7, led8, led9
let latch = 0
on seg1 gosub led0, led1, led2, led3, led4, led5, led6, led7, led8, led9
goto scan
'to i2c
send:
'use I2C to send num to the master uProcessor
goto scan
'Calculates num. outputs to display to set the 7segs.
add0:
num = num % 10
num = num * 10
seg1 = num % 10
seg2 = num / 10
goto display
add1:
num = num % 10
num = num * 10 + 1
seg1 = num % 10
seg2 = num / 10
goto display
add2:
num = num % 10
num = num * 10 + 2
seg1 = num % 10
seg2 = num / 10
goto display
add3:
num = num % 10
num = num * 10 + 3
seg1 = num % 10
seg2 = num / 10
goto display
add4:
num = num % 10
num = num * 10 + 4
seg1 = num % 10
seg2 = num / 10
goto display
add5:
num = num % 10
num = num * 10 + 5
seg1 = num % 10
seg2 = num / 10
goto display
add6:
num = num % 10
num = num * 10 + 6
seg1 = num % 10
seg2 = num / 10
goto display
add7:
num = num % 10
num = num * 10 + 7
seg1 = num % 10
seg2 = num / 10
goto display
add8:
num = num % 10
num = num * 10 + 8
seg1 = num % 10
seg2 = num / 10
goto display
add9:
num = num % 10
num = num * 10 + 9
seg1 = num % 10
seg2 = num / 10
goto display
'set 7segs
led0:
let pins = %00000000 & %00001111
return
led1:
let pins = %00000001 & %00001111
return
led2:
let pins = %00000010 & %00001111
return
led3:
let pins = %00000011 & %00001111
return
led4:
let pins = %00000100 & %00001111
return
led5:
let pins = %00000101 & %00001111
return
led6:
let pins = %00000110 & %00001111
return
led7:
let pins = %00000111 & %00001111
return
led8:
let pins = %00001000 & %00001111
return
led9:
let pins = %00001001 & %00001111
return
as you can see, if you are good at reading code, it is made to start with the number 00. then you push a key, lets say 5, and the number is 05. push 6 and it is 56. push 9 and the number is 69. you get the idea. I only have to come up with the I2C section. I have the signal pin set up so that it can be used as an interuptor, but that is probably a crude way of doing it. do you know what I meen by using it as an interuptor? is it crude? is there a better way?
Back to the Future
I don't use BASIC on a PIC. I've done this sort of thing before in PIC RISC and an "interrupt on PORTB change" is the best way.
In RISC, you have a piece of code at the interrupt vector (address 0x0004) which looks for the RBIF bit of the INTCON register going high. That's how you know SOMETHING on PORTB has changed.
Have you considered "debounce"? I suspect that the code will execute so quickly that when you press a key the PIC will think you've pressed it about 5 times. Once the interrupt takes place, I suggest you pause for about 20ms before actually processing it.
that is agood idea, I'll
that is agood idea, I'll look into the debounce idea when I finally get my XOR and can actually try it.
I don't know currently how to program pics in other languages. the important thing is that you agree on the interupt pin as a method of telling the master that a number has been submited using the submit key (pound #).
I'll finnish my readings on I2C communication and update my code.
Me neither
PS