Justin, thanks for the note...

[Justin wrote...]

> Paul pretty much summarizes everything in his reply to this.  He does a
> great job.

An understatement.

> Most of my applications do something on keypress, then sleep, so I use the
> PORTB interrupt.  If your PIC is on constantly, polling is the better
> solution.  I agree with pretty much everything Paul states, except that
> using an interrupt is undesirable.  Many applications "do something on
> keypress", so using a PORTB interrupt to start a debounce timer, and
> another interrupt when debounce complete, is a very convenient
> method for a
> lot of applications.  I usually am tight on RAM, so using none at all for
> my keypad code (except for hardware flags) is rather convenient.

Well, my idea has 2 switch blocks of 4 switches each living on an RS485 bus
and each switch block will have it's own PIC. I'm hoping I won't have a RAM
problem but, as soon I introduce the slave code, my RAM-bets may be off.

This is an automotive idea so I have a constant supply of fluky power. Once
the ignition is off, there's no need to keep the PICs hot.

[My old message cleared out]