Above is a graphic from wikipedia.org showing the keyboard layout we’re trying to create.  Note that only the central portion of the keyboard is different.  About half of the keys will remain right where they are.

In this post, we’re going to take a look at how I went about detecting errors in my keymap data.  Any problems we can eliminate early on will be problems we don’t have to deal with later and the database makes this rather easy to do.

We’ll start with identifying our rows and columns again.  We know that pins 11, 12, 16, 17, 18, 19, 21, and 22 are the rows for our key matrix.  Get very familiar with this set of numbers – we will use them a lot as the project progresses.  The first task is to query our table and make sure that both the qwRow and dvRow columns only contain these numbers.  If either column contains anything else, it’s a transcription error that crept into the data somewhere along the way and it needs to be fixed.  Here are a couple of queries that help do that:

select distinct qwRow from keymap;
select distinct dvRow from keymap;

Once those errors are corrected, then the same can be done for the column rows:

select distinct qwCol from keymap;
select distinct dvCol from keymap;

Again, the only thing that should show in the results pane are the columns: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 13, 14, 15, 20, 23, 24, 25, and 26.

The final step is a bit more interesting.  Both the qwerty and the dvorak row/column pairs should correlate with each other.  It’s a bit hard to explain how that is, but in the end, we’re checking for consistency between the two views of the table.  These views help in ensuring that the keymap data is consistent.  Here’s the query:

select a.qwKey, b.dvKey
from keymap a, keymap b
where a.qwCol = b.qwCol and
a.qwRow = b.qwRow and
a.dvCol = b.dvCol and
a.dvRow = b.dvRow
order by qwKey;

The trick I’ve used above is an old one that has come in handy many times.  I purposely joined the same table to itself and forced the arrangement of the data so that each keyname from both layouts would be displayed together.  Once this is done, it’s fairly simple to visually scan through the results for problems.    Here is a snippet of the results:

If you take a look at a qwerty keyboard and then compare it to the graphic at the top of this post, you can see that where there is a G in a qwerty layout, there would be an I in the dvorak layout.  The Home and Insert keys would remain in their same position in both layouts.

Finally, lets try another query:

select a.qwKey, b.dvKey
from keymap a, keymap b
where a.qwCol = b.dvCol and
a.qwRow = b.dvRow
order by qwKey;

This one will yield a somewhat surprising result.  It will show you two columns of keynames and they should all be the same across each row:

This query puts the key translation into the where clause of the query, which makes the result set show if there are any inconsistencies.  At the end of the day, each key can only be represented once for each layout.  The forwards and backwards examination of that translation should be consistent.  If any problems do show up, you have an opportunity to debug it now before we’re about 500 lines deep in verilog code.

Next time, we’ll take a look at how we’re going to implement the key translation.  That post will be mostly about the theory behind the design.  Do note that if you’re not comfortable with sql queries, it might seem to get a little bit more complicated from here, but we’ll really only be using the same multiple-joins trick in a slightly different way.