EmbeddedRelated.com
Forums
Memfault State of IoT Report

keypad controller

Started by Unknown May 31, 2005
Alan wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote: >
... snip ...
>> >> A few years ago there was a discussion of key matrices that >> dispensed with diodes and that could detect various things, such >> as multiple keys down, rollover, etc. I have lost what I saved, >> but I recall that the cost was the full intersection range of >> the key positions. I.e. a 4x4 matrix could handle, say, 10 keys >> in place of 16. I think the discussion was right here on c.a.e. > > Have a look at: > http://www.freescale.com/files/32bit/doc/app_note/MC68EZ328KEYPAD.pdf > > 5 lines can hanlde a 4 x 4 matrix > 6 lines can handle a 5 x 5 matrix > 7 lines can handle a 6 x 6 matrix > etc. > > I made a full 4 row querty keyboard using this scheme and it does > work.
That's the sort of thing. There was a better discussion and/or refs than that app-note, IIRC. It also developed the generic rules and penalties for configurations. -- Some informative links: news:news.announce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
praveen.kantharajapura@gmail.com wrote:
> I am implementing the Keypad scanner in an FPGA , how will i go about > the design of multiple key presses. > Spehro Pefhany wrote: >
Do what the PS/2 keyboard does. Use keycodes to indicate key transistions, eg. 0xFF01 for keypress and 0xF001 for key release. Buffer these codes in the FPGA using a FIFO. Let the firmware figure out how to use these codes for its purposes. Some FPGA ideas... - use two flip-flops in series and an XOR to capture the transistion - Generate logic to create the keypress and keyrelease codes, then place the code into the FIFO. Generate unique codes for each key (0x00 - 0x0F for the keypad below) and place these into the FIFO after the transistion code. - Use an arbiter to prevent key collisions. - Use a slow scanrate (10ms per row?) to prevent keybounce problems. Hope this helps, - Richard
>>On Tue, 31 May 2005 19:23:31 +0200, the renowned Michael Lange >><leckmich@despammed.com> wrote: >> >> >>>Hi you, >>> >>> >>>>I want to implement a 6x6 matrix keypad controller in hardware which >>>>should be able to detect multiple key presses. >>>>Can anybody suggest how to go about this?? >>> >>>if you mean more than one key pressed same time, you could use this. >>>(Please expand to 6x6 matrix). Set the Y-lines to high, only one at same >>>time, and read the X-lines to get the pressed key(s) in this row. >>> >>> Y0 o Y1 o Y2 o Y3 o >>> | T | T | T | T >>> | --- | --- | --- | --- >>> o--o o-->|--. o--o o-->|--. o--o o-->|--. o--o o-->|--. >>> | | | | | | | | >>> X0 o---)-----------o-)-----------o-)-----------o-)-----------o- >>> | T | T | T | T >>> | --- | --- | --- | --- >>> o--o o-->|--. o--o o-->|--. o--o o-->|--. o--o o-->|--. >>> | | | | | | | | >>> X1 o---)-----------o-)-----------o-)-----------o-)-----------o- >>> | T | T | T | T >>> | --- | --- | --- | --- >>> o--o o-->|--. o--o o-->|--. o--o o-->|--. o--o o-->|--. >>> | | | | | | | | >>> X2 o---)-----------o-)-----------o-)-----------o-)-----------o- >>> | T | T | T | T >>> | --- | --- | --- | --- >>> o--o o-->|--. o--o o-->|--. o--o o-->|--. o--o o-->|--. >>> | | | | | | | | >>> X3 o---)-----------o-)-----------o-)-----------o-)-----------o- >>> | | | | >>> | | | | >> >> >> >>Perhaps obvious, but you do need some pull-down resistors on the X >>lines. Less obviously, there is an RC time constant between the stray >>capacitance and the resistors you choose (when the line is going low), >>so you might want to have the processor twiddle its thumbs for enough >>time to let the voltage settle. Maybe a microsecond or so with 10K >>(assuming short connections), proportionally longer with higher >>resistances. >> >> >>Best regards, >>Spehro Pefhany >>-- >>"it's the network..." "The Journey is the reward" >>speff@interlog.com Info for manufacturers: http://www.trexon.com >>Embedded software/hardware/analog Info for designers: http://www.speff.com > >
On Wed, 01 Jun 2005 17:51:06 +0800, Alan <me@somewhere.com.au.invalid>
wrote:

>Have a look at: >http://www.freescale.com/files/32bit/doc/app_note/MC68EZ328KEYPAD.pdf > >5 lines can hanlde a 4 x 4 matrix >6 lines can handle a 5 x 5 matrix >7 lines can handle a 6 x 6 matrix >etc. > >I made a full 4 row querty keyboard using this scheme and it does >work.
In that example, it appears: I/O Usable Required Required Pins Switches Diodes Resistors 3 4 4 4 4 9 6 6 5 16 8 8 6 25 10 10 Half the diodes are used as a wire-OR configuration. It will work okay with n-keys, _up to a point_. The keys along the diagonal can only be detected if they are the only key pressed, because their feedback is returned to the current scan line, where it cannot be detected (read back.) The way they are detected, despite this problem, is only because of the wire-OR providing feedback, too. But that only provides a unique indication if no other keys are being pressed at the time. So, if you eliminate the diagonal keys (reducing from 16 to 12, or from 25 to 20, etc.), then n-keys can be detected. Jon
On Thu, 02 Jun 2005 17:01:10 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>On Wed, 01 Jun 2005 17:51:06 +0800, Alan <me@somewhere.com.au.invalid> >wrote: > >>Have a look at: >>http://www.freescale.com/files/32bit/doc/app_note/MC68EZ328KEYPAD.pdf >> >>5 lines can hanlde a 4 x 4 matrix >>6 lines can handle a 5 x 5 matrix >>7 lines can handle a 6 x 6 matrix >>etc. >> >>I made a full 4 row querty keyboard using this scheme and it does >>work. > >In that example, it appears: > >I/O Usable Required Required >Pins Switches Diodes Resistors > > 3 4 4 4 > 4 9 6 6 > 5 16 8 8 > 6 25 10 10 > >Half the diodes are used as a wire-OR configuration. > >It will work okay with n-keys, _up to a point_. The keys along the >diagonal can only be detected if they are the only key pressed, >because their feedback is returned to the current scan line, where it >cannot be detected (read back.) The way they are detected, despite >this problem, is only because of the wire-OR providing feedback, too. >But that only provides a unique indication if no other keys are being >pressed at the time. > >So, if you eliminate the diagonal keys (reducing from 16 to 12, or >from 25 to 20, etc.), then n-keys can be detected. > >Jon
I actually have a product which uses 20 keys in a 5 x 5 matrix with the diagonal keys eliminated. It makes it easier to detect (or rather ignore) the diagonal keys. Also I don't require roll-over for this unit. In fact two keys pressed together usually means an error condition - so ignore/alarm (except on power up when holding two specific keys down together puts the unit into programming mode). Alan -- ++++++++++++++++++++++++++++++++++++++++++ Jenal Communications Manufacturers and Suppliers of HF Selcall P O Box 1108, Morley, WA, 6943 Tel: +61 8 9370 5533 Fax +61 8 9467 6146 Web Site: http://www.jenal.com Contact: http://www.jenal.com/?p=1 ++++++++++++++++++++++++++++++++++++++++++
On Fri, 03 Jun 2005 10:15:59 +0800, Alan <me@somewhere.com.au.invalid>
wrote:

>On Thu, 02 Jun 2005 17:01:10 GMT, Jonathan Kirwan ><jkirwan@easystreet.com> wrote: > >>><snip> >> >>In that example, it appears: >> >>I/O Usable Required Required >>Pins Switches Diodes Resistors >> >> 3 4 4 4 >> 4 9 6 6 >> 5 16 8 8 >> 6 25 10 10 >> >>Half the diodes are used as a wire-OR configuration. >> >>It will work okay with n-keys, _up to a point_. The keys along the >>diagonal can only be detected if they are the only key pressed, >>because their feedback is returned to the current scan line, where it >>cannot be detected (read back.) The way they are detected, despite >>this problem, is only because of the wire-OR providing feedback, too. >>But that only provides a unique indication if no other keys are being >>pressed at the time. >> >>So, if you eliminate the diagonal keys (reducing from 16 to 12, or >>from 25 to 20, etc.), then n-keys can be detected.
>I actually have a product which uses 20 keys in a 5 x 5 matrix with >the diagonal keys eliminated. It makes it easier to detect (or rather >ignore) the diagonal keys.
Indeed. I just thought it might not be entirely clear from the PDF file you pointed at and was worth bringing to the surface in the clear light of day. Particularly since the OP was talking about "multiple key presses."
>Also I don't require roll-over for this unit. In fact two keys pressed >together usually means an error condition - so ignore/alarm (except on >power up when holding two specific keys down together puts the unit >into programming mode).
Well, the OP was talking about that feature in particular. So it doesn't hurt to point out the boundaries/limitations of the indicated solution. (And the PDF did a poor job of explaining the reasoning behind the design, in my opinion, so this aspect wasn't particularly clear to an inexperienced eye.) But since you've brought up your case, one can design such features as you probably needed using only four I/O lines instead of 5 for all 20 keys. Including detecting special key pairs. Speaking minimally. Jon
On Fri, 03 Jun 2005 03:37:48 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>On Fri, 03 Jun 2005 10:15:59 +0800, Alan <me@somewhere.com.au.invalid> >wrote: > >>On Thu, 02 Jun 2005 17:01:10 GMT, Jonathan Kirwan >><jkirwan@easystreet.com> wrote: >> >>>><snip> >>> >>>In that example, it appears: >>> >>>I/O Usable Required Required >>>Pins Switches Diodes Resistors >>> >>> 3 4 4 4 >>> 4 9 6 6 >>> 5 16 8 8 >>> 6 25 10 10 >>> >>>Half the diodes are used as a wire-OR configuration. >>> >>>It will work okay with n-keys, _up to a point_. The keys along the >>>diagonal can only be detected if they are the only key pressed, >>>because their feedback is returned to the current scan line, where it >>>cannot be detected (read back.) The way they are detected, despite >>>this problem, is only because of the wire-OR providing feedback, too. >>>But that only provides a unique indication if no other keys are being >>>pressed at the time. >>> >>>So, if you eliminate the diagonal keys (reducing from 16 to 12, or >>>from 25 to 20, etc.), then n-keys can be detected. > >>I actually have a product which uses 20 keys in a 5 x 5 matrix with >>the diagonal keys eliminated. It makes it easier to detect (or rather >>ignore) the diagonal keys. > >Indeed. I just thought it might not be entirely clear from the PDF >file you pointed at and was worth bringing to the surface in the clear >light of day. Particularly since the OP was talking about "multiple >key presses." >
Agreed - that's why I specifically noted that I ignore the diagonals, but well worth highlghting for the OP.
>>Also I don't require roll-over for this unit. In fact two keys pressed >>together usually means an error condition - so ignore/alarm (except on >>power up when holding two specific keys down together puts the unit >>into programming mode). > >Well, the OP was talking about that feature in particular. So it >doesn't hurt to point out the boundaries/limitations of the indicated >solution. (And the PDF did a poor job of explaining the reasoning >behind the design, in my opinion, so this aspect wasn't particularly >clear to an inexperienced eye.) > >But since you've brought up your case, one can design such features as >you probably needed using only four I/O lines instead of 5 for all 20 >keys. Including detecting special key pairs. Speaking minimally. > >Jon
Agreed again. There are many different ways to skin a cat (as they say). This one worked for me in this instance. Other times I have just used enough I/O pins as required for one per row and one per column (usually 3 x 4 keypads). I NEVER scan them continuously though, like some people seem to do automatically, I always wait for a keypress then scan. Alan -- ++++++++++++++++++++++++++++++++++++++++++ Jenal Communications Manufacturers and Suppliers of HF Selcall P O Box 1108, Morley, WA, 6943 Tel: +61 8 9370 5533 Fax +61 8 9467 6146 Web Site: http://www.jenal.com Contact: http://www.jenal.com/?p=1 ++++++++++++++++++++++++++++++++++++++++++
On Fri, 03 Jun 2005 12:04:34 +0800, Alan <me@somewhere.com.au.invalid>
wrote:

><snip> >>Indeed. I just thought it might not be entirely clear from the PDF >>file you pointed at and was worth bringing to the surface in the clear >>light of day. Particularly since the OP was talking about "multiple >>key presses." >> >Agreed - that's why I specifically noted that I ignore the diagonals, >but well worth highlghting for the OP. ><snip>
I must have missed the fact that you pointed it out in your first post on the matter. Jon

Memfault State of IoT Report