I just cannot see how you can share the resources you are currently using to support the encoders in a shared mode. I am presuming that you are using the interrupts to detect edges of signals coming from the encoders. There is just no effective way to share these between two encoders.

If the logic you have now for supporting two encoders is working well in the product why don't you just follow my suggestion and duplicate the encoder logic in another micro controller and then have it communicate back to the first micro controller. If you use the same processor part type then the original software code to monitor the encoders should be possible to use again on the slave processor with very few changes. Any other solution and you will have to get into making many more changes to the software.

If the current processor is in a DIP-40 package you could even consider putting a socket there and then making a small adapter board with a 40-pin header on the bottom side that plugs into the socket. On this adapter board you could place two processors (presuming you are using on-board flash parts) that are in the very small TQ-48 surface mount packages. One processor can connect to most of the pins of the header to replace the functionality of the original processor. The second processor can interface to an encoder connector which you would place on the edge of the adapter board for the connection of the third encoder. Then you can make a master/slave I²C 2-wire serial bus between the two processors right on the adapter board for the two of them to communicate.

Now IF the original processor was a bit resource starved (ie, all its pins were used in the original design) you may be able to find a way to re-route some of the functions of the original processor to the new secondary processor. This would free up a corresponding number of I/Os on the replacement primary processor in order to facilitate implementation of the suggested I²C 2-wire serial bus. For example, if the original processor supported scanning of a keypad matrix on some pins, that function could easily be moved to the secondary add-on processor. The main processor would then poll for its keyboard inputs via the I²C bus using some comm protocol you would get to devise.

Michael Karas