Hex keyboard decoder
Ok, now if you've ever used a hex-keyboard, you'll be thinking: "why a decoder? Isn't a simple program enough to get what you want?". Well, as I've mentioned elsewhere, there was insane static and interference in the room we worked. I never figured out why exactly, but there was enough to make buttons, loose wires and keyboards behave erratically - so much I had to often connect pull-down and pull-up resistors to accommodate the issues. I thought my hands had way too much static so I occasionally tried to get it off by touching a wall or something, but to little success. Sometimes, getting a finger close to a pushbutton would activate it, and even when I switched to a loose wire connected to power or ground whenever I wanted to use it as a trigger, the same thing would happen - I move my hand close to the wire and it made the microcontroller react. Same thing with the keyboard - not to mention I was using the ECIO microcontrollers, by Matrix Multimeda. Now they have a lot of ready-made routines for stuff like keyboards and LCDs, which is handy, but when my keyboard didn't work, I didn't really feel plowing through pages of C code for PICs would be a time-efficient solution. So I made the decoder to both prevent strange activations and scan it on its own, saving pins, MCU processing time and making it finally predictable.
Here, at its output is a 7-segment display showing the number of the cell that has been pushed (it doesn't interpret the keys as they are shown in the picture - it's pointless to handle that through circuitry in this case), 4 LEDs showing the same number in binary and an extra LED that indicated whether a button is being pressed or not. Since there are 16 different keys and 4 bits can indicate 16 different states, there is not state to indicate nothing is being pressed - thus the 5th output is charged with this duty. An additional advantage of this, is that the 5th output can be connected to an interrupt, making the reading of numbers from the microcontroller as economic in processing time as possible. You might be able to tell I am particularly proud of this one :). Another interesting advantage is that the scanning time is independent of this circuit or the microcontroller (given maximum switching times of the ICs involved ofcourse). As long as its fast enough, it does its job just fine.
Now, granted, this circuit has a lot of gates. It was done in a bit of a hurry as I was counting on the ready-made routines to work and when they didn't I had to put this together as fast as possible so the rest of the circuitry could be controlled through the MCU, which was the point all along. We could have just had dip switches instead, but that would be like using a 60's computer with punching cards - not a very interesting prospect, since that would look terrible at the presentation anyway.