Experimental thumb keyboard, suitable for a hand held device
As promised, I've put the keyboard scanning code covered in the last three logs online and you can download it from this page: https://dboucher.org.uk/keyboard.
Keyboard with Arduino UNO and paper pin insulator.
This version is set up for Arduino but it should work on anything Arduino compatible with enough GPIO pins. I've used it on a Teensy LC for example.
There is a README with more info in the download. I hope you find it useful.
Last one of these I promise.
One of the problems with producing any sort of keyboard is all of the different layouts. Layouts vary by country, language, country AND language and sometimes there are different layouts for the same country and language.
But what if I want an uppercase "Q" instead? I need a shift key for this, which brings us on to modifiers. Modifier keys, when held down, change the function of other keys, which means changing the key map used. I decided to have two modifiers, as I have limited space on the keyboard to print the alternate functions for each key. I also decided not to allow modifiers to be used together, as the keyboard can only reliably detect two simultaneous key presses (see the first keyboard basics log for an explanation).
This gives each key three possible functions, one on its own and one with each modifier, and so three key maps are required. The mapping routine first checks which modifiers are pressed to determine which map to use, then maps the key as explained above. Ta Da! Now we can type "Hello World!" complete with uppercase characters and punctuation.
And so ends this (longer than originally planned) explanation of how to scan a keyboard. I will post the code for this once I have tidied it up a bit and I will also be moving on to the hardware side of things.
This is the middle bit of the keyboard reading code. At this point we have a map of which keys are pressed and we need to start turning that into key events. The events that we need are:
In order to determine whether a key has been pressed or released we need to keep a record of the state of the keyboard on the last scan and check for state changes. This is simple enough, but the repeat event requires a little more work. For key repeat, we need to know how long a key has been held down, so we need to do a little bit of timing. There are actually two time periods associated with key repeat: the first is how long a key must be held down to produce the first repeat event and the second is how much additional time it must be held down for each additional repeat event. The first of these intervals is generally longer than the second.
The way that I've handled this is to have the scan routine run at regular intervals. I could do this on a timer interrupt but for simplicity I'm just using the millis() function to control a delay between scans. Then I maintain a counter of how many scans a key has been held down for.
I can also use this for key debouncing. Bouncing is when a circuit is made and broken multiple times as a switch is being pressed or released, which in a keyboard would cause spurious key press and release events. I've not actually had a problem with this unless I scan the keyboard continuously with no delay between scans, but I've included code to deal with it anyway just in case.
Putting all these things together, this is how I'm handling this part of the process. Firstly, though, I need a few constants:
Then the code does the following:
Now we have a stream of key events but we only have the key numbers when what we really need to know is what that key represents. That needs key mapping which will be the subject of the next log.
In the last log I covered how a keyboard is wired up. This time I'll cover how it is scanned. My prototype thumb keyboard has four rows of ten keys each, giving a requirement for 14 GPIOs in total. This puts it within the capabilities of an Arduino. There won't be many pins left for anything else, but I'll cover a way around that in a later log.
Prototype 1 connected to an Arduino UNO. The piece of paper is just there to stop two of the pins shorting out.
To scan the keyboard, all the GPIOs are first set to INPUT_PULLUP, then each row GPIO in turn is set to output and pulled LOW and each column GPIO is read. A column GPIO that is LOW indicates a pressed key. The row is then set pack to INPUT_PULLUP and the next row is scanned. The end result of this is a map of pressed keys.
But there is a problem: if three keys are pressed together forming three corners of a square, a fourth, phantom (or ghost) key press will be detected at the missing corner. Here's a diagram to help explain that:
In this example, keys are pressed at (c3,r1), (c3,r3) and (c1,r3), but when position 1,1 is scanned current will flow via the three pressed keys (orange line) and produce a phantom key press at (1,1).
This situation can be avoided by fitting a diode in series with each key switch. This means that current can flow from a row to a column but not the other way. Looking at the example above again, when (1,1) is scanned, current could flow from row 1 to column 3 at (c3,r1) but would not be able to flow onto row 3 at (c3,r3), so no circuit would be made.
Most keyboards, including mine, do not do this and rely on detecting the phantom instead. This is quite easy to do: for each key, if two or more keys are pressed in same row and one one of those keys also has another key pressed in the same column then a potential phantom exists. Referring to the example above again, (c3,r3) would trigger phantom detection as it has a another key pressed in the same row at (c1,r3) and also in the same column at (c3,r1). When a phantom condition is detected, the scanning routine stops updating the state of the keyboard until the condition is cleared by releasing one of the keys.
Even with the phantom key problem, any two simultaneous key presses can be detected. As I'm building a thumb keyboard, and two is the usual number of thumbs per person, I think adding series diodes would be overkill in my case.
As this point we have the ability to determine which keys are pressed. In the next log I'll cover how this is turned into a series of key press, release and repeat events.
Electrically, a keyboard is just a grid of wires with a switch at each intersection. Pressing a key (switch) makes a connection between a single row and column. To read the keyboard, a controller energises the wires in one axis one at a time and checks each wire on the other axis for a circuit. If there is a circuit between a particular row and column then the key at that intersection is pressed (Probably, but I'll come back to that in another log).
In the picture above, pins 1 is permanently connected to pin 4 and pin 2 is permanently connected to pin 3. Pushing the switch connects all four pins. This means that I can carry the column connections through the switch, bypassing the row wiring. A solder joint across two pads connects each row to the one below it.
Although my prototype has the keys laid out in a rigid grid, this is of course not usually the case with keyboards. Keyboards generally have their rows offset and include keys of different sizes, which sometimes cross multiple rows or columns. I don't think that different sized keys are practical with my design, but I want to look at offsetting the rows at some point. As this is meant to be a thumb keyboard, not a full sized one, I think that this is an acceptable compromise.
Recently, I've been considering building something that would need a small thumb keyboard. I did consider modifying one of those mini bluetooth keyboards or a gaming chatpad but I couldn't find one that met my requirements, so I've decided to build one from scratch.
The requirements that I set myself are:
As you can see from the project picture, I've got as far as building a first prototype. I'll be talking about that more in another log soon.
My aim is to produce a flexible design and release the details in the hope that they will be useful to others.