Keypad musing

A project log for Discrete YASEP

a 16-bits YASEP computer (mostly) made of DIP/SOIC chips like in the 70s and 80s... with 2010's twists!

yann-guidon-ygdesYann Guidon / YGDES 10/22/2015 at 04:280 Comments

(Note: Interesting read but superseded)

(note 2, 20151030 : a similar idea is implemented at but with a 16->1 multiplexer)

It does not seem reasonable to implement capacitive keys (yet).

I have to stick to dumb logic and smart ideas.

There are not many keys so the required logic will not be too hard. There is the hex keypad and the command keys, overall 32 keys or less. It does not seem necessary to use an array for the scan, particularly because the "priority encoder" logic could become tricky. (Update: later, I found the 74HC148 priority encoder in a local store...)

Fortunately the user interface does not need simultaneous key presses. The keys count could even be lowered if the "command" keys are "folded" into or "shared" with the hex keys. But I'm not making one of those electronic music instruments with weird "modes" and hidden/obscure combinations to access menus... I know that some love minimalism like #Unhappy Hacking Keyboard but I can live with more keys, the more the better. Where is the "homebrew appeal" or the "physical computing charm" otherwise ? Give me keys !

So the challenge is to 1) scan all the keys 2) provide a reliable information when more than one key is pressed 3) get the timings right.

The starting point is the scan of the keys. We can use the running counters from the display board's CD4040 or even generate a local lower frequency with another one (so there is only one signal to send from P1B to P1A).

OK now we have a 5-bits free-running counter that wraps around at least 100 times per second. The output goes to several 74HC138, each output is connected to a single key. The 3->8 decoders can be scattered across the PCB, we are not constrained by the geometry of an array.

The 74HC138 outputs are normally held high. One output goes low at a time. So when the four 74HC138 are connected to the 5-bits counter, all the outputs will go low in sequence, one after another.

Then the main "trick" is to make a big "wired OR" circuit with all the outputs. Each output is followed by a diode in series with one of the keys. The other terminal of all the keys is connected to a common "sense" signal, pulled-up by a 10K resistor.

Now we get a low pulse on the common signal, each time a key is pressed and it is being probed. The next step is to sample this signal.

The common signal is combined with the input frequency to create a rising edge in the middle of the current cycle, so the counter's value can be stored in a 74HC273. This value is updated each time a pressed key is probed so the '273 could oscillate between two or more values.

The priority encoder is implemented by sampling the '273 at the end of a scan cycle. If several keys are pressed simultaneously, only the key with the highest scan code will be considered.

A more compact version is possible if the scan counter's clock can be inhibited (let's indulge in clock-gating). The CD4040's clock input is ANDed with the pulled-up common signal:

Prioritisation of the scan code is inherent and "first press first serve". The code is send on press, not release.

The other hidden advantage is the ease of implementing a debounce circuit: a simple capacitor (10µF alu ?) between the common signal and 0V, to delay the rising edge. The common signal should be buffered with a Schmitt Trigger circuit to prevent parasites. The output of this buffer can then send a strobe to the other circuits, telling them to sample the counter's value.

It's not very complex :-) The only drawback is we can't use this easily to control the TIL311's blanking to reduce the current and luminosity.

PS: I just found 20years old scraps from an even older keyboard that I completely took apart (I think I wanted to make a MC6809 SBC as a teen). The keys are bulky but they contain a diode ! The first prototype will be awesome and clicky :-D