1 Introduction
The Keypaw is a 12-button input device that provides computer users with an ergonomic, fully-configurable alternative to the traditional QWERTY keyboard.
The Keypaw is a microcontroller-driven device with 12 buttons mounted on two handsets; 1 button is provided for each finger, and 2 buttons are provided for each thumb. Pressing a button or combination of buttons on the Keypaw produces a single character input to the host computer. The Keypaw maps 92 of 255 possible key combinations to the characters that appear on a standard PS/2 keyboard, and it transmits the decoded combinations to a host computer through the widely-supported PS/2 protocol.
A simple configuration program allows the user to customize which button combination on the Keypaw corresponds to which keyboard character. A training program gives users a simple interface for memorizing the key combinations. The configuration and training programs run on the Keypaw’s microcontroller and display simple text prompts on the host computer’s Hyperterminal program.
The hardware design of the Keypaw provides the user with extensive control over finger, hand, wrist, and arm positions while typing. The two separate handsets allow the user’s hands to rest in a naturally curled position wherever the user chooses to place the handsets. Because the Keypaw has only twelve buttons, the fingers and thumbs do not need to move from their resting positions on the handsets.
The software design of the Keypaw was developed with complete customizability in mind. We created a default button mapping that we found convenient for typing English text at the maximum possible speed, because typing English text comprises a large part of our own human-computer interaction. However, because typing English text is not the primary goal of every computer user, the Keypaw’s configuration software allows users to completely customize the keyboard mappings to suit their own needs.
2 High Level Design
2.1 Motivation
As computing technology becomes more integrated with all parts of personal and work life, good design at the human-computer interface has become increasingly important to ensuring that all computer users can derive the maximum benefit from their interactions with computers. We are therefore surprised that advancements in input device technology have not been as widespread as the advancements in computing systems themselves. Most computers today still have as their primary human-computer interface the QWERTY keyboard, an input device originally designed to compensate for the mechanical limitations of 19th century typewriter technology.
The idea for this project originally stemmed from Maudie’s desire to be able to type while standing and walking; the hardware design of the Keypaw in its current implementation is similar to her original description of a device that would permit comfortable typing from a standing position. As we discussed the uses of such a device, we came to realize that a customizable hand-held input device would be a great alternative to the PS/2 keyboard for some computer users. Consequently, armed with limited knowledge of how modern keyboards work and extensive knowledge of our own computer usage habits, we set out to create a better input device using inexpensive (under $40), readily-available technology.
2.2 Project Goals
At this time, we have developed and demonstrated the two deliverables that we described in our project proposal as “expected-case deliverables”. These deliverables are:
- Two input devices, one for each hand, that communicate with a host computer using keyboard Scan Code Set 2 via a PS/2 keyboard interface (see Section 2.4 on Standards for complete discussion)
- A basic configuration program that allows the user to define how button combinations map to standard keyboard scan codes.
We have also had time to work on one of our best-case deliverables:
- Expanded functionality of the configuration program, including a training program to help users to practice using the device.
We did not choose to pursue the development of a second best-case deliverable: implementing a wireless version of our device.
2.3 Design Tradeoffs
The overall scope of our project was defined with the timeline constraint in mind. Knowing that we would have roughly four weeks from when we started the project until we would have to complete it, we decided to use hardware, programming languages, and protocols that were familiar to us from our previous coursework. This resulted in our choice of the Atmel Mega32 microcontroller as the central computing device in our design and C as the programming language. Though we were not intimately familiar with Scan Code Set 2 or PS/2 keyboard interfaces at the start of the project, we thought that learning the details of this protocol would accomplish our goal of meeting the complexity requirement of the project.
We realized early on that our proposed device would require little more hardware than the Atmel Mega32, buttons, and comfortable handsets to be fully functional according to our device specification. Rather than using up any of our extra budget by adding expensive peripheral hardware features to our device, we chose to keep the total cost of our device as low as possible and instead focus on building useful accompanying software to make device configuration as user-friendly as possible. The first hardware tradeoff that accompanied this decision was in our choice of buttons; we purchased the most basic button that would meet our requirements for usability. The second hardware tradeoff that accompanied this decision was in our choice not to build an LCD on our device. We decided to use a HyperTerminal window on the host computer to display prompts from our configuration and training software rather than build an LCD onto our device.
Other priority-driven decisions and tradeoffs occurred as the development of the device progressed. A summary of these tradeoffs appears in the table below:
| Project Priorities | Priority-Driven Decisions and Tradeoffs |
|---|---|
| Complete the project design, implementation, testing, and documentation by May 5 | Chose hardware, programming languages, and protocols familiar from previous coursework; resulted in selection of Atmel Mega32 for device MCU and C as programming language. Also resulted in selection of simple, easy to carve plastic foam for handset construction. |
| Build a device that would be useful to us in our everyday life | Chose to develop an improved input device, a design problem interesting to both team members |
| Build a device that meets final project requirements for complexity, functionality, ethics, etc. | Set aggressive goal of completely implementing standard keyboard host-to-device and device-to-host communication despite lack of formal documentation; required significant time investment. Focused on usability of device for the broadest segment of the target user base. Focused on ergonomic design over developing a device with similarities to a traditional keyboard |
| Keep the total cost of parts under $40 | Chose not to add an LCD to our device for the configuration program outputs; instead used HyperTerminal on the host computer that the user would be using with the device. |
2.4 Standards and Conventions
PS/2 Keyboard Protocol
Most modern computers support PS/2 keyboards as the main input device. Although three PS/2 keyboard scan code sets (referred to as Scan Code Sets 1, 2, and 3) have been developed, Scan Code Set 2 is the most widely supported, and it is the default for most modern computers and keyboards. We decided to support only Scan Code Set 2 in order to avoid the additional development time required to implement the other less commonly-used sets.
We chose to use the RS232 serial communication standard to display our configuration and training prompts on the host computer’s HyperTerminal software.
In summary, the hardware and software design choices we made resulted in our use of the following standards and conventions:
- The 6-pin mini-DIN hardware standard for the PS/2 plug that connects the Keypaw to the host computer
- The Scan Code Set 2 convention for device-to-host and host-to-device communication via a PS/2 keyboard port
- The RS232 standard for device-to-host communication via a serial port
Using an online source [4] on the PS/2 keyboard communication protocol, we learned that most modern personal computers provide an interface for IBM-compatible PS/2 keyboards, which by default use the Scan Code Set 2 convention for host-to-device and device-to-host communication. Scan Code Set 2 was developed by IBM in the late 1980s for use in the keyboards that shipped with IBM personal computers, but this convention is not documented online by IBM or any other device manufacturer. We therefore used references [4,5] developed by individuals who reverse-engineered the convention through observation and information collection. An overview of the PS/2 protocol and Scan Code Set 2 convention is provided in Section 3.2, The PS/2 Keyboard Protocol.
RS232 Serial Communication
We configured the Universal Synchronous/Asynchronous Receiver/Transmitter (USART) on the Atmel Mega32 to transmit over an RS232 cable to a serial COM port of the host computer at 9600 baud. With the proper initialization in software, this allowed us to transmit text strings to the host computer using the standard C input/output libraries. Because we used the RS232 voltage-leveling hardware that is included on the STK500 development board, no further familiarity with RS232 protocol was required for us to use this standard in our project.
2.5 Intellectual Property Issues
The only commercially available device that we could find that is somewhat similar to the Keypaw is a patented product called the DataHand Ergonomic Keyboard, made by DataHand Systems, Inc. Unlike our device, the DataHand is a tabletop device with a non-configurable, pre-defined key mapping that basically translates the QWERTY keyboard layout to a device that supports the hand and eliminates some of the travel distance between keys. The DataHand does not use our paradigm of mapping button combinations to single keyboard characters. The DataHand is also in a price range ($1000 and $1300) that targets only high-end computer users who place an extremely high value on the ergonomics of their keyboard.
Having read the patents related to the DataHand and other novel input devices, we have identified the following patents describing a keyboard design similar to our device’s handset:
- US Patent 6,712,533, Chen: Hand-held computer keyboard, claims patent on a hand-held computer keyboard with buttons mounted on separate hand pieces
We have also identified patents that may include claims that cover our use of configurable button combinations on a handheld keyboard to produce scan codes to a PC:
- US Patent 6,703,963, Higginson: Universal keyboard, claims a multifunction keyboard for use as an input to computing devices.
- US Patent 4,833,446, Eilam, et al.: Keyboard apparatus and method, claims a patent on “chordic” keyboards, wherein combinations of buttons are mapped to single characters.
We are interested in pursuing legal counsel to determine how our device would infringe on these patents and whether any portion of our device can be patented.
3 Software Design
3.1 Required Functionality
| Device-to-host communication | The Keypaw must be able to recognize combinations of buttons presses and respond by producing valid Scan Code Set 2 make and break codes |
|---|---|
| Host-to-device communication | The Keypaw must be able to recognize and respond to host requests without interfering with device-to-host input from the user. |
| Button configuration | The Keypaw’s user must be able to determine what combinations of buttons map to what characters |
| Training | New users must be able to quickly learn how to use the novel configuration of the Keypaw and look up the button combinations corresponding to individual characters |
3.2 The PS/2 Keyboard Protocol
The PS/2 protocol allows a keyboard and a host computer to communicate with each other through the serial transmission of data over two voltage signals: a CLOCK signal and a DATA signal. Either the host computer or the keyboard may be setting the voltages on these lines at a given time, depending on the direction of data transmission.
Device-to-Host Communication
The voltages on the CLOCK and DATA lines remain at the positive power rail when the keyboard is not sending or receiving data. When the keyboard sends the scan code for a character to the host computer, the keyboard produces a clock signal on the CLOCK line with a period between 60 and 100 microseconds and a serial 11-bit data signal on the DATA line that is read by the host on falling edges of the clock. The 11-bit data signal consists of a low start bit, an 8-bit scan code (least significant bit first) corresponding to a keyboard character, an even parity bit (high when the number of 1‘s in the scan code is even), and a high stop bit. A general device-to-host communication waveform is shown in the figure below.
Parts List:
| Part | Quantity | Price Each | Total Cost |
|---|---|---|---|
| Jameco #155379 Tactile Switch | 16 | $0.35 | $5.60 |
| Jameco #155408 Tactile Switch Cap | 16 | $0.15 | $2.40 |
| Jameco #142261 6-pin mini-DIN Male Connector | 1 | $0.89 | $0.89 |
| Plastic Foam Handset Base | 2 | $0.69 | $1.38 |
| Large Solder Board | 1 | $2.50 | $2.50 |
| Small Solder Board | 1 | $0.80 | $0.80 |
| Atmel Mega32 Microcontroller | 1 | $8.00 | $8.00 |
For more detail: Keypaw
