Online Since 1995
Cribbage Board #10
Adventures / Interests
WEDDING BOARD CODE & FIRMWARE
The firmware for the Wedding Board was initially written by Shannon Gomes and debugged and finished by Red Byer.
The early code for pulse-width modulation of an RGB LED was reverse engineered (and inspired by) the Color Kinetics line of LED products. This first generation of code was written for the Zilog 8-bit miconcontrollers (because the development tools were free).
However, as miniaturization became the goal, Shannon discovered the beauty that is the AVR 8-bit microcontroller product line. The Atmel AVR microcontrollers had some clear advantages, including: (1) the small size (2) on board clock circuitry (3) on board EEPROM (3) active and supportive hobbyist community (4) In-System-Programmable and reprogrammable capability and (5) free development tools and nearly free programmer tools.
From there, it took quite a bit of layout work and several rough prototype PCBs burned in my garage. At this time, I was investigating direct etching of waterproof ink-jet prints onto thin copper sheet. (mixed results, and I digress). The pegs at this point were much more like jewlery than designed objects, each taking hours to assemble.
The code for the pegs was written in assembly using AVR Studio. Programming in C was not an option at the time, since a majority of the C-compilers (specifically CodeVisionAVR) did not support the ATTiny12. Additionally, AVR Studio 4 still had issues and did not correctly emulate the Tiny12 processor for debugging, so we still relied on AVR Studio 3.5 for debugging work.
After the initial color wash code was completed, it was determined that there was enough code space to add several other modes. The solid color modes would all be similar to a standard colorwash, except that they would cycle between the same 3 colors. The overlay modes were more complex and involved interrupt driven masking. For a graphical explanation, check this out.
Seeing as we were out of pins on the Tiny12 and we wanted a player to be able to switch modes without a hassle, it took some brainstorming to figure out how to communicate with a peg. Because of the AVRs ability to determine the source of a reset (brown out or soft reset) it was possible to put together a simple on/off power cycle protocol for communicating state changes (a feature eventually not used in the pegs). We settled on an on/off cycling protocol that simply uses a time-delay and an EEPROM flag to determine if the last power cycle was done quickly enough (intentional programming cycle) or was simply a "pegging" event.
Because we were using the EEPROM to monitor every single power cycle, both Shannon and myself shared concerns over the longevity of the on-board EEPROM in the AVR devices. With a stated lifetime of 10,000 write cycles, we were concerned that repeated playing and on/off programming would quite literally wear out the electronics. Shannon found the nifty dual circular buffer algorithm (seen here). With the dual circular buffer in place, we figured it would take greater than 10,000 average games of cribbage to wear out the EEPROM cells inside each peg. As a final precaution, should the EEPROM become corrupted, the peg will simply enter the basic color washing mode.
Standing in stark contrast to the complexity of the Peg code was the Programmer Board code (flowchart here). The Programmer Board simply checked the source of reset, read the desired state off of a 16-position rotary switch and then cycled the power the appropriate numbers of times. Since the simple nature of the on/off cylcing is prone to off-by-one errors, extra code was included to effectively quadruple (easier than tripling in an 8-bit world) the number of cycles and isolate count values. However, this redundancy was not implemented since (1) this forces the user to sit around longer, (2) this wears out the EEPROM that much faster and (3) it is not the end of the world when a peg is misprogrammed.
In the end, the programming count value and the time to program were tweaked to a reasonable amount (yet kept slow enough that pegs could still be hand programmed as a party-trick). A progamming cycle takes only a second or two and includes a R-G-B sequence to indicate completion. Finally, a significant amount of time was spent debugging the interrupt loops to prevent unstable behavior.
While the code is not the most efficient (in terms of register use and timing), it is stable. A serious round of resource optimization would be possible and beneficial but is not planned (seeing as everything works just fine right now).
These are simple rich-text files.
DISCLAIMER: Please do not copy/share/distribute the firmware code without prior written permisson from myself. As with the GNU public license, you may use snippets of the code in your own NON-COMMERCIAL project so long as you provide some due credit (in the comments, etc).
Although available from the Atmel site, here's the .inc file for the Tiny 12.
March 2, 2008