When we last spoke, I used the term “Success!” to describe what was going on. That was only partly true. I was not referring to completing the project, but rather to the success of getting raw key scan addresses out of the keyboard. It is a very long way between raw key scan addresses and a usable keyboard. So perhaps I should have titled that post “I can actually write some keyboard firmware now!” Yesterday between obligations I powered through writing rather a lot of firmware, and today I am happy to report that I actually have a better success than the last success. Even more successier than I expected in so short a time!
To understand why the firmware was a challenge, I should perhaps back up a little bit. I’ve already discussed the wire protocol and the signalling and all that, but when you’ve finally got the electrical connections all hooked up and decoded the protocol correctly, you’re still left with a very rough raw stream of data that needs handling. The Teensy firmware is responsible for decoding it and turning it into something useful.
The firmware essentially has two functions. Its first duty is to sit in a tight loop, pushing a status byte to the keyboard about once every 1.28 ms. On every 16th update, bit 6 is turned on in the status word, which means “Hey, keyboard, why don’t you look to see what keys are down right now?” When the keyboard sees this bit, it examines all of its columns and rows to find the addresses of the keys that are down. It sends those addresses to its own UART. The keyboard’s UART happily shoots them down the line to the USB converter’s UART, which interrupts the Teensy whenever it has new data.
The second firmware function (and probably the more important) is handling this interrupt. Each time it’s interrupted, the Teensy slurps the key address into a small internal buffer. The challenge here is that a human finger may hold a key down for 100 ms or so. To you and me, that’s one short key press, but the keyboard is being asked to scan itself 5 times during that very short key press. The Teensy has to be smart enough to know that this is only one key press, not 5!
Furthermore, the mechanical switches in the keyboard are of course not debounced, which means they may appear to open and close very rapidly for a very short time. Debouncing with hardware would require a lot more parts, and be a lot more expensive per unit, than doing it in software, so each key press might get scanned during the middle of a bounce. It might seem like the key is up when the user actually meant it to be down, or vice-versa. So the Teensy has to handle that, too.
It’s not a trivial problem, but lucky for me DEC came through again. Of course I couldn’t examine Digital’s actual firmware source code, but Section 4.4.9 of the “VT100 Technical Manual” goes into gruelling detail about the algorithms DEC used in the VT100’s 8085 firmware to recognize key presses and deal with auto-repeat. They document it so well, in fact, that it was pretty easy for me to just turn it directly into C code.
Anyway, here’s the project on my Github if you’re interested in looking at it or, God forbid, you actually want to try this yourself at home.
Comments