Project Summary/Goals

A tic-tac-toe game was designed. It was programmed for two players, with the game recording whose turn it was at a particular time. Possession of a square was indicated by the lighting of either a green LED (representing x’s possession of the square) or a red LED (representing o’s possession of the square). The initial project proposal discussed the possibility of incorporating a sound with the claiming of each square. However, it was decided to leave that out of the actual project due to time constraints.

Error checking was incorporated into the program, prohibiting selection of the same square twice. The game continually checked for two scenarios: a winner (3 in a row), or if every square had been selected without a winner. The game board’s lights responded differently to each of these cases to indicate completion of the game.

Project Status Reports #1, #2

Background

This was a valid and worthwhile project because it provided insight into the programming and using the 8051-family micro-controllers. It also reinforced the ideas of hardware/software co-design and simulation. That is, preliminary code was written as soon as a sufficient design was accepted by all members of the group. Several changes were made in both software and the hardware design throughout the process. When the hardware was actually implemented, we had a good idea that the software functioned properly due to it’s simulation earlier in the process.

Another worthwhile aspect of the project was the initial tic-tac-toe design (see website) used several components which were discussed in the Digital Systems Design class, such as PNP transistors and the crystal oscillator. Likewise knowledge of circuits and programming was essential to the successful completion of the project.

Code

For the code which runs the tic-tac-toe game, follow this link:

Schematics

Initial Design

Final Design

Connections from 89C51RC2 micro-controller used in our project

Photo of final project

Final Parts List

  • 1 Solderless breadboard
  • Breadboard wire
  • 89C51RC2 -Controller
  • Momentary push-button switches
  • Quantity: 10
  • Vendor:Digikey
  • Description:Light Touch Bi-directional Switch
  • Price:$1.0920 each
  • Red LED
  • Quantity: 10
  • Vendor:Digikey
  • Description:LED, red clear, round, flat top
  • Price:$0.215 each
  • Green LED
  • Quantity: 10
  • Vendor:Digikey
  • Description:LED, green clear, round, flat top
  • Price:$0.224 each
  • 470  used limit current through LED’s
  • Quantity:20
  • obtained in HKN Student Projects Lab
  • 10 K resistors for the pull up resistors not present on port 0 of 8051-family
  • Quantity:8
  • obtained in G-10 lab of EE building
  • 1 capacitor from output of voltage regular to ground of voltage regulator
  • Quantity:1
  • obtained in G-10 lab of EE building
  • 7805 5V voltage regulator
  • Quantity: 1
  • Vendor:Radio Shack (Rolla)
  • Price:approximately $1.70
  • Oscillator crystal
  • Quantity:1
  • Vendor:Digikey
  • Description:11.0592 MHZ Quartz Crystal (HC-49)
  • Price:$0.80
  • 9-Volt battery
  • Quantity 1

Summary of Simulation Techniques

Software

To simulate the software, the code was compiled and the debug scenario was started in Keil -Vision software.

Tin the debugger, values on Port 0 and the first pin on Port 1 were manually changed. This basically took the role of switches being individually pressed. Then all of the other variables were checked to confirm that they were what they should be with that particular switch simulated as pressed (game board got the right player in the right position, proper LEDs werelit, a winner was detected when it should be, etc.). Scenarios such as two switches pressed at once, and other erroneous possibilities were entered to determine the reactions of the other variables. If a reaction was not a desired one, the code was changed to fix it. Once the program simulated without problems, it was loaded onto the microprocessor.

Hardware

Simulation in hardware was largely a process of trial and error. Many versions of the program (and test programs) were flashed to the microprocessor in this portion of the project. If the program was not running correctly, voltages on switches and pins were measured to possibly detect what part of the hardware was not functioning properly. At this stage, confidence was high that the code was correctly written, since software simulation had been completed. Therefore, it was largely assumed that any problems were due to hardware glitches.

Operation of Tic-Tac-Toe Game

The logic of the tic-tac-toe game is very simple. It follows the basic rules of standard two player tic-tac-toe and doesn’t allow cheating. The game is played as follows:

  1. Turn the game on. This is currently done by plugging in a 9V battery into the appropriate connector.
  2. Press one of the nine game switches to make a move in the spot associated with the switch you have pressed.
  3. Allow your opponent to make his/her move.
  4. Continue until the game is over.

The 8051 handles the task of determining whose turn it is, lighting up the appropriate LEDs, and determining if there is a winner. The basic microcontroller operations, as the game progresses, are as follows (assuming that power has been attached and the “Reset” button has been pressed):

  1. The green LED is lit up to indicate that it is green’s turn (green always has first turn).
  2. The switches are scanned by a while loop until a switch is pressed—which effectively grounds the microprocessor pin to which it is connected.
  3. It is determined which switch is pressed by calling a location function that looks for a low pin voltage on the pins connected to switches. The only grounded pin is the pressed switch.
  4. The switch location (and the player that pressed it) are stored in a three-by-three game board array.
  5. A check is run to see if there is a winner by calling a function that looks at the data in the game board array and returns the player who won and where they won.
  6. If there is no winner and no CAT (non-winning, complete) game, the LED of the move made is lit up by grounding the pin connected to the LED corresponding to the player and the position.
  7. The current player is changed to the other player and the cycle is repeated.
  8. If there is a winner, a function is called which turns off all LEDs but the ones that correspond to the three locations that constituted the win and color of the winner and also the player LED of the winner.
  9. The computer then waits for the reset button to be pushed (tied to Vcc) to begin a new game.

Work Distribution

Project Design – Butchko, Hargis, Wingett

Code – Butchko

Code/Software Simulation – Butchko

Web – Wingett

Reports – Wingett, Hargis, Butchko

Schematics – Butchko, Hargis

Parts – Hargis, Butchko, Wingett

Hardware Assembly – Butchko, Wingett, Hargis

Debugging – Butchko, Wingett, Hargis, Jackson

Presentation – not completed yet

Administrative – Hargis

Project Results

The completed tic-tac-toe game met all initial project goals, except the possibility of incorporating a sound when a space was claimed by a player. That feature was neglected because the team decided to limit the complexity of the project. The project was a success, even though at this point we are not sure why the last switch (tied to a different port than the others) does not work.

Some valuable lessons about design were gained through completion of this project. When we first began our project, we very quickly came up with a design and began coding for it. (See our first design schematic and code: WEB ADDRESSeS). We had not, however, sat down to consider if our first design was the easiest, quickest and least expensive to implement.

We followed this design through to successful simulation of the code, and obtaining all the parts. After all of that work, we discovered that port 3 could be used as a general port, just like ports 0, 1, and 2. Therefore, we had enough ports/pins that we could tie each individual LED and switch directly to a pin. This was a much simpler and cost efficient design. Although it was late in the process, coming up with a better design was a great success, and probably saved us headaches when it came to building and testing the actual device. It was noted, however, that our initial design would be better if the design needed to use the fewest pins possible, or if other parts were taking up space on some ports.

In future projects, it would be a wise idea to read some pages out of the parts manual on the microprocessor before beginning, so specifics about the chip are known.

Reading the parts manual would have also helped in the hardware testing and final debugging stages of the device. We found out that port 0 needed pull-up resistors external to the chip. We also found out that it was necessary to tie the EA/ pin high to read from internal memory, and to tie the PSEN/ pin high while resetting the chip, but allowing it to float after reset.

This project could be expanded to include the ability to play against the computer. It could also incorporate the sound feature discussed earlier (however any extra devices could mean partial redesign, since we used all but a few pins on the chip).