27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

I'm working on a project that requires me to interface my microcontroller (the 68hc11e9) with a numerical keypad. What would be the best way to do this?

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Depends on how much software you want to develop. I see two options (there are many more, I'm sure) The first is software heavy, the second is hardware heavy. 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA for your keypad columns and the inputs for your keypad rows. The software heavy part is in writing the decoding and de-bouncing routines. 2) Wire your keypad matrix to a chip such as the NSC 74C922 or 74C923. These two chips do all of the decoding and debouncing in hardware, but of course, you have the extra chip and two capacitors. Then, the "AVAIL" pin can be inverted and wired to your IRQ, and the data out pins can be wired to something like PORTE. If you need your PORTE pins, then you would need to do some address decoding on the -OE pin of the '922/3 and hook the data pins to the data bus. One caution about this chip.... AVAIL=1 as long as the key is pressed. You may want to choose edge triggered IRQ if its the only device connected to IRQ so that you only get one interrupt per key press. Otherwise you will get a continual string of interrupts. As you may guess, I prefer the second option, if only because it's easy, and saves on code space. That's my two cents -Brian --- lotsofquestions02 <> wrote: > I'm working on a project that requires me to interface my > microcontroller (the 68hc11e9) with a numerical keypad. What would be > > the best way to do this? > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to: > > > __________________________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hrm... Initially, the IRQ is going to be set due to another action, then the keypad will be used. Knowing that, wouldn't it be better to use option 1? --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > Depends on how much software you want to develop. > > I see two options (there are many more, I'm sure) > The first is software heavy, the second is hardware heavy. > > 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA for > your keypad columns and the inputs for your keypad rows. The software > heavy part is in writing the decoding and de-bouncing routines. > > 2) Wire your keypad matrix to a chip such as the NSC 74C922 or 74C923. > These two chips do all of the decoding and debouncing in hardware, but > of course, you have the extra chip and two capacitors. Then, the > "AVAIL" pin can be inverted and wired to your IRQ, and the data out > pins can be wired to something like PORTE. If you need your PORTE > pins, then you would need to do some address decoding on the -OE pin of > the '922/3 and hook the data pins to the data bus. > One caution about this chip.... AVAIL=1 as long as the key is pressed. > You may want to choose edge triggered IRQ if its the only device > connected to IRQ so that you only get one interrupt per key press. > Otherwise you will get a continual string of interrupts. > > As you may guess, I prefer the second option, if only because it's > easy, and saves on code space. > > That's my two cents > > -Brian

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

I use also the 'E9 to scan two, 4 x 4 matrix keypads using the SPI interface. My keypads are of the "crossbar" matrix type. Pressing a key connects one column line to one row line for the duration of the keypress. The SPI uses MOSI and a 74HC595 for outputs to the column line and the MISO and a 74HC165 to read the resulting row inputs if a key is pressed. Advantages: 1. This approach conserves the rather limited number of DIO pins on an 'HC11E9, a critical factor in this project. 2. The SPI is fully interrupt capable, thus avoiding the need for polling overhead. 3. The approach works very reliably. Disadvantages: 1. Initializing, running an 8-bit SPI sequence, and servicing SPI interrupts limits the possible scan rate. 2. Since a total of 4 column scans are required to detect a keypress and then the keypress must be latched and debounced the final keypad response time is somewhat slow compared to a typical telephone keypad response (in the order of 50-100 mS). 3. The approach is both hardware and software intensive. If I could afford to throw away the Port pins, I would prefer to drive and read the keypad with the GPIO pins. Good luck, Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-1065 ----- Original Message ----- From: "lotsofquestions02" <> To: <> Sent: Sunday, September 15, 2002 4:34 PM Subject: [m68HC11] Interfacing > I'm working on a project that requires me to interface my > microcontroller (the 68hc11e9) with a numerical keypad. What would be > the best way to do this? > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi, I would use a matrix for 12 keys, eg: PC0,PC1,PC2,PC3 inputs for rows and PB0,PB1 and PB2 outputs for columns. If you are not goingto use A/D converter inputs PCto PC3 could be changed by PE0 to PE3. remember to use the required pullip resistors ( eg: 10 K ). Regards, Roberto Guillermo Berner Boolean General ICQ 119529928 54 11 4308 3500 54 11 4308 3700 15 5122 6095 ----- Original Message ----- From: "lotsofquestions02" <> To: <> Sent: Sunday, September 15, 2002 5:34 PM Subject: [m68HC11] Interfacing > I'm working on a project that requires me to interface my > microcontroller (the 68hc11e9) with a numerical keypad. What would be > the best way to do this? > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

You could also use an Input Compare pin to generate your interrupt. If you wanted the keypad to work only under certain conditions, you could selectively enable and disable that interrupt. Option 1 (direct keypad matrix) requires 8 IO pins for a 4x4 keypad, or 7 pins for the standard 3x4 telephone keypad. Using the 74c922 would give you up to 4x4 coverage using 5 pins, four for transferring the decoded keypress, and one for the interrupt. Again, my heavy slant for hardware is showing, but I wrote a keypad matrix decoding/debouncing routine a long time ago for some not-so-great switches, and getting the debounce period right was pretty tricky. It's a delicate balance between rejecting false multiple key presses and responding quickly to a keypress. Somehow, the 74c922 just seems to minimize response time while maximizing rejection of false keypresses. --- lotsofquestions02 <> wrote: > Hrm... Initially, the IRQ is going to be set due to another action, > then the keypad will be used. Knowing that, wouldn't it be better to > > use option 1? > > --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > > Depends on how much software you want to develop. > > > > I see two options (there are many more, I'm sure) > > The first is software heavy, the second is hardware heavy. > > > > 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA > for > > your keypad columns and the inputs for your keypad rows. The > software > > heavy part is in writing the decoding and de-bouncing routines. > > > > 2) Wire your keypad matrix to a chip such as the NSC 74C922 or > 74C923. > > These two chips do all of the decoding and debouncing in hardware, > but > > of course, you have the extra chip and two capacitors. Then, the > > "AVAIL" pin can be inverted and wired to your IRQ, and the data out > > pins can be wired to something like PORTE. If you need your PORTE > > pins, then you would need to do some address decoding on the -OE > pin of > > the '922/3 and hook the data pins to the data bus. > > One caution about this chip.... AVAIL=1 as long as the key is > pressed. > > You may want to choose edge triggered IRQ if its the only device > > connected to IRQ so that you only get one interrupt per key press. > > Otherwise you will get a continual string of interrupts. > > > > As you may guess, I prefer the second option, if only because it's > > easy, and saves on code space. > > > > That's my two cents > > > > -Brian > > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to: > > > __________________________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

From what I recall of the 'C922 when I investigated it some time ago, it has a settable sample rate that can run as high as 200 kHz. This, in part, accounts for the rapid response. I also recall that the debounce filter period is settable so it is easy to balance between response time and effective debouncing. In general, the debounce time is a function of the quality of the switches in use. I evaluated a number of different keypads for a project. I found that: 1. Simple membrane contact switches were mostly pretty crappy. The bounce time depended largely on how crisply the operator could press the pad. 2. "Snap dome" switches were the best. When pressed the dome resists movement until the dome collapses and then "snaps" down to the ON position. This produces a distinctive tactile feedback that is satisfying to the operator and a clean, crisp electrical transition with minimum bounce on make or break. I have found that one can evaluate the bounce period by setting up a test switch with the nominal resistive load and attach an oscilloscope across the contact. Trigger the scope on the beginning of the transition period. Activate the switch several times and observe the worst case contact bounce period. Your hold time for the debounce decision must be at least this long. Good luck, Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-1065 ----- Original Message ----- From: "Brian Moerdyk" <> To: <> Sent: Monday, September 16, 2002 11:48 PM Subject: Re: [m68HC11] Re: Interfacing > You could also use an Input Compare pin to generate your interrupt. > If you wanted the keypad to work only under certain conditions, you > could selectively enable and disable that interrupt. > > Option 1 (direct keypad matrix) requires 8 IO pins for a 4x4 keypad, or > 7 pins for the standard 3x4 telephone keypad. > > Using the 74c922 would give you up to 4x4 coverage using 5 pins, four > for transferring the decoded keypress, and one for the interrupt. > > Again, my heavy slant for hardware is showing, but I wrote a keypad > matrix decoding/debouncing routine a long time ago for some > not-so-great switches, and getting the debounce period right was pretty > tricky. It's a delicate balance between rejecting false multiple key > presses and responding quickly to a keypress. > > Somehow, the 74c922 just seems to minimize response time while > maximizing rejection of false keypresses. > > --- lotsofquestions02 <> wrote: > > Hrm... Initially, the IRQ is going to be set due to another action, > > then the keypad will be used. Knowing that, wouldn't it be better to > > > > use option 1? > > > > --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > > > Depends on how much software you want to develop. > > > > > > I see two options (there are many more, I'm sure) > > > The first is software heavy, the second is hardware heavy. > > > > > > 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA > > for > > > your keypad columns and the inputs for your keypad rows. The > > software > > > heavy part is in writing the decoding and de-bouncing routines. > > > > > > 2) Wire your keypad matrix to a chip such as the NSC 74C922 or > > 74C923. > > > These two chips do all of the decoding and debouncing in hardware, > > but > > > of course, you have the extra chip and two capacitors. Then, the > > > "AVAIL" pin can be inverted and wired to your IRQ, and the data out > > > pins can be wired to something like PORTE. If you need your PORTE > > > pins, then you would need to do some address decoding on the -OE > > pin of > > > the '922/3 and hook the data pins to the data bus. > > > One caution about this chip.... AVAIL=1 as long as the key is > > pressed. > > > You may want to choose edge triggered IRQ if its the only device > > > connected to IRQ so that you only get one interrupt per key press. > > > Otherwise you will get a continual string of interrupts. > > > > > > As you may guess, I prefer the second option, if only because it's > > > easy, and saves on code space. > > > > > > That's my two cents > > > > > > -Brian > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > > __________________________________________________ > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Friends, I used the 922 very much some 25 years ago. No problem with the chip. The oscillator can be trimmed with a single capacitor ( I never needed to do that ). It is and was expensive chip. Remember that your finger takes more than 20 ms to do something. So there is really no debouncing problem at all. The conductive rubber switches ( ~600 Ohm contact ) can also be used in matrix with the 922. You will have to increase current ( no more that 10 mA ! ) per switch, so there is a need to adjust pullup R's values. I don't know what the particular system you are talking about, but do we normally need a 922 ? SPI or port matrix methods ( and several other combinations) can be driven implementing a timer interrupt service routine tick. You need a very simple state machine to recognize 3 or 4 different states of your keyboard ( Scan-> Bounce1->Bounce2->Release) that appears to the program as an external 922 working for you all the time and living a key code and setting a flag for key ready. You can also include this machine in the same thread of a larger interrupt service task. You can adjust bouncing time when pressing, releasing, do multispeed key autorepeat, key rollover, etc. If you don't have critical CPU timing envolved, there is no need of 922's. Regards, Roberto Guillermo Berner Boolean General ICQ 119529928 54 11 4308 3500 54 11 4308 3700 15 5122 6095 ----- Original Message ----- From: "Robert Smith" <> To: <> Sent: Tuesday, September 17, 2002 8:43 AM Subject: Re: [m68HC11] Re: Interfacing > From what I recall of the 'C922 when I investigated it some time ago, it has > a settable sample rate that can run as high as 200 kHz. This, in part, > accounts for the rapid response. I also recall that the debounce filter > period is settable so it is easy to balance between response time and > effective debouncing. > > In general, the debounce time is a function of the quality of the switches > in use. I evaluated a number of different keypads for a project. I found > that: > > 1. Simple membrane contact switches were mostly pretty crappy. The bounce > time depended largely on how crisply the operator could press the pad. > > 2. "Snap dome" switches were the best. When pressed the dome resists > movement until the dome collapses and then "snaps" down to the ON position. > This produces a distinctive tactile feedback that is satisfying to the > operator and a clean, crisp electrical transition with minimum bounce on > make or break. > > I have found that one can evaluate the bounce period by setting up a test > switch with the nominal resistive load and attach an oscilloscope across the > contact. Trigger the scope on the beginning of the transition period. > Activate the switch several times and observe the worst case contact bounce > period. > > Your hold time for the debounce decision must be at least this long. > > Good luck, Bob Smith > --- Avoid computer viruses, Practice safe hex --- > > -- Specializing in small, cost effective > embedded control systems -- > Robert L. (Bob) Smith > Smith Machine Works, Inc. > 9900 Lumlay Road > Richmond, VA 23236 804/745-1065 > > ----- Original Message ----- > From: "Brian Moerdyk" <> > To: <> > Sent: Monday, September 16, 2002 11:48 PM > Subject: Re: [m68HC11] Re: Interfacing > > You could also use an Input Compare pin to generate your interrupt. > > If you wanted the keypad to work only under certain conditions, you > > could selectively enable and disable that interrupt. > > > > Option 1 (direct keypad matrix) requires 8 IO pins for a 4x4 keypad, or > > 7 pins for the standard 3x4 telephone keypad. > > > > Using the 74c922 would give you up to 4x4 coverage using 5 pins, four > > for transferring the decoded keypress, and one for the interrupt. > > > > Again, my heavy slant for hardware is showing, but I wrote a keypad > > matrix decoding/debouncing routine a long time ago for some > > not-so-great switches, and getting the debounce period right was pretty > > tricky. It's a delicate balance between rejecting false multiple key > > presses and responding quickly to a keypress. > > > > Somehow, the 74c922 just seems to minimize response time while > > maximizing rejection of false keypresses. > > > > --- lotsofquestions02 <> wrote: > > > Hrm... Initially, the IRQ is going to be set due to another action, > > > then the keypad will be used. Knowing that, wouldn't it be better to > > > > > > use option 1? > > > > > > --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > > > > Depends on how much software you want to develop. > > > > > > > > I see two options (there are many more, I'm sure) > > > > The first is software heavy, the second is hardware heavy. > > > > > > > > 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA > > > for > > > > your keypad columns and the inputs for your keypad rows. The > > > software > > > > heavy part is in writing the decoding and de-bouncing routines. > > > > > > > > 2) Wire your keypad matrix to a chip such as the NSC 74C922 or > > > 74C923. > > > > These two chips do all of the decoding and debouncing in hardware, > > > but > > > > of course, you have the extra chip and two capacitors. Then, the > > > > "AVAIL" pin can be inverted and wired to your IRQ, and the data out > > > > pins can be wired to something like PORTE. If you need your PORTE > > > > pins, then you would need to do some address decoding on the -OE > > > pin of > > > > the '922/3 and hook the data pins to the data bus. > > > > One caution about this chip.... AVAIL=1 as long as the key is > > > pressed. > > > > You may want to choose edge triggered IRQ if its the only device > > > > connected to IRQ so that you only get one interrupt per key press. > > > > Otherwise you will get a continual string of interrupts. > > > > > > > > As you may guess, I prefer the second option, if only because it's > > > > easy, and saves on code space. > > > > > > > > That's my two cents > > > > > > > > -Brian > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to:

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

*sigh* Yaknow, it really doesn't take much to confuse me. :( I've had to make some adjustments to what I'm planning to do. The keypad is the "centre piece". I'd like to experiment with both the hardware debouncing/decoding and the software decoding/debounce... from what I"m understanding, the hardware seems to be the best way to go, since the software is touchy when trying to get the debounce right. One thing I'm NOT understanding is why I should use input AND outputs for the keypad. (Someone had mentioned using inputs for the rows and outputs for the columns. Why wouldn't I use inputs for both the rows and columns? --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > You could also use an Input Compare pin to generate your interrupt. > If you wanted the keypad to work only under certain conditions, you > could selectively enable and disable that interrupt. > > Option 1 (direct keypad matrix) requires 8 IO pins for a 4x4 keypad, or > 7 pins for the standard 3x4 telephone keypad. > > Using the 74c922 would give you up to 4x4 coverage using 5 pins, four > for transferring the decoded keypress, and one for the interrupt. > > Again, my heavy slant for hardware is showing, but I wrote a keypad > matrix decoding/debouncing routine a long time ago for some > not-so-great switches, and getting the debounce period right was pretty > tricky. It's a delicate balance between rejecting false multiple key > presses and responding quickly to a keypress. > > Somehow, the 74c922 just seems to minimize response time while > maximizing rejection of false keypresses. > > --- lotsofquestions02 <lotsofquestions02@h...> wrote: > > Hrm... Initially, the IRQ is going to be set due to another action, > > then the keypad will be used. Knowing that, wouldn't it be better to > > > > use option 1? > > > > --- In m68HC11@y..., Brian Moerdyk <bmoerdyk@y...> wrote: > > > Depends on how much software you want to develop. > > > > > > I see two options (there are many more, I'm sure) > > > The first is software heavy, the second is hardware heavy. > > > > > > 1) Wire your keypad matrix to PORTA. Use the output pins of PORTA > > for > > > your keypad columns and the inputs for your keypad rows. The > > software > > > heavy part is in writing the decoding and de-bouncing routines. > > > > > > 2) Wire your keypad matrix to a chip such as the NSC 74C922 or > > 74C923. > > > These two chips do all of the decoding and debouncing in hardware, > > but > > > of course, you have the extra chip and two capacitors. Then, the > > > "AVAIL" pin can be inverted and wired to your IRQ, and the data out > > > pins can be wired to something like PORTE. If you need your PORTE > > > pins, then you would need to do some address decoding on the - OE > > pin of > > > the '922/3 and hook the data pins to the data bus. > > > One caution about this chip.... AVAIL=1 as long as the key is > > pressed. > > > You may want to choose edge triggered IRQ if its the only device > > > connected to IRQ so that you only get one interrupt per key press. > > > Otherwise you will get a continual string of interrupts. > > > > > > As you may guess, I prefer the second option, if only because it's > > > easy, and saves on code space. > > > > > > That's my two cents > > > > > > -Brian > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > To unsubscribe from this group, send an email to: > > m68HC11-unsubscribe@y... > > > > > > > > > > > > __________________________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

well, by using the SPI along with the 74C922 one can reduce the disadvantages stated by Robert to only one disadvantage: The approach is Hardware Intensive. Let me explain my idea: In the past, I used the MM74C922 chip to reduce software debouncing and scanning and DIO pins in the microcontroller. When I used this method, I was just on the way to study the SPI system. Now that I'm familiar with the SPI, I can mix Robert's idea with Brian's idea to produce a new suggestion that, in my opinion, would reduce software requirements and DIO pins of the microcontroller. Now let's get into the subject: you can connect the keypad to the 74C922 chip which does all the required scanning and debouncing jobs, then the 74C922 chip can be connected to a parallel in/serial out shift register that interfaces this system to the SPI module of the microcontroller. Finally, if this idea has some "bugs", I will be glad to hear comments about it. Best Regards, Roger Tannous. Lebanon. Roger= "Thinking Motorola"; _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi all, The most straight-forward approach to decode switches, is simply to add a pull-up to one side of the switch, and connect it to an input pin on the CPU while grounding the other contact. Unfortunately, this approach takes one input for every switch you want to include in your system. An alternative approach, suggested by many in previous mail, is the use of row-column decoding. In this scheme the keys are organized in as close to square matrix as possible. Keys are decoded by pulsing one row at a time while monitoring all of the columns (or vice versa, the assignment is arbitrary). While this scheme requires some passive diodes to prevent shorting outputs together in the event of multiple (simultaneous) key presses, the number of CPU signals required to decode N keys is reduced to 2*CEIL(SQRT(N)) compared to N. For instance, a 16 key keypad needs only 8 I/O pins, whereas it would require 16 for the straight-forward approach. Obviously, as N increases, the hardware savings quickly become obvious. Scott *sigh* Yaknow, it really doesn't take much to confuse me. :( I've had to make some adjustments to what I'm planning to do. The keypad is the "centre piece". I'd like to experiment with both the hardware debouncing/decoding and the software decoding/debounce... from what I"m understanding, the hardware seems to be the best way to go, since the software is touchy when trying to get the debounce right. One thing I'm NOT understanding is why I should use input AND outputs for the keypad. (Someone had mentioned using inputs for the rows and outputs for the columns. Why wouldn't I use inputs for both the rows and columns? [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Scott, I think that it is very important to evaluate the cost / performance math.It all depends on what you pretend from your hardware / software balance. For years I have used the old Motorola's MEK6800D2 evaluation kit keyboard / display matrix hardware that combined 24 keys and 6 seven segment LED displays as a good example of cost / performance ( 14 discrete transistors). If one can afford the '922 cost, it is OK to use it. If your software is so time critical that you cannot handle a keyboard matrix ( it may happen...) then you need the 922 or similar solution,or you are wrong with the choosen MPU. Regards, Roberto Guillermo Berner Boolean General ICQ 119529928 54 11 4308 3500 54 11 4308 3700 15 5122 6095 ----- Original Message ----- From: "Grodevant, Scott" <> To: <> Sent: Monday, September 23, 2002 9:40 AM Subject: RE: [m68HC11] Re: Interfacing > Hi all, > > The most straight-forward approach to decode switches, is simply to add a > pull-up to one side of the switch, and connect it to an input pin on the CPU > while grounding the other contact. Unfortunately, this approach takes one > input for every switch you want to include in your system. > > An alternative approach, suggested by many in previous mail, is the use of > row-column decoding. In this scheme the keys are organized in as close to > square matrix as possible. Keys are decoded by pulsing one row at a time > while monitoring all of the columns (or vice versa, the assignment is > arbitrary). While this scheme requires some passive diodes to prevent > shorting outputs together in the event of multiple (simultaneous) key > presses, the number of CPU signals required to decode N keys is reduced to > 2*CEIL(SQRT(N)) compared to N. For instance, a 16 key keypad needs only 8 > I/O pins, whereas it would require 16 for the straight-forward approach. > Obviously, as N increases, the hardware savings quickly become obvious. > > Scott > *sigh* Yaknow, it really doesn't take much to confuse me. :( > > I've had to make some adjustments to what I'm planning to do. The > keypad is the "centre piece". I'd like to experiment with both the > hardware debouncing/decoding and the software decoding/debounce... > from what I"m understanding, the hardware seems to be the best way to > go, since the software is touchy when trying to get the debounce > right. > > One thing I'm NOT understanding is why I should use input AND outputs > for the keypad. (Someone had mentioned using inputs for the rows and > outputs for the columns. Why wouldn't I use inputs for both the rows > and columns? > [Non-text portions of this message have been removed] > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Roberto, Agreed. I was more speaking to the mechanics of doing the decoding rather than implementation methods. Nothing wrong with using a chip that does the decoding. Like you say, economics in the end dictates the best answer. Best regards, Scott -----Original Message----- From: Boolean General [mailto:] Sent: Monday, September 23, 2002 9:10 AM To: Subject: Re: [m68HC11] Re: Interfacing Scott, I think that it is very important to evaluate the cost / performance math.It all depends on what you pretend from your hardware / software balance. For years I have used the old Motorola's MEK6800D2 evaluation kit keyboard / display matrix hardware that combined 24 keys and 6 seven segment LED displays as a good example of cost / performance ( 14 discrete transistors). If one can afford the '922 cost, it is OK to use it. If your software is so time critical that you cannot handle a keyboard matrix ( it may happen...) then you need the 922 or similar solution,or you are wrong with the choosen MPU. [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

See below: --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-1065 ----- Original Message ----- From: "Grodevant, Scott" <> To: <> Sent: Monday, September 23, 2002 8:40 AM Subject: RE: [m68HC11] Re: Interfacing > Hi all, > > The most straight-forward approach to decode switches, is simply to add a > pull-up to one side of the switch, and connect it to an input pin on the CPU > while grounding the other contact. Unfortunately, this approach takes one > input for every switch you want to include in your system. > > An alternative approach, suggested by many in previous mail, is the use of > row-column decoding. In this scheme the keys are organized in as close to > square matrix as possible. Keys are decoded by pulsing one row at a time > while monitoring all of the columns (or vice versa, the assignment is > arbitrary). The usual scheme is to drive the columns low, one at a time and attach pull ups to the row outputs. Then, as you drive the columns low one at a time you read all the rows after the columns have time to settle. Eventually you will find that one of the rows goes low when the key is pressed. > While this scheme requires some passive diodes to prevent > shorting outputs together in the event of multiple (simultaneous) key > presses, There is no need for diodes. It is true that if multiple keys are pressed in any given column, you will have two or more rows going low after that column is driven, but this would be nonsense input and can be sorted out and simply ignored in software. the number of CPU signals required to decode N keys is reduced to > 2*CEIL(SQRT(N)) compared to N. For instance, a 16 key keypad needs only 8 > I/O pins, whereas it would require 16 for the straight-forward approach. > Obviously, as N increases, the hardware savings quickly become obvious. This elaborate statement can be reduced to saying, "You need one output pin per column and one input pin per row", nothing more or less. > Scott > *sigh* Yaknow, it really doesn't take much to confuse me. :( > > I've had to make some adjustments to what I'm planning to do. The > keypad is the "centre piece". I'd like to experiment with both the > hardware debouncing/decoding and the software decoding/debounce... > from what I"m understanding, the hardware seems to be the best way to > go, since the software is touchy when trying to get the debounce > right. > > One thing I'm NOT understanding is why I should use input AND outputs > for the keypad. (Someone had mentioned using inputs for the rows and > outputs for the columns. Why wouldn't I use inputs for both the rows > and columns? > [Non-text portions of this message have been removed] > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi All and Bob, These days with newer CPUs whose outputs can be programmed to be active low, or high-Z that's a good idea. To say it is the usual scheme is somewhat misleading, since there have been several approaches suggested in this thread already. Care must be taken that the column outputs are programmed to be low outputs or high-Z, e.g. that you are changing the direction bits and not the port bits for the column signals. If they (columns) are allowed to be high outputs, then the diodes are still called for (since two simultaneous key presses of keys in the same row will short a high output to a low output resulting in excess current flow). I hadn't rethought the problem since my early days when outputs could not be programmed to be three-state. Back then, I never liked the notion of shorting two CPU outputs even under non-typical fault conditions such as two keys being pressed. As far as my elaborate statement goes, it says a little more than the simplified version. The simplified version gives no indication of how many rows or columns one might need for N keys. While the notion of decoding keys in a row and column format is obvious to many of us, it wasn't too obvious to the person asking the original question. That being the case, the number of rows and columns needed for N keys probably isn't either. Further it implies that a square matrix is the most efficient to minimize the number of CPU signals. That can't be implied from the "simplified" statement. In fact, with one column permanently tied active, your simplified statement breaks down into the straight-forward approach I first mentioned. Regards, Scott > Hi all, > > The most straight-forward approach to decode switches, is simply to add a > pull-up to one side of the switch, and connect it to an input pin on the CPU > while grounding the other contact. Unfortunately, this approach takes one > input for every switch you want to include in your system. > > An alternative approach, suggested by many in previous mail, is the use of > row-column decoding. In this scheme the keys are organized in as close to > square matrix as possible. Keys are decoded by pulsing one row at a time > while monitoring all of the columns (or vice versa, the assignment is > arbitrary). The usual scheme is to drive the columns low, one at a time and attach pull ups to the row outputs. Then, as you drive the columns low one at a time you read all the rows after the columns have time to settle. Eventually you will find that one of the rows goes low when the key is pressed. > While this scheme requires some passive diodes to prevent > shorting outputs together in the event of multiple (simultaneous) key > presses, There is no need for diodes. It is true that if multiple keys are pressed in any given column, you will have two or more rows going low after that column is driven, but this would be nonsense input and can be sorted out and simply ignored in software. the number of CPU signals required to decode N keys is reduced to > 2*CEIL(SQRT(N)) compared to N. For instance, a 16 key keypad needs only 8 > I/O pins, whereas it would require 16 for the straight-forward approach. > Obviously, as N increases, the hardware savings quickly become obvious. This elaborate statement can be reduced to saying, "You need one output pin per column and one input pin per row", nothing more or less. > Scott [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

well, i'm resending this message, because my reply is still the same, and i felt that it didn't get any echo anywhere; so, can i expect comments about my idea?? Here is my previous message: From: "roger tannous" <> Reply-To: To: Subject: Re: [m68HC11] Interfacing Date: Sat, 21 Sep 2002 16:06:16 +0300 well, by using the SPI along with the 74C922 one can reduce the disadvantages stated by Robert to only one disadvantage: The approach is Hardware Intensive. Let me explain my idea: In the past, I used the MM74C922 chip to reduce software debouncing and scanning and DIO pins in the microcontroller. When I used this method, I was just on the way to study the SPI system. Now that I'm familiar with the SPI, I can mix Robert's idea with Brian's idea to produce a new suggestion that, in my opinion, would reduce software requirements and DIO pins of the microcontroller. Now let's get into the subject: you can connect the keypad to the 74C922 chip which does all the required scanning and debouncing jobs, then the 74C922 chip can be connected to a parallel in/serial out shift register that interfaces this system to the SPI module of the microcontroller. Finally, if this idea has some "bugs", I will be glad to hear comments about it. Best Regards, Roger Tannous. Lebanon. Roger= "Thinking Motorola"; _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Roger-- Still can't understand why you would use the 74C922 at all, because-- as others have pointed out-- it's really not too hard to do the job in software with minimal external passive components, so the '922 just adds cost. There doesn't seem to be anything the '922 does, that can't readily be done with code-- more flexibly (such as, tuning debounce times). And even if my 68HC11 ran out of port pins, and I needed to use SPI in order to get access to more I/O, I would use 74HC165 and 74HC595 (or 74HCT4094) and still save somewhere around $3 per board in 100-1000 lots. Fairchild shows the '922 at about $6 in 1,000 lots-- more than most small microcontrollers these days-- but Digi-Key shows them at $4 and change. Doing the shift register AND the 74C922 just seems to compound the overkill, in my opinion. Scanning and debouncing just isn't that hard to do in software.... AN463 shows one example (for a 68HC05)-- it uses a keyboard interrupt feature, but you can easily poll the keyboard fast enough without interrupts-- and there are probably other app notes on this subject as well. Hope this is helpful and not just argumentative.... Best regards, Kerry Berland Silicon Engines 2101 Oxford Road Des Plaines, IL 60018 USA 847-803-6860 Fax 847-803-6870 ----- Original Message ----- From: roger tannous To: Sent: Monday, September 23, 2002 5:16 PM Subject: Re: [m68HC11] Interfacing well, i'm resending this message, because my reply is still the same, and i felt that it didn't get any echo anywhere; so, can i expect comments about my idea?? Here is my previous message: From: "roger tannous" <> Reply-To: To: Subject: Re: [m68HC11] Interfacing Date: Sat, 21 Sep 2002 16:06:16 +0300 well, by using the SPI along with the 74C922 one can reduce the disadvantages stated by Robert to only one disadvantage: The approach is Hardware Intensive. Let me explain my idea: In the past, I used the MM74C922 chip to reduce software debouncing and scanning and DIO pins in the microcontroller. When I used this method, I was just on the way to study the SPI system. Now that I'm familiar with the SPI, I can mix Robert's idea with Brian's idea to produce a new suggestion that, in my opinion, would reduce software requirements and DIO pins of the microcontroller. Now let's get into the subject: you can connect the keypad to the 74C922 chip which does all the required scanning and debouncing jobs, then the 74C922 chip can be connected to a parallel in/serial out shift register that interfaces this system to the SPI module of the microcontroller. Finally, if this idea has some "bugs", I will be glad to hear comments about it. Best Regards, Roger Tannous. Lebanon. Roger= "Thinking Motorola"; _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To unsubscribe from this group, send an email to: Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

hmmm, I understood your idea; well, I thought like this because I didn't think like you did in the beginning, I didn't think of big quantities since I don't work in a company. And although the first email in this topic mentioned an E9 microcontroller, I still think of the A1P I have (I have 2 HC11A1P, 2 HC908GP32 and 2 HC912B32 -- but in this mailing list, I only think about the HC11 this list is made for) and its small memory (256 bytes of EEPROM), that's why I prefer a heavy hardware and because many of my projects didn't fit inside the 256 bytes of the HC11A1P. Best Regards, Roger Tannous. From: "Kerry Berland" <> Reply-To: To: <> Subject: Re: [m68HC11] Interfacing Date: Mon, 23 Sep 2002 18:55:56 -0500 Roger-- Still can't understand why you would use the 74C922 at all, because-- as others have pointed out-- it's really not too hard to do the job in software with minimal external passive components, so the '922 just adds cost. There doesn't seem to be anything the '922 does, that can't readily be done with code-- more flexibly (such as, tuning debounce times). And even if my 68HC11 ran out of port pins, and I needed to use SPI in order to get access to more I/O, I would use 74HC165 and 74HC595 (or 74HCT4094) and still save somewhere around $3 per board in 100-1000 lots. Fairchild shows the '922 at about $6 in 1,000 lots-- more than most small microcontrollers these days-- but Digi-Key shows them at $4 and change. Doing the shift register AND the 74C922 just seems to compound the overkill, in my opinion. Scanning and debouncing just isn't that hard to do in software.... AN463 shows one example (for a 68HC05)-- it uses a keyboard interrupt feature, but you can easily poll the keyboard fast enough without interrupts-- and there are probably other app notes on this subject as well. Hope this is helpful and not just argumentative.... Best regards, Kerry Berland Silicon Engines 2101 Oxford Road Des Plaines, IL 60018 USA 847-803-6860 Fax 847-803-6870 _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )