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: > 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 > ---------- > > From: John Esposito > > To: PICLIST@MITVMA.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 >