ECE 477
Digital Systems Senior Design Project
Spring 2009
Homework 9: Software Design Considerations
Due: Friday, March 27, at NOON
Team Code Name: Not So Deep Blue___________________________ Group No. 10____
Team Member Completing This Homework: John Fawcett_________________________
E-mail Address of Team Member: jfawcett@ purdue.edu
NOTE: This is the last in a series of four “design component” homework assignments, each of
which is to be completed by one team member. The body of the report should be 3-5 pages,
not including this cover sheet, references, attachments or appendices.
Evaluation:
SCORE
DESCRIPTION
Excellent – among the best papers submitted for this assignment. Very few
corrections needed for version submitted in Final Report.
Very good – all requirements aptly met. Minor additions/corrections needed for
9
version submitted in Final Report.
Good – all requirements considered and addressed. Several noteworthy
8
additions/corrections needed for version submitted in Final Report.
Average – all requirements basically met, but some revisions in content should
7
be made for the version submitted in the Final Report.
Marginal – all requirements met at a nominal level. Significant revisions in
6
content should be made for the version submitted in the Final Report.
Below the passing threshold – major revisions required to meet report
*
requirements at a nominal level. Revise and resubmit.
* Resubmissions are due within one week of the date of return, and will be awarded a score of
“6” provided all report requirements have been met at a nominal level.
10
Comments:
Comments from the grader will be inserted here.
Overall good, discuses the functionality of modules well. This would benefit from dividing each
section into individual modules, such as SPI, I2C, etc.
ECE 477
Digital Systems Senior Design Project
Spring 2009
1.0 Introduction
The Not So Deep Blue Project will enhance the playing experience that users get while
playing the game of chess. For beginners, it will allow them to obtain a deeper understanding of
the game; the rules, the possible moves, etc. For the veterans, it will bring playing chess to a
new level by allowing them to focus on their next move rather than worrying about time,
location of pieces, and being able to safely save a game.
Game play needs to be responsive. The software needs to be designed to allow the players to
experience the game without having a noticeable delay from picking up or setting back down a
chess piece, to the LED lights under the game board being updated with the proper new
information.
2.0 Software Design Considerations
The chessboard is being controlled by an Atmel ATmega128 microcontroller. The
ATmega128 has 4kb SRAM and 128kb Flash storage and will be running at 16 MHz.
All software is being written in C and we are using AVR C Runtime Library (avr-libc) [3]
for ATmega128 specific libraries, WinAVR [4] for compiling the code using avr-gcc, and
AVRDUDE [2] to program the microcontroller. Avr-libc contains libraries with port and
memory mappings eliminating the need for us to be concerned about the lower-level memory
mapping specifics [1].
For input sampling, we are using the 8-bit Timer 0 of the microcontroller, which uses
registers TCCR0, OCR0, and TIMSK. The 6 touch sensors are set up as inputs on registers
PORTA and DDRA, with their state being read on register PINA. The reed switch matrix is
handle over SPI, which uses registers PORTB and DDRB [1].
For outputs, the 16-bit Timer 1 is being used, which uses registers TCCR1A, TCCR1B,
TCCR1C, ORC1A, and TIMSK. All PWM values for the 12 LED Drivers displaying the board,
and the other LED Driver displaying player timers is done over I2C (referred to by TWI in the
microcontroller manual and avr-gcc header files). I2C uses registers TWBR, TWSR, TWCR,
and TWDR. Debugging messages with UART to a computer over RS-232 uses registers
UBRR1, UCSR1B, UCSR1C, and UDR1.
Our main constraint is the 4kb of SRAM. The software needs to be designed to be very
efficient with variable sizes and procedure call depth. Keeping information hard-coded in
-1-
ECE 477
Digital Systems Senior Design Project
Spring 2009
lookup tables and shrinking variable and array sizes will help tremendously as the software needs
to keep track of what is happening on 64 different spots on the board, as well as overall game
information such as game time and player control.
When powered on, the program will perform all necessary on-chip initializations (setting up
timers, SPI, and I2C/TWI mode registers) then proceed to initialize the I/O expander via SPI and
the 13 LED Drivers over I2C (the latter can be done all at once using an ALL_CALL address for
those chips).
After initialization, a timer will start that will run an input-sampling loop over SPI. A
second timer will be used in similar fashion to refresh the LEDs over I2C. These will be run on
a regular interval that is fast enough to not be a burden on the chess player, but slow enough to
allow for all of the SPI/I2C communication to complete before trying to perform another refresh.
The main loop will just check to see if the input-sampling loop got anything new back (a piece
was picked up or set down, or a touch sensor was pressed) and then perform the corresponding
action. This is more or less event driven, as it will only perform anything if there has been an
input change.
If it was detected that a piece has been picked up, then it will run the possible moves
algorithm (which also will check if a move would put them in check and thus invalidate that
move) and change all associated board locations to have a new temporary state. Before
triggering another LED board refresh, the I2C timer will increment or decrement temporary
game location state variables to create pulsing and/or fading of the LEDs.
To help with development and debugging, there will also be UART communication from the
ATmega128 to a computer terminal’s serial port to allow viewing of print messages and possibly
sending input commands if we determine it is needed later.
3.0 Software Design Narrative
The code is broken up into the lower-level communication libraries (I2C, UART, SPI),
the higher-level core game logic, and the mapping methods to go between the two levels.
The I2C block generates START and STOP signals, sends an address byte, and sends an
array of data bytes. We have this block written and working completely as function calls where
we wait for the actual bytes to be sent before doing anything else. The last step is to convert it
into an ISR that will use global variables to know what the next byte to send is.
-2-
ECE 477
Digital Systems Senior Design Project
Spring 2009
I2C is used to send new LED brightness values to the LED Drivers [5]. We have code
written and tested (with just one LED Driver) that will update all 13 LED Drivers’ 16 LED
PWMs with their respective values. The LED timer will be changing temporary LED values
before starting to refresh the LED board.
We have finalized the LED Driver [5] initializations needed to be able to output values
on all 16 LEDs connected to them. We can perform this initialization to all 13 LED Drivers at
once by sending data to an ALL_CALL I2C address that all LED Drivers listen to on top of their
individual I2C addresses. When refreshing the LED board we iterate through all 13 LED Drivers
sending a starting register and mode as the first data byte (this is the same for all LED Drivers)
followed by the PWM values for all 16 of the LEDs connected to that LED Driver.
There is room for efficiency improvement in the way we store and send the 208
individual LED values to the 13 LED Drivers. Each game board location (out of 64) the red,
green, and blue LEDs are connected to the same PWM number, but on 3 different LED Drivers.
Also, game board locations will be in a “state” (active piece, occupied black, possible move,
possible attack, etc) that will map back to RGB values so we do not need to store 208 individual
LED values and can save SRAM space there.
The SPI block handles the SPI protocol, which, unlike the I2C block, will need to handle
receives. This has been written and works for function calls where we wait for the bytes to be
sent before doing anything. We have converted it into an ISR but have not tested its
functionality.
The SPI timer will sample the touch sensor inputs and start the I/O expander polling ISR.
The results will be set for the main loop to check and compare to its last-known inputs. The code
for this needs to be further developed and we need to finalize a format for organizing the input
states.
The core game logic loops checking if there has been a change in inputs from the SPI
timer. If there was a change in the I/O expander’s inputs then it will run update game state
which may be either calculating possible moves and check (a piece is picked up), or removing
possible moves and possibly detecting a piece capture (a piece was placed down). Possible move
and check/checkmate detection is laid out in pseudocode and needs to be implemented. To track
the state of a game (also used when saving/loading a game), we have an 8x8 array (representing
all the squares on a chess board) that for each location in the array it stores 4 things. First is
-3-
ECE 477
Digital Systems Senior Design Project
Spring 2009
stores whether that location on the chess board is currently empty or not. Then it stores which
player has a piece there, and what type of piece it is. It also stores whether the piece has ever
been moved since the start of the game (used to determining if a castle is permitted).
The UART block allows us to send printf() commands to a computer’s serial port for
development and debugging help. This has been coded and works. With the UART library
included, just run its initialization and then all printf() commands will be transmitted out and we
have verified receiving it on a computer terminal screen.
4.0 Summary
There will be timers to trigger polling the inputs and to refresh the board LEDs. Only
when a change in inputs is detected will the core game logic need perform some operation.
From a completion standpoint, we have all communication protocols working and only
need to finalize them into ISRs. The core game logic needs to be converted from pseudocode
and the mappings/lookup tables need to be finalized for going from SPI inputs to game board to
LED Driver data. We also need to define the operation of touch sensor inputs and finalize how a
user will load a saved game and set the board back up correctly.
-4-
ECE 477
Digital Systems Senior Design Project
Spring 2009
List of References
[1] Atmel, [Online].
http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf.
[Accessed: March 26th, 2009]
[2] AVRDUDE, [Online].
Available: http://savannah.nongnu.org/projects/avrdude/. [Accessed: March
26th, 2009]
[3] AVR C Runtime Library, [Online]. http://savannah.nongnu.org/projects/avrlibc/. [Accessed: March 27th, 2009]
[4] WinAVR, [Online]. http://winavr.sourceforge.net/. [Accessed: March 27th, 2009]
[5] LED Driver Product Sheet, [Online].
http://focus.ti.com/lit/ds/symlink/tlc59116.pdf. [Accessed: March 27th, 2009]
IMPORTANT: Use standard IEEE format for references, and CITE ALL REFERENCES
listed in the body of your report. Any URLs cited should be “hot” links.
-5-
ECE 477
Digital Systems Senior Design Project
Appendix A: Flowchart/Pseudo-code for Main
Program
-6-
Spring 2009
ECE 477
Digital Systems Senior Design Project
Appendix B: Hierarchical Block Diagram of Code Organization
-7-
Spring 2009