2
\$\begingroup\$

For my first hardware hack I'm taking a stab at a 'mechanical keyboard from scratch' (where scratch means individual components).

I plan to use a teensy++ board (16MHz) and was wondering about how to scan for key presses, so far I was thinking of using a grid (matrix) for the keys, every row is an out pin and every column is a in pin, the switches connect them (along with a diode for limiting the direction of current to lessen ghosting).

So there would be a scanning cycle, during which a column is set to high (or low, depending) and then every row is tested for this value. My question concerns whether or not this would be accurate enough, it means that the switch has to be closed at the exact moment that row and column are checked otherwise the key wont be registered at all. Is this how it is done or is there some much better approach?

There is also the issue of key bounce, so either a delay between checking the same key (could be a result of the scanning loop) and/or a counter where a certain key to be activated a number of times.

Thanks in advance :)

\$\endgroup\$
5
\$\begingroup\$

What you describe is basically the way the 8 bit micros used to do it, before keyboards all got dedicated microcontrollers (which just did the same thing anyway).

Human user keyboard input isn't very fast. If you scan the key matrix once every 20 msec, and make it a rule that you only count the key as being pressed if you see it pressed on two consecutive scans, you will eliminate key-bounce.

\$\endgroup\$
  • \$\begingroup\$ That deals with bounce. But with each key press the key is only activated for a short period of time (depending on how long the key takes to get from the actuation point to the reset point) and if the scanner doesn't check the key during this time period then the key press will be missed, using my method will I be able to check it sufficiently fast enough that a user tapping the key very lightly? (the key activates and resets halfway down, so if tapped lightly it could quickly fluctuate on and off) \$\endgroup\$ – cjh Feb 22 '11 at 2:26
  • 5
    \$\begingroup\$ People don't type nearly as fast as you think. Think of it this way - 20ms pressed and 20ms released would give a key press a period of 25Hz. Can you hit a key 25 times in one second? I can get 5 or 7 presses in a second here. That key is down for at least 50ms. Even light presses will be down for longer than you think. \$\endgroup\$ – AngryEE Feb 22 '11 at 3:12
  • \$\begingroup\$ The problem might arise if you are trying to determine which keys were pressed in what order, true, a user pressing a single button may not be able to go that fast, but when you have a hundred keys and 10 fingers with which to actuate them, fast typists will have begun to depress the next key as soon as another has made contact. \$\endgroup\$ – Nick T Mar 22 '11 at 16:28
  • \$\begingroup\$ @NickT - what you're talking about is what's known as 'roll-over', when key presses start overlapping. The wait-two-scans thing will still work for individual keys, because any individual key press is relatively slow. Of course roll-over, and pressing multiple keys in general invites the issue of ghosting, where if three keys happen to lie on the corners of a rectangle within the matrix, it becomes impossible to tell if the key at the 4th corner of the rectangle is pressed, but that's another issue. \$\endgroup\$ – JustJeff Apr 12 '11 at 11:30
1
\$\begingroup\$

Yes, a matrix with diodes is exactly how it is done.

I'm going to assume you select select one column at a time by driving it low, let all the other columns float (open-collector) (or drive all the other columns high), and your row input pins have pull-up resistors.

In principle, super-brief keytaps would be missed if the MCU doesn't select that column during the entire interval from the time the key is pressed until the time the key is released. In practice, humans are so slow that even when they try to quickly tap a key, a typical keyboard encoder with a fairly slow MCU will scan through every column dozens of times during that interval. The typing speed world-record is 1075 keystrokes over the course of 1 minute. That's an average of slightly more than 1 keystroke per millisecond on average. Almost certainly some keys were held down longer, and others shorter, but as long as you're not trying to beat the world record, I suspect that a keyboard scan time of 100 microseconds is more than fast enough. A 16 MHz processor should be able to scan every column in 100 microseconds or less fairly easily. In fact, some low-quality buttons have "keybounce" for so long that you may get several (false) key-presses and key-releases when a human tries to push the button one time, requiring extra complexity in hardware or software to make sure it is interpreted as a single keypress.

Most keyboard encoders simply scan the keyboard over and over (polling), selecting only one column at a time.

Low-power keyboard encoders drive all the columns low, set up an interrupt to wake them up if any row goes low, and then go to sleep. When they wake up, they scan the keyboard over and over (polling), selecting only one column at a time, until no keys are being pressed, then go back to sleep.

\$\endgroup\$
  • \$\begingroup\$ I have now done a mock up, so my inputs all have pullup resistors and all my out pins are set to high, when I want to scan a column I set its out pin to low so when the switch closes (each switch also has a diode) I will get a low on the corresponding in pin. \$\endgroup\$ – cjh Mar 26 '11 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.