The Keypaw

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.

The 1- or 2-byte scan code that tells the host computer when a key is depressed is called a make code, and the 2- or 3-byte scan code that tells the host computer when a key is released is called a break code.

The table of scan code values that contain the make and break codes used by most PS/2 keyboards is called Scan Code Set 2. This is the scan code data that we implemented in our software, so the Keypaw can produce all the scan codes associated with a standard PS/2 keyboard.

Host-to-Device Communication

Host-to-device communication is somewhat more complicated than device-to-host communication. In order for the host to send a request to the keyboard, the host must first hold the CLOCK signal low for more than 100 microseconds. The host must then drive DATA low before releasing CLOCK. The low start bit is marked as soon as the keyboard asserts the CLOCK signal. The keyboard must then proceed to toggle CLOCK with a period between 60 and 100 microseconds while the host sets the DATA line on falling edges. Unlike device-to-host communication, data bits are registered by the host on rising clock edges. Eight data bits are followed by an even parity bit and a stop bit, after which the host returns control of the DATA line to the keyboard. The keyboard must immediately drive the DATA line low, assert CLOCK, and drive DATA high. This final low value is known as the acknowledge bit. A general host-to-device communication waveform is shown in the figure below.

Requests that the host computer can make include setting the keyboard's Num Lock, Caps Lock, and Scroll Lock LEDs on or off, disabling or enabling the keyboard, setting the keyboard's typematic delay and typematic repeat rate, and various diagnostic functions. Typematic behavior is defined as the repetition of a held character after a short delay. The typematic delay refers to the amount of time that must elapse from an initial key press until the keyboard repeatedly sends the make code for that key to the host. Typematic rate is the rate at which the make code for the held character is sent to the host computer.

3.3 Implementation

A full listing of our commented C code is provided in Appendix B. The flowcharts and discussions that follow describe the major components of the program.

High Level Program Organization

The figure below is a high-level block diagram of the Keypaw program. Upon reset, the device monitors the Keypaw buttons and configuration program buttons. If a valid button combination is pressed, a character is sent to the host via the PS/2 port. If the configuration button is pressed, the device enters a configuration routine that allows the user to configure each button mapping stored in the device memory or play training games. More detailed flow charts of each of the four sub-processes appear in the figures that follow.

Registering Key Combinations

The figure below is a flow chart for the debounce_combo() function. This function allows the Keypaw to recognize combination button presses, use a concurrency window, and perform typematic repeat and delay timing. The purpose of the concurrency window is to separate keys pressed in succession from keys pressed simultaneously. When a key is pressed, any additional keys pressed while the window is open are considered part of the combination, while keys pressed after the window is closed are considered a new combination (with a new concurrency window).

Meta Keys

The figure below is a flow chart for the debounce_meta() function. This function allows the Keypaw to implement correct meta key behavior, which simply sends a make code when a meta key is pressed and sends a break code when any meta key is released. Meta keys differ from combination keys in that any number of them can be pressed along with other key combinations. The Shift, Control, Alt, and operating system specific meta key (e.g. the "Windows" key) each require a dedicated button so that any or all of them can be used to modify a non-meta character.

Registering Host Requests

The figure below is a flow chart for the check_host() function. This function implements host-to-device communication in the Keypaw by monitoring host control of the PS/2 CLOCK signal. If CLOCK is held low for longer than 100 microseconds, the host is requesting transmission, and the program enters the check_host() function. As described in Section 3.2, The PS/2 Keyboard Protocol, the host and device must then follow a prescribed series of signaling using the DATA and CLOCK lines to initiate a transfer of data from the host to the device. Three correct exchanges of data and clock signals must occur before the device provides the clock signal that the host uses to transmit its data to the device. After the request data has been received, the Keypaw interprets it and responds accordingly.

Mapping Configuration Program

The figure below is a flow chart for the config() function. This function allows the user of the Keypaw to customize the button mappings that produce each keyboard character scan code. The user can enter the configuration program by pressing a "Configuration" button that is separate from the Keypaw buttons. Once started, the configuration program outputs to a HyperTerminal window that instructs the user how to use the "Back", "Next", "Undo", and "Exit" functions in the configuration program, as well as information about the character currently being configured and the current button mapping for that character. If one mapping is provided for more than one character, the user is provided with a warning that a new mapping should be provided for one of them.

The configuration program also provides two training routines. The first routine flashes random characters to the user along with the key combination that is mapped to that character. Once the user enters the correct combination, the routine chooses a new random character. The second routine tests the user's memory of the combination mappings by flashing random characters without displaying the associated key combination.

3.4 Challenges and Failures

We ultimately implemented all of the functionality that we set out to build into the Keypaw, except for having the host computer recognize the device upon system restart. Other challenges and failures associated with the development of the Keypaw software arose mostly from our lack of familiarity with Scan Code Set 2 and the PS/2 keyboard interface. Specifically, the factors that made implementation of the required functionality difficult were:

• There is no formal documentation of the Scan Code Set 2 that the host computer is purported to use, because the IBM Technical Reference Manual that documented the convention in the late 1980s is no longer available in print. Consequently, we could not be certain at the outset whether the references we were using would be sufficient to allow us to correctly implement device-to-host and host-to-device communication.
• Signal timing is critical for producing valid device-to-host and host-to-device communication, and precise timing information was not available for each stage of device-to-host and host-to-device communication.

The biggest disappointment was that we could not get the host computer to recognize the Keypaw as a keyboard upon the host computer's system startup. Although we implemented all of the response codes for the various host requests, the specifics of the signal handshaking that occurs when the host computer starts is completely undocumented, and we were unable to reverse-engineer the proper behavior for our device.

To learn about Scan Code Set 2 and the PS/2 keyboard interface protocol, we spent the first several days of our project listening in on various host-to-device and device-to-host communications. We did this by building a PS/2 "extension cord" from a spare PS/2 6-pin mini-DIN, connecting the pins of a normal PS/2 keyboard to the extension cord through a breadboard, and probing the data and clock signals with an oscilloscope after the extension cord was plugged into the host computer. By examining the signal transmissions for make codes and break codes, as well as by watching the more complicated host-to-device and device-to-host communication that occurs when the host makes a request, we were able to verify or correct the information provided by our references.

A detailed summary of the other technical challenges we faced while developing the Keypaw software appears below in the table below.

Desired Functionality	What did not Work	What did Work
Device should produce a scan code that is recognized by the host	Setting the start bit low in the same way that other data bits were set; variation in the setup time for the scan code start bit resulted in random host errors (system beeps)	Setting the start bit low before transmission begins to ensure that setup time variations do not cause timing errors
Device should be able to recognize buttons pressed in combination	Using the same debounce function used in earlier labs to debounce STK500 buttons	Increasing the frequency that the debounce function was called to account for the shorter bouncing time of our buttons; modifying the bit-masking that occurs in the debounce function to allow multiple button presses to be recognized with a single call of the debounce function.
Device should be able to recognize buttons pressed in combination as long as the user has pressed the buttons within an adjustable "concurrency window"; the device should also be able to distinguish rapid, separate button presses from combination presses.	Producing a scan code each time the debounce state machine detects a single or combination button press	Adding an interrupt-timed "concurrency window" to our button-detection routine that accumulates the buttons pressed by the user while the concurrency window is open and sends a scan code only when the concurrency window has closed; window must be wide enough to account for finger-movement speeds of users with normal coordination without causing a noticeable lag in producing a desired character on the host computer
Pressing meta keys should produce different scan code behavior than pressing general-purpose (combination) buttons	Using the same debounce function used to debounce combination keys	Creating a separate debounce function for meta keys that produces the make-code and break-code behavior needed for meta keys (make code on press, break code on release)
Device must allow host computer to assume control of the PS/2 DATA and CLOCK signals whenever the host makes a request	Setting the data and clock pins as microcontroller outputs, as we had done during the first phase of software development	Using the DATA and CLOCK signals as outputs only when scan codes are being sent, and setting them as inputs with pull-up resistors at other times. Using an interrupt timer to check whether the host has held the clock low for 100 microseconds, which indicates a request
Holding down a combination of buttons should produce host-specified typematic delay and typematic repeat behavior	Setting typematic delay and typematic repeat within our program	Implementing host-to-device communication (see below for details) and decoding host-specified typematic delay and typematic repeat timing
User should be able to press a combination of buttons to "program" a new configuration without causing a character to occur on the host terminal	Using the same debounce function used when normally typing	Creating another debounce state machine specifically for the configuration program that strips the scan code capabilities from the function while still allowing the configuration program to detect combinations of button presses

4 Hardware Design

4.1 Required Functionality

Communication between host computer and device	Cable and 6-pin mini-DIN connector to carry PS/2 signals between the host and device.
Input handsets	Two handsets must provide comfortable and sturdy access to all combination and meta keys.
Configuration Buttons	Configuration buttons mounted separately from the input handsets.
Microcontroller	Solder board containing Atmel Mega32 microcontroller and supporting hardware, diagnostic, status, and keyboard LEDs, ports for input handsets and configuration buttons, output for PS/2 signals, and outputs for RS232 signals.

4.2 Implementation

PS/2 Connector

Most modern keyboards connect to the host machine via a PS/2 port. The male end of the PS/2 port, which follows a standard called the 6-pin mini-DIN, has a configuration of pins as shown in the figure below. The pins are connected to: 1) DATA, 2) Not Implemented, 3) GND, 4) VCC, 5) CLOCK, and 6) Not Implemented.

We purchased a 6-pin mini-DIN and connected it through a flexible cable to the PS/2 CLOCK and DATA signals as configured on the microcontroller .

Microcontroller and Supporting Hardware

The hardware required to implement the Keypaw centers around an Atmel Mega32 microcontroller. The figure below shows all of the connections made to the Mega32 chip.

The following table summarizes the connections shown above.

PORT A	PIN 0: PS/2 CLOCK signal PIN 1: PS/2 DATA signal PIN 3: diagnostic LED PIN 4: configuration mode indicator LED PIN 5: Num Lock LED PIN 6: Caps Lock LED PIN 7: Scroll Lock LED
PORT B	All pins used for combination key input pushbuttons
PORT C	PIN 0-3: meta key input pushbuttons
PORT D	PIN 0: RS232 RXD (receive signal) PIN 1: RS232 TXD (transmit signal) PIN 3-7: configuration input pushbuttons

Other Hardware

In addition to the microcontroller hardware, we fabricated a substantial amount of human interface and computer interface hardware, including two detachable handsets, a detachable mounting board for the configuration buttons, and a PS/2 cable. The handsets were carved from ergonomically sized and shaped plastic foam eggs, and the combination and meta buttons were mounted to minimize the amount of finger movement from the natural resting position.

4.3 Challenges and Failures

The greatest challenge of hardware development was fabricating the handsets. The plastic foam was very unforgiving for carving, and it took us several attempts until we had a button configuration that was both comfortable and sturdy. Once we had created one of the handsets, it was challenging to create its mirror image for the other hand.

Due to time and budget constraints, we decided not to include in our stand-alone hardware configuration the Atmel MAX232 chip that is required to adjust the RS232 voltages to conform to the RS232 standard. In order to use the configuration and training programs, we connect the RXD and TXD pins (PORTD.0 and PORTD.1) from our stand-alone board to the RXD and TXD pins of the STK500 development board.

5 Results

5.1 Functionality

The Keypaw allows the user to perform all the same functions as a standard IBM PS/2 keyboard without the need to move the fingers from a resting position over a single button. Combinations of button presses produce all the scan codes that can be produced with a normal keyboard, and the Keypaw also responds to host requests as a production keyboard would. For example, character typematic repeat and typematic delay behave as specified by the host computer, as do the Num Lock, Caps Lock, and Scroll Lock keys.

5.2 Safety

We believe that the only safety issue associated with using the Keypaw as a computer input device is the risk of repetitive stress injury due to handset design. We did not have the time or resources to perform in-depth research into the design of ergonomic handsets, so we do not know if the current prototype presents any kind of hazard to users of different hand sizes or motor skills. Before making a Keypaw-like device commercially available, we would need to understand what factors affect the design of an ergonomic keyboard, particularly any standards that may exist pertaining to the design of a handset. However, based on our own use of keyboards and computer mice that are described as ergonomic, we believe that we have followed basically sound ergonomic design principles by developing handsets that allow the user to keep the hands in a natural, curled position and allows the user to position the fingers, hands, wrists, and arms in any position.

5.3 Usability

An obvious drawback to the current hardware implementation of the Keypaw is the decidedly un-rugged materials and construction, which resulted from the real limitations on our budget and short timeline for developing a prototype. For practical applications, a Keypaw-like device would require handset design using standard mouse- or joystick-like materials and knowledge of ergonomic design.

Despite these drawbacks, the Keypaw demonstrates the basic principle of combination button presses mapping to single keyboard characters and fully configurable button mappings. From using the device ourselves, we realize that such software settings as the concurrency window, which determines how long a user has to depress all the buttons needed for a desired combination, should be configurable by the user to account for different levels of coordination. We also appreciate that some types of motor disabilities might make the Keypaw unusable for some users. However, we also see from our research into other "chordic"-style keyboards that, like our Keypaw, allow the fingers to remain positioned over a single button, in fact offer benefits to some users who are vision-impaired or one-handed.

For users such as ourselves, who have no motor disability and frequently work with computers, the Keypaw offers a comfortable alternative to touch-typing. Using even our basic configuration and training software, we were able to quickly learn how to use the Keypaw and would choose to use such a device on our personal computers if we were able to build more rugged handsets.

6 Conclusions

6.1 Results vs. Expectations

Although a host of features could be added to the Keypaw to expand its usability and functionality, the device in its current state fully demonstrates the value proposition of a fully-configurable hand-held keyboard and therefore meets all of our original expectations for our final project.

6.2 Conforming to Standards

The Keypaw correctly implements Scan Code Set 2 and communicates via a PS/2 keyboard interface with a host PC. We also use the RS232 capabilities of the STK500 board, as explained in Section 4, to send text data to the host PC's HyperTerminal program.

6.3 Intellectual Property Considerations

The two majors features of the Keypaw, 1.) combinations of buttons mapping to single keyboard characters and 2.) two handsets with single buttons for each finger, may be covered by the patents cited above in Section 2.5, Intellectual Property Issues. If we wished to pursue commercial production of a Keypaw-like device, we would need legal counsel to advise us whether our design infringes on any patents. We are interested in pursuing possible patent opportunities for the concept of fully configurable button mappings on a handheld keyboard.

Apart from the issue of patent-related intellectual property considerations, our device was built using software that we wrote in its entirety and hardware that we designed and constructed from basic components.

6.4 Ethical Considerations

Our overarching goal in this project was to build a device that could provide real benefit to a substantial number of computer users. We feel that the decision to pursue the design of the Keypaw for the purpose of improving the usability of a standard computer input device is consistent with the first point of the IEEE code of ethics, "to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment". Per the second part of point of the IEEE code of ethics, we have disclosed all known safety and usability issues with the Keypaw that might endanger the public or the environment.

To the best of our ability, we developed preliminary specifications and final documentation for the Keypaw that accurately state the functionality of the device. In this way, we have adhered to the third point in the IEEE code of ethics by being, "honest and realistic in stating claims or estimates based on available data".

In our demonstration and documentation of the Keypaw, we hope to meet the requirements of the fifth point of the IEEE code of ethics by improving the user's and reader's "understanding of technology, its appropriate application, and potential consequences" as regards input devices.

By limiting our project scope to include technologies that we were familiar with or capable of learning without endangering ourselves or others, we sought to meet the sixth point of the IEEE code of ethics, "to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations".

In our communication with each other and our peers in ECE 476, as well as during the documentation of our final project work, we met the requirements of the seventh point of the IEEE code of ethics, "to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others".

Though our device may not be optimized for the use of persons with certain disabilities, we have tried through complete disclosure of our device's functionality and target audience to meet the eighth requirement of the IEEE code of ethics, "to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin".

7 Appendices

Appendix A: Photos

The photo below shows the prototype Keypaw solder board with Atmel Mega32 microcontroller and supporting hardware, diagnostic, status, and keyboard LEDs, and custom ports for input handsets and configuration buttons.

The photo below shows one of the Keypaw input handsets. Four combination buttons are accessed by the four fingers, and two meta keys are accessed by the thumb (the setup is mirrored for the other hand).

The screenshot below shows the host computer's HyperTerminal displaying the key combination mapping configuration program.

The screenshot below shows the host computer's HyperTerminal displaying the training program main menu.

The screenshot below shows the host computer's HyperTerminal displaying the character practice training program.

The screenshot below shows the host computer's HyperTerminal displaying the key mapping memory training program.

Appendix B: C Code Listing

The source code for this project was divided into two files:

• main.c: main program
• mappings.c: predefined key combination mappings

Appendix C: Budget

The total cost of the Keypaw is $21.57, which includes all hardware used except for small circuit components (wires, resistors, LEDs) and the STK500 development board. The cost breakdown for the device is shown in following table.

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

Appendix D: Team Member Contributions

Maudie's Conbributions

Sumul's Contributions

Developed original project idea, contributed introduction and editing to project proposal Researched PS/2 scan code protocol Designed setup for "listening in" to real keyboard communication with host Circuit wiring for ten-button keypad used throughout software development Collaboratively developed and debugged software for sending scancodes with Sumul Modification of debounce state machine to allow button combinations rather than single button-presses to be registered by device Designed a state machine outlining host-to-device communication protocol to assist in implementing host-to-device communication in software Wrote basic button configuration and training software, including modified debounce state machines, to implement customizable button mappings Helped write final project report

Wrote project proposal Found sufficient PS/2 scan code documentation Ordered needed parts Built setup for "listening in" to real keyboard communication with host Collaboratively developed and debugged software for sending scancodes with Maudie Developed data structure for easy handling of character mapping information Reviewed and clarified code comments for easy readability of code Modified debounce state machine to implement meta-keys and "extended" scancode keyboard characters Implemented host-to-device communication in software so device could successfully perform BAT and other signaling requiring receiving and responding to host commands Constructed handset and hardware for final version of the device prototype Helped write final project report Created website

Appendix E: References

1. Atmel Mega32 Data Sheet (http://instruct1.cit.cornell.edu/courses/ee476/AtmelStuff/full32.pdf)
2. Jameco Electronics (http://www.jameco.com/)
3. PS/2 Hardware Standard (http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm)
4. PS/2 Keyboard Protocol (http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro/keyboard/atkeyboard.html)
5. Scancode Listing (http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html)