The reason I said that the E line should be unique is as follows:

1) I reasoned that the original poster was using port pins as general I/O as opposed to some type of External Bus method.

2) I also understood that KEYPAD was a rows and columns matrix that requires scanning.

One wants to ensure that while some I/O pins are used to scan the keypad that such scanning activity (with or without some switches closed) does not look like a read or write cycle to the LCD module.

One also wants to ensure that an apparent short of two of the port pins via one or more closed switches in the keypad matrix does not disturb the ability to communicate to the LCD module.

-------------

I have seen many a scheme used to share I/O pins on microcontrollers between separate external functions. As a matter of fact I have had to resort to such techniques in some of my own projects too.

That said however sharing I/O pins does present an increased challenge to the microcontroller firmware programmer. In particular the software may have added complication to deal with the fact that hardare I/O lines are shared. This can get into some complicated programming if say a keypad scanning algorithm wants to be run in a foreground timer interrupt context and at the same time the mainline context is trying to write to the LCD module.

Also note that I have seen many microcontroller designs wherein I/O pin sharing was used only to see that the designer has had to add a handful of external chips to sort out the contention issues that arise from such shared I/O. These days when it is possible to purchase increased pin count controllers it is often hard to justify the use of additional external chips just to save a few pins on the processor package. And with the ease of making a design "distributed" (due to chips with wholly contained FLASH and RAM) it is often the most cost effective to partition the design into multiple controllers and have them communicate by efficient narrow serial busses such as I²C.

Michael Karas