Post by thread:Remote keypads

Hello all. I am trying to implement several remote keypads with one central master, very similar to a home security system. Each keypad uses a 4x4 matrix keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial communications with the master. I have been gradually incorporating each of these into a PIC16C84, but a rapidly running out of I/O (only 13) pins even with the use of shift registers and a software SPI. I eventually want to migrate this to a cheaper chip, perhaps an 18-pin PIC16C5x or PIC16C62. My question is: despite their relatively low prices, the addition of the shift registers dramatically increases the real estate and wiring. Should I consider the PIC16C63A with its larger size but increased I/O capability? Then I could utilize the USART for communications and the built-in SPI. I think the additional cost of PIC16C63A would almost be offset by the additional cost of the shift registers for the PIC16C5x, let alone the reduced software complexity using the built-in USART and SPI. Of course I will not utilize many of the features of the PIC16C63A - but that does leave room for possible expansion. Any comments or suggestions? Regards, --John

> I am trying to implement several remote keypads with one central master, > very similar to a home security system. Each keypad uses a 4x4 matrix > keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial > communications with the master. I would put a processor in each keypad, and go for otherwise, minimum parts. Make sure to protect your comm lines with something robust, like 232 drivers or similar. If you take alarm wiring directly to the processor (including sensors) you will discover the pain that the alarm industry went through in the late 70s, early 80s.

>shift registers dramatically increases the real estate and wiring. Should >I consider the PIC16C63A with its larger size but increased I/O capability? >Then I could utilize the USART for communications and the built-in SPI. I >think the additional cost of PIC16C63A would almost be offset by the >additional cost of the shift registers for the PIC16C5x, let alone the >reduced software complexity using the built-in USART and SPI. Of course I >will not utilize many of the features of the PIC16C63A - but that does >leave room for possible expansion. > I would say YES, i've used the '63 and it's never let me down. I would however consider the '66, its got more memory for that future expansion we never quite forsee. John C.

I don't see why you need all those extra parts. 13 pins is plenty for what you said. The keypad and LCD and 3 LEDS and even the piezo buzzer can share pins. I bet you can do this with 12 pins total, including your 2 wire comms. You don't need a shift register. Your LCD accesses are fast enough the LEDs will barely tickle. Or put a small cap across each one to get rid of that. The piezo should probably take the 13th pin though. Even if you use the LCD register select pin, the piezo make tiny noises that will be audible. Cheers, Bob

Can a keypad share pins with the bus to an LCD? What about keypresses? How do you keep them from interfering with the LCD comms? Nuno. Bob Blick wrote: {Quote hidden}> > I don't see why you need all those extra parts. 13 pins is plenty for what > you said. The keypad and LCD and 3 LEDS and even the piezo buzzer can > share pins. I bet you can do this with 12 pins total, including your 2 > wire comms. You don't need a shift register. Your LCD accesses are fast > enough the LEDs will barely tickle. Or put a small cap across each one to > get rid of that. The piezo should probably take the 13th pin though. Even > if you use the LCD register select pin, the piezo make tiny noises that > will be audible. > > Cheers, > Bob -- ---- ~~~~~~~ ------- Nuno Filipe Freitas Pedrosa -- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454 - ~~~~ ~~ ---- spam_OUTNuno.PedrosaTakeThisOuTicn.siemens.de - ~~~~ ~~ ---- "MSWindows - Best run on a SlideShow" =======================================================================

On Thu, 13 May 1999, Nuno Pedrosa wrote: > Can a keypad share pins with the bus to an LCD? > > What about keypresses? How do you keep them from interfering with the LCD > comms? Absolutely. Either on the rows or columns of the keypad will work. If you do it on the output side it's real easy, no change in data direction. The other side is still easy, but you must tris the pins to input to read the keypad. Put a pulldown resistor on the 4 passive keypad lines, and also use a series resistor to the PIC pins. the LCD is direct to the PIC. Therefore the keypad can not out-drive the PIC when it is talking to the LCD. This is standard operating procedure for me, never waste pins between keys and LCD. The Enable pin of the LCD can not be shared. I usually don't read from the LCD, but I don't see any problem doing it with this method(but in the application mentioned, the extra pin for R/W might be hard to allocate). Put the LEDs off the PIC with their own series resistors. Even if you use low(say 220 ohm) LED resistors and high(say 10k) keypad series resistors, the keypad can still be read because the LED will only clamp to 1.6 volts or more and the PIC input high level is 1.2 volts on PORTB(at 5 volts operation). Put a series diode before each LED if you are chicken and want more margin. Or use green LEDs. Cheers, Bob

> -----Original Message----- > From: pic microcontroller discussion list > [.....PICLISTKILLspam@spam@MITVMA.MIT.EDU]On Behalf Of Nuno Pedrosa > Sent: Thursday, May 13, 1999 7:44 PM > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: Remote keypads - which PIC? > > > Can a keypad share pins with the bus to an LCD? > > What about keypresses? How do you keep them from interfering > with the LCD > comms? Be carefull !!!!!!!!!!!!! I have just designed at complete system with a '84, 8x4 keyboard and a 80x2 display. The display and keyboard share ports. Everything is okay except when i am writeing to the display and two or more keys (from different rows) are pressed at the same time. I do ofcause check if any key is pressed before i write to the display. But this is a lag of design (my fault). So please think again if it's worth it. They way i did was to share the 8 row-keyboard-pins with the 8-display-data-pins. Regards Benjamin Petersen

John, Consider the following: LCD: (4) output. data lines (shared between LCD/Keypad via Serial Expander) 1 output. RS line (shared between RS/Serial Expander) 1 output. E line (not shareable) [tie R/W line low since you only have to write to LCD] Keypad: (4) output. column driver (shared with LCD/Keypad via Serial Expander) 4 input. row lines (use RB4-RB7 to allow interrupt on change) (enable weak pullups and you save 4 resistors!) [up to 4 spst n.o. switch contacts to gnd can be added to these input lines if they are diode-isolated by placing the diode's cathode at the n.o. contact and connecting all the switch commons to a single PIC output. To read the switches, send out a low on the PIC output and then read the row data. Consider it to now be a 4x5 instead of a 4x4 "keyboard". The "extra" keys can be toggle or dip switches or even jumpers if desired. Each additional group of 4 input switches will require an additional PIC output to activate the group] RS232: 1 output. (not shared) 1 input. (not shared) Serial Expander: (1) output. for serial data (shared between RS/Serial Expander) 1 output. clock (not shared) 1 output. load signal to transfer data to latches (not shared) [These three control/data lines can supply any multiple of 8 output lines. Assuming a single set of 8 output lines, use 4 for the shared LCD/Keypad data/column lines, and the other 4 to handle up to 4 LEDs. LEDs: (4) output. derived from Serial Expander. Could also be used to control relays, etc. Still Available: 3 PIC I/O lines for anything you want. *** DUMP THE SERIAL EXPANDER *** If you want to dump the Serial Expander, that would give us 5 PIC I/O lines to use. Use 4 as shared lines to drive 4 LCD data lines and 4 Keypad column outputs. You now have one free PIC I/O pin. That's only enough to activate one LED. Can you display the other LED data on the LCD? If not, you will have to share the LEDs with LCD/Keypad (Yuck!) To allow the LEDs to be shared with the LCD/Keypad lines, we can make use of the fact that LEDs are diodes and only conduct in their forward direction (as long as you don't exceed the reverse breakdown voltage). Connect all four LED cathodes together. Connect this common cathode set to the collector of an NPN common-emitter connected transistor. Connect each LED anode through a 330 ohm resistor to a different one of the 4 Keypad column drivers. Connect the base of the transistor to a 4.7k resistor. Connect the other end of this base resistor to the last remaining PIC I/O line. The only problem with this method is that you will have to turn the LEDs off whenever you want to scan the Keypad. This is do-able, but you have to make sure that the software enables the LEDs enough of the time so that they are visible, and activates the Keypad columns enough of the time so that they capture keystrokes in a timely fashion. If you have an interrupt routine that is is entered at regular intervals due to TMR0, then you might be able to do the "task switching" in the interrupt service routine. If you run the LEDs at 50% duty cycle they will appear dim. So either use high brightness LEDs, or give the LEDs a higher duty cycle. Keypads can operate at very low duty cycles as long as you ensure that you check them every few milliseconds so you don't miss an input. Obviously, once you have detected a key input you disable the LEDs and service the Keypad. Then re-enable the LEDs. I hope this helps. Fr. Tom McGahee 13 PIC I/O lines used to implement LCD, 4x4 keypad, RS232 send AND receive, plus 4 LEDs. Note that LCD and Keypad software needs to turn off the NPN transistor before sending out LCD data or Keypad Column data, and then turn the NPN back on after first recovering the LED data. The LED and LCD data must therefore be kept in a file register. One register can hold both. In general there is no n eed to save LCD data ---------- {Quote hidden}> From: John Esposito <.....John_EspositoKILLspam.....DADEBEHRING.COM> > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU > Subject: Remote keypads - which PIC? > Date: Thursday, May 13, 1999 11:23 AM > > Hello all. > > I am trying to implement several remote keypads with one central master, > very similar to a home security system. Each keypad uses a 4x4 matrix > keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial > communications with the master. > > I have been gradually incorporating each of these into a PIC16C84, but a > rapidly running out of I/O (only 13) pins even with the use of shift > registers and a software SPI. I eventually want to migrate this to a > cheaper chip, perhaps an 18-pin PIC16C5x or PIC16C62. > > My question is: despite their relatively low prices, the addition of the > shift registers dramatically increases the real estate and wiring. Should > I consider the PIC16C63A with its larger size but increased I/O capability? > Then I could utilize the USART for communications and the built-in SPI. I > think the additional cost of PIC16C63A would almost be offset by the > additional cost of the shift registers for the PIC16C5x, let alone the > reduced software complexity using the built-in USART and SPI. Of course I > will not utilize many of the features of the PIC16C63A - but that does > leave room for possible expansion. > > Any comments or suggestions? > > > Regards, > > --John

Use diode isolation at each output pin going to the keypad and you will eliminate the problem. Fr. Tom McGahee ---------- > From: Benjamin Petersen <benjaminspam_OUTMARK-INFO.COM> > To: @spam@PICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: Remote keypads - which PIC? > Date: Friday, May 14, 1999 4:12 AM > > > {Original Message removed}

If your a fan of remote expanders: I had to get more i/o for a project I was working on with the 12C671, I already was using 2 pins for an I2C eeprom (24LC02b) and Phillips makes 8 and 16 bit quasi bi-directional i/o expanders that go on the i2c (they also have an #int line so you can detect a change on the inputs but keep them purely slave devices). I have some very tight (maybe too tight since it only works with a 1us instruction cycle i2c master mode code implementation) code I could send over. I think these expanders are called PCF8574 etc. on the phillips website. Too bad other people aren't making much of i2c technology maybe too old of a standard even at 3.4Mega-Bits On Fri, 14 May 1999, Thomas McGahee wrote: {Quote hidden}> John, > Consider the following: > LCD: > (4) output. data lines (shared between LCD/Keypad via Serial Expander) > 1 output. RS line (shared between RS/Serial Expander) > 1 output. E line (not shareable) > [tie R/W line low since you only have to write to LCD] > > Keypad: > (4) output. column driver (shared with LCD/Keypad via Serial Expander) > 4 input. row lines (use RB4-RB7 to allow interrupt on change) > (enable weak pullups and you save 4 resistors!) > [up to 4 spst n.o. switch contacts to gnd can be added > to these input lines if they are diode-isolated by > placing the diode's cathode at the n.o. contact > and connecting all the switch commons to a single PIC output. > To read the switches, send out a low on the PIC output > and then read the row data. Consider it to now be > a 4x5 instead of a 4x4 "keyboard". The "extra" keys > can be toggle or dip switches or even jumpers if desired. > Each additional group of 4 input switches will require > an additional PIC output to activate the group] > > RS232: > 1 output. (not shared) > 1 input. (not shared) > > Serial Expander: > (1) output. for serial data (shared between RS/Serial Expander) > 1 output. clock (not shared) > 1 output. load signal to transfer data to latches (not shared) > [These three control/data lines can supply any multiple > of 8 output lines. Assuming a single set of 8 output > lines, use 4 for the shared LCD/Keypad data/column lines, > and the other 4 to handle up to 4 LEDs. > > LEDs: > (4) output. derived from Serial Expander. Could also be used > to control relays, etc. > > Still Available: > 3 PIC I/O lines for anything you want. > > > *** DUMP THE SERIAL EXPANDER *** > > If you want to dump the Serial Expander, that would give us 5 PIC I/O > lines to use. Use 4 as shared lines to drive 4 LCD data lines and 4 Keypad > column outputs. > > You now have one free PIC I/O pin. That's only enough to activate one LED. > Can you display the other LED data on the LCD? If not, you will have to > share the LEDs with LCD/Keypad (Yuck!) > > To allow the LEDs to be shared with the LCD/Keypad lines, we can make > use of the fact that LEDs are diodes and only conduct in their forward > direction (as long as you don't exceed the reverse breakdown voltage). > Connect all four LED cathodes together. Connect this common cathode set > to the collector of an NPN common-emitter connected transistor. > Connect each LED anode through a 330 ohm resistor to a different one of the > 4 Keypad column drivers. Connect the base of the transistor to a 4.7k > resistor. Connect the other end of this base resistor to the last remaining > PIC I/O line. The only problem with this method is that you will have to > turn the LEDs off whenever you want to scan the Keypad. This is do-able, > but you have to make sure that the software enables the LEDs enough of the > time so that they are visible, and activates the Keypad columns enough > of the time so that they capture keystrokes in a timely fashion. > If you have an interrupt routine that is is entered at regular intervals > due to TMR0, then you might be able to do the "task switching" in the > interrupt service routine. If you run the LEDs at 50% duty cycle they will > appear dim. So either use high brightness LEDs, or give the LEDs a higher > duty cycle. Keypads can operate at very low duty cycles as long as you > ensure that you check them every few milliseconds so you don't miss > an input. Obviously, once you have detected a key input you disable > the LEDs and service the Keypad. Then re-enable the LEDs. > > I hope this helps. > Fr. Tom McGahee > > > > 13 PIC I/O lines used to implement LCD, 4x4 keypad, RS232 send AND receive, > plus 4 LEDs. > > > Note that LCD and Keypad software needs to turn off the NPN transistor > before sending out LCD data or Keypad Column data, and then turn the NPN > back on after first recovering the LED data. The LED and LCD data must therefo re > be kept in a file register. One register can hold both. In general there is no need to save LCD data {Quote hidden}> ---------- > > From: John Esposito <KILLspamJohn_EspositoKILLspamDADEBEHRING.COM> > > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > > Subject: Remote keypads - which PIC? > > Date: Thursday, May 13, 1999 11:23 AM > > > > Hello all. > > > > I am trying to implement several remote keypads with one central master, > > very similar to a home security system. Each keypad uses a 4x4 matrix > > keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial > > communications with the master. > > > > I have been gradually incorporating each of these into a PIC16C84, but a > > rapidly running out of I/O (only 13) pins even with the use of shift > > registers and a software SPI. I eventually want to migrate this to a > > cheaper chip, perhaps an 18-pin PIC16C5x or PIC16C62. > > > > My question is: despite their relatively low prices, the addition of the > > shift registers dramatically increases the real estate and wiring. Should > > I consider the PIC16C63A with its larger size but increased I/O capability? > > Then I could utilize the USART for communications and the built-in SPI. I > > think the additional cost of PIC16C63A would almost be offset by the > > additional cost of the shift registers for the PIC16C5x, let alone the > > reduced software complexity using the built-in USART and SPI. Of course I > > will not utilize many of the features of the PIC16C63A - but that does > > leave room for possible expansion. > > > > Any comments or suggestions? > > > > > > Regards, > > > > --John >

> Van: John Esposito <spamBeGoneJohn_EspositospamBeGoneDADEBEHRING.COM> > Aan: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU > Onderwerp: Remote keypads - which PIC? > Datum: donderdag 13 mei 1999 17:23 > > Hello all. Hello John, > I am trying to implement several remote keypads with one central master, > very similar to a home security system. Each keypad uses a 4x4 matrix > keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial > communications with the master. > > I have been gradually incorporating each of these into a PIC16C84, but a > rapidly running out of I/O (only 13) pins even with the use of shift > registers and a software SPI. I eventually want to migrate this to a > cheaper chip, perhaps an 18-pin PIC16C5x or PIC16C62. My first thought was how to combine all those devices. With some restrictions I came to the following, using _all_ pins. One LED could be added though :-) B0-3 A0 LCD in 4-bit mode, Write only. (B0-3 := Data, A0 := Enable) B0-3 A1 Led's (B0-3 := Anode's, A1 := common Kathode) B0-7 Keyboard (B0-3 := Out, B4-7 In -> wake-up on change enabled) A2 Buzzer (taking you use a Piezo, so multiplexing it is not possible) A3-A4 I2C (A3 := Clock, A4 := Data -> OC output & wake-up on change) By using B4-7 as inputs from the Keyboard a Wake-up function (on key-press) could be implemented. Using A4 as I2C-data input serves two functions: One: it's Open-collector (required when using I2C) and a Interrupt-possibility when detecting data-change. Greetz, Rudy Wieser

Caisson (Rudy Wieser) wrote: > B0-3 A0 LCD in 4-bit mode, Write only. (B0-3 := Data, A0 := Enable) Ah-hem. You seem to have forgotten RS. -- Cheers, Paul B.

> > I am trying to implement several remote keypads with one central master, > > very similar to a home security system. Each keypad uses a 4x4 matrix > > keypad, a 16x2 backlit LCD, 3 diodes, a piezo buzzer, and 2-wire serial > > communications with the master. http://www.dontronics.com/dt102.html may give you some ideas. Don McKenzie RemoveMEdonTakeThisOuTdontronics.com http://www.dontronics.com Don's Download Dungeon: http://www.dontronics.com/download.html Australian Electronics Ring http://www.dontronics.com/aering.html Win $500USD Cash. Micro design contest: http://www.simmstick.com

> Van: Paul B. Webster VK2BZC <paulbEraseME.....midcoast.com.au> > Aan: EraseMEPICLISTMITVMA.MIT.EDU > Onderwerp: Re: Remote keypads - which PIC? > Datum: maandag 17 mei 1999 14:42 > > Caisson (Rudy Wieser) wrote: > > > B0-3 A0 LCD in 4-bit mode, Write only. (B0-3 := Data, A0 := Enable) > > Ah-hem. You seem to have forgotten RS. You're right ... Resetting parameters. Trying to find next solution :-) Greetz, Rudy Wieser