NOTE:  It is very likely that various pieces of documentation presented here will be out of date as the project evolves.  User beware.  This is most likely to happen where the same topic is covered in two different sections (e.g. text and drawings) where I forget to correct all possible sections.  This information will not be a step by step set of instructions.  I intend for it to be a guide, but it will require perserverence for someone not familiar with working with AVR chips to wade through.  It will be extremely difficult for someone to actually work with the source code and customize it to their needs.  I have enough trouble when I take a several month break from working on the source code and then want to do something simple.
As of 26 June 2010, the keyboard functions are fairly stable and well behaved.  Only minor cosmetic changes (e.g. changing the exact key assigned to a few functions) have been made in the past few weeks.  No work has yet been done on the PADDLE keyer mode.
15 Aug 2010 Update:  First support for PADDLE keyer mode implemented;  initial tests encouraging;  no support for ID detect from paddle yet.
13 Sept 2010 Update:  Paddle mode fairly compete (back on Aug 19);  ID detect from paddle working;  transmitted code (from paddle) displayed on row 2;  need to add word spaces in the displayed text and add an enable / disable for this display function;  my fingers are not quite convinced that the Type A implemention is identical to the PIC keyer implementation, but it is pretty close;  I do seem to generate the letter R more often when trying to send the letter W, so I need to try to tweak the timing eventually.  For Type B, I can only judge that my usual error where I try to send the letter V and produce a trailing dot (VE) does happen, so it at least has some characteristics of Type B timing.
15 Sept 2010 Update:  AMP KEY line implemented with hardcoded 13 msec delay fro key up to amp key up.  This is for generating the amp key line to use instead of the K3 KEY OUT line, in CW+ mode, which becomes erratic above 60 wpm, staying low even through most word spaces at 70 wpm.  Plan to eventually make the delay a programmable parameter in steps of 1 msec.  I have not actually tested with the K3 and amp yet, only looked at the key and amp key lines on the scope.
27 Dec 2010 NOTE:  I had sort of ignored support for the smaller chip (328P) when I added the AMP KEY line support and thought I would just abandon further support at compile time for the that chip (in the Duemilanove).  Recently I decided to play with the Bare Bones Board (BBB) from Modern Device:  http://shop.moderndevice.com/products/bbb-kit which uses the 328P.  So I plan to add the compile time support to skip the AMP KEY feature in the 328P, since it does not have additional timers available, and continue to support both chips.  I may also try the Really Bare Bones Board (RBBB) from the same source.  It is smaller, but functionally the same.  Both the BBB and RBBB cost about $15.  See Bare Bones Board Version  for information on the BBB assembly.   
31 Dec 2010 NOTE:  I completed the wiring of the BBB version today, and ran it on 40M with 600 watts.  So far it seems to be working the same as the Seeeduino versions.
1 Jan 2011 NOTE:  I am starting on the RBBB version now.  See Really Bare Bones Version  for information on the RBBB assembly.   
(For documentation on the previous PIC / assembly language keyer (that implements both keyer and keyboard), circa 1999, see: http://sites.google.com/site/w5uxhkeyerkeyboard/)
(For documentation on a QSK switch project, inspired by K7FJ and W6JL, using 1N4007 diodes, see:  https://sites.google.com/site/k7fjdiodeqskswitchbyw5uxh/)
This site presents documentation for a CW Keyboard project implemented with the Atmel AVR family of chips.  The current development environment and source code supports targeting both the Seeeduino Mega board using the ATmega1280 chip and the Arduino Duemilanove board using the ATmega328P chip.  This smaller chip is available in a DIP package that can be socketed, so a dedicated version of the keyboard should be possible in a custom design.
 14 Oct 2010:  The newest "prototype" uses Engraved front and rear panels from Front Panel Express:
I messed up on the countersunk holes.  They are too large for the 4-40 flat head screws that hold in the LCD display.  As a result I will not be using the black flat heads I had intended but will use 4-40 pan heads as seen in the photo.  I have ordered some 6-32 flat heads for the four corner screws on both front and back and will see if the hole size / counter sink size are at least correct for those screws.
It is expected that the final code should easily fit in the program memory of the smaller chip.  The primary difference between the two targets is that the ATmega1280 non-volatile EEPROM supports storage of longer programmed messages and the SRAM supports larger buffers.
14 Oct 2010:  As expected the code size after implementing the keyer paddle support still easily fits in the smaller chip, but I probably am going to drop support for that chip.  I had previously dropped support for a 2 line LCD, so the current plan is to only support the 1280 chip and the 4x20 LCD.
Main Project Goal:    Implement a combined paddle keyer / PS-2 CW Keyboard
Target Audience:      QRQ CW ragchewers;  no special features for contesting, amplifier control etc.
Documentation Plan:  Hopefully I will generate three "manuals":
    1)  An operating manual.
    2)  A construction manual.
    3)  A basic development environment manual.
The manuals may never evolve, but the raw documentation hopefully will be sufficient for someone experienced with this sort of project to be able to wire up a functional unit and download the firmware using AVRDUDE.
The keyboard buffer sizes and programmed message lengths for the two target chips are shown here:
#ifdef ATmega328P
#define KBD_BUF_SIZE 128
#define MSG_BUF_SIZE 80

#ifdef ATmega1280
#define KBD_BUF_SIZE 512
#define MSG_BUF_SIZE 320
Links to sources for the Mega board and LCD:
    http://www.nkcelectronics.com/seeeduino-mega-fully-assembled.html                                              (price currently $39.50)
Brief sumary of features to be implemented:
    Accurately timed CW character generation at speeds well above 60 WPM in keyboard mode.
    128 or 512 character keyboard buffer.
    Nine message memories, 80 or 320 characters per memory.
    Independent speed settings for paddle keyer / keyboard keyer.  Common weight setting for the two.
    Speed and weight settings controlled with the four arrow keys on the keypad (UP/DOWN steps of 1 and 5).
    LCD 4 line x 20 character display of speed, weight, buffer status, and text entry.
    ID timer that counts up from 0 minutes, automatic reset to zero when call is sent from either paddle or PS-2 keys.
The features of this implementation basically duplicate those of an earlier project from the 1998-2001 time frame that was based on a PIC chip and written in assembly.  The new project is written completely in C using the AVR-Studio / WinAVR / avrdude development environment.  The Doxygen HTML documentation tool is used to produce linked documentation for navigating the code modules.
The initial scope of the project only includes the CW Keyboard mode, but eventually the CW Keyer (paddle) mode will be added.  Development is still in the early stages but the following features have been implemented so far and are now in use:
A buffer full warning when less than 32 characters remain is provided.  (My personal preference is to never be more than 3 or 4 characters ahead in the buffer.)
Two different speed settings are supported, "PDL" and "KBD", where it is intended that the PDL speed is used with the keyer paddle and the KBD speed with the PS-2 keys.  Although the paddle keyer code is not yet implemented, the PDL speed setting is used when a rapid "QRS" speed change is required.  The F1 key toggles the PDL and KBD speeds settings back and forth to accomplish this.
Speed and weight are controlled with the four keypad arrow keys as follows:
    UP    Arrow   =   UP   5 units
    DOWN  Arrow   =   Down 5 units
    LEFT  Arrow   =   Down 1 unit
    RIGHT Arrow   =   UP   1 unit
For SPEED control the units are WPM.  For WEIGHT the unit is "percent" duty cycle, where the nominal setting is 50% meaning the length of a dot is equal to the length of the element space.  Lower weight (e.g. 45%) is a "lighter" weight.  At 45%, the dot length is shorter than the 50% dot by 5% while the element space is 5% longer.  Specifically, at 60 WPM and 45% weight, the dot length would be 19 msecs and the element space would be 21 msecs.  At 60 WPM and 50% weight, both the dot and element space lengths are 20 msec. 
The three keys directly above the arrow keys determine which parameter (PDL, KBD or WT) will be changed by the use of the arrow keys.  The "delete" key changes control to PDL, the "end" key to KBD and the "page down" key to WT.  The initial power on default speed and weight settings can be changed by storing the current settings in EEPROM.  The "scroll lock" key provides this action.
Timing resolution for element and space lengths is 16 usec, using Timer1 (a 16 bit timer) clocked at 62.5 KHz.  No effort has been taken to limit the speed or weight range to protect you from yourself.
A "ten minute ID" timer is provided.  This timer counts up in minutes and is automatically reset when a specified call sign is sent.  The call sign is stored in EEPROM and may be edited.   A warning indicator flashes when the timer reaches 8 minutes and continues flashing until the 16 minute point, at which the flashing stops.  The timer limits at 99 minutes.  When the paddle keyer is implemented, the timer will also be reset when the specified call is sent using the paddle, assuming some reasonable accuracy in the operators fist.
Message memory support is not yet completed but should be in another day or so.
Three text display modes are provided:  no text displayed as code is generated; one line of text is displayed as it is typed;  two lines are displayed:  as typed and as transmitted.  The default is neither line of text is displayed.  The F2 key rotates between the text display modes.
The current weight is only displayed on command, when the "page down" key is used to select weight.  When either of the other two keys is used to select PDL or KBD, the weight fields are cleared in order to have less clutter on the display.
As the project is only a month or so old, any documentation provided will continue to evolve, so from here on it is likely that there will be incorrect documentation to be found.  Sorry about that.
 In the initial creation of this web page I have included some drawings and photos and the current set of project source code files.  The source code changes daily, so this is only a snapshot and will not be maintained with any frequency!
The Doxygen page contains ZIP files that have the complete HTML documentation as of the time stamp date.  To browse the documentation, unzip the file, then follow this path:  Doxygen-Keyer-AVR\Keyer-AVR\html\index.html and click on the index.html file to begin browsing.  If you are not familiar with Doxygen, it may take some experimentation to learn your way around.  When you open the file, click on "Golbals" in the left panel.   Then click on "Functions", "Variables", or "Defines" to see lists of all objects in those groups, or while still in the "All" tab, click on any letter for a list of all objects starting with the letter.  e.g. to find the main function, click on "M", then next to the main() label, click on Keyer-AVR.c, the source module name in which the main() function lives.  This takes you to the documentation for each defined function.  If you click on the line number shown, that will take you to the specific function.  If you click on the actual file name this time, it will take you to the top of the source code module.
As with the source code, this HTML documentation also will not be updated with any frequency.
Front panel fabrication service of possible interest:  http://www.frontpanelexpress.com/company/news/index.html  .  This company was pointed out to me by K6KX and I have done a test order for a simple front panel to see how the process works.  My prototypes have all been done using a hand drill and nibbler so far.  The results are not pretty.  I intend to use the front panel as an "overlay" on the front of an enclosure to see how that turns out.  The test front panel has been received in good order.  The primary goal of insuring that I had the hole pattern for mounting the LCD display was accomplished.  The next iteration will include silkscreen and countersunk holes, unlike the test panel.  These are not cheap, but it is definitely nice to have machined panels.
W5UXH, Chuck
Las Cruces, NM