Our project is a two player touchscreen controlled speed chess game.
One of our goals for this project is to build a reliable touchscreen device. Our initial plan was to use an LCD and attach LED and phototransistors on opposite sides. However, we determined that most commercial LCDs are small and placing 8 LEDs/8 transistors on each sides is difficult and there could be a lot of interference between adjacent LCDs and transistors. Our instructor Bruce Land advised us to use a 6 inches diagonal TV and we found that we can actually place the LEDs and transistors with sizeable width between each LEDs/transistors so that interference is minimal. We were lucky to get access to video generation code from the ECE 4760 website which we used to generate the screen on the TV. We also used bitmaps to generate the graphical representation of the pieces. Over the process of 5 weeks, we actually made changes to our initial plans an design. For example we planned to tape the LEDs and transistors to the TV, but when we were not satisfied of the sturdiness and the accuracy of our touchscreen, we used a foamcore and used it as a base to put the LEDs and transistors on. This new design made our touchscreen more accurate. To make our device even more accurate and sturdy we taped the foam core to the TV.
We successfully implemented the first part of our proposal. We also planned to use a transceiver to transmit/receive data between two MCUs connected to TVs using which two users could play a wireless 2 -player game. However, due to shortage of time, we could not implement that feature. We did not have enough time to build the touch screen feature for another TV and to develop the wireless connection. Furthermore, our program uses a lot of data memory and we did not have enough memory in our MCU to properly interface with another MCU to run the two player game.
1. High-Level Design
1.1 Rationale and Sources of the Project Idea
Programming a relatively complicated game, such as chess, to be displayed on a TV would provide the opportunity to combine material covered in Microcontrollers (ECE 4760)—such as timing, concurrency, and general C programming for the ATMega644 microcontroller with GCC—with relevant material not covered in the course this semester—such as video generation. After discussing the proposal, the professor suggested that we add some significant hardware component that would require hardware-software interaction. As a result, we decided to develop a touchscreen chess game, which had substantial hardware and software components to it.
1.2 Background Math
The mathematics used in the touchscreen chess game software did not require any complex mathematics. Our program makes use of simple arithmetic to calculate valid moves for each individual chess piece. Furthermore, modulo and division operations allowed the program to determine the address of any particular chess tile based on the numerical address that we assigned to it.
1.3 Logical Structure
The logical structure of this project is to build a touchscreen and to run a game of chess on it. A user will be able to touch any of the chess tiles and thus block off infrared light to certain phototransistors, which would allow the microcontroller to compute which chess tile was selected. Once a chess tile is selected, the user would be able to select a different chess tile for the selected piece to move to. The software we program will concurrently continue updating the screen while running chess algorithm code to check whether desired move adheres to the rules of chess or not.
1.4 Hardware/Software Tradeoffs
The hardware is not as exact as we would hope: we count on the LEDs emitting reasonably straight beams of infrared light to the corresponding, opposite phototransistors and thus allowing these phototransistors to input voltage data into the MCU that would allow it to determine the chess tile selected. These LEDs and phototransistors are not perfectly directional, thus our design suffered from multiple LEDs shining infrared light diagonally into phototransistors even when the LED right opposite the phototransistor is blocked off. Nonetheless, this design made sense to us, and we found a reasonable solution to offset the issue.
In terms of software, our only real tradeoff was number of lines of code vs. efficiency of the code. In some cases, it would take the MCU less time to copy multiple large similar versions of code in divided if-statements than to incorporate these if-statements into one large such chunk of code.
1.5 Relationship of design to available IEEE, ISO, ANSI, DIN, and other standards
Our project is relatively safe considering we do not use any flammable or explosive material. Our touch screen interactive chess game should also be user friendly as humans like touch screen devices. We also did not make use of other people’s work without acknowledging them.
1.6 Existing Patents, Copyrights, and Trademarks relevant to the Project
As we only made use of “beer-ware,” student projects from previous years, and course material and advice provided by the TAs and the professor, we did not have to deal with any patents, copyrights, and trademarks.
2. Software Design
2.1 Initial Structs and Definitions
The complicated chess algorithms and interrupt service routines in our software require us to instantiate numerous variables, constants, and struts. location_piece refers to the location of the chess tile that the user has most recently touched on the touchscreen or is currently touching. old_location_piece refers to the location of the chess tile that the user has previously touched. Please see the Debouncing section of this report for a detailed explanation of loc_deb, loc_deb_count, and the #defined loc_deb_lim. The variable possible is 1 when the user has touched two chess tiles, such that the chess piece in the initial chess tile the chess piece in the first chess tile can legally move from old_location_piece to location_piece. If the user attempts a move that the rules of chess do not allow, the variable possible will become 0. start_move_x and start_move_y are respectively the x and y coordinate positions of the location of the piece selected by the user to be moved. stop_move_x and stop_move_y are respectively the x and y coordinate positions of the second tile selected by the user to move the chess piece to. We also initialize a series of chars that designate whether certain chess pieces have moved or not. For example, SolidKingHasMoved will be 1 when the solid king has made a move this game and will be 0 when the solid king has not yet moved this game. These variables are necessary to implement more complicated chess moves such as castling. The unsigned char choosePiece means that a piece has been chosen to move, and the unsigned char moveToDestination means that a location has been chosen for the chess piece to move to. The #defined value lineTime is the time required by the microcontroller to update all the lines on the TV that we are using. The #defined value sleepTime is the time we put the microcontroller to sleep. ScreenTop is the top line on the TV that the microcontroller prints to, and ScreenBot is the bottom line that the microcontroller prints to. We #define each different chess piece (on both sides) in order to easily be able to define them. Finally, LineCount is the line number in the current frame, and the screen array is used to designate how much memory we allocate to writing a certain set of graphics to the TV.
In order to debounce the selection of a particular chess tile, we instantiated unsigned chars loc_deb (location debounce) and loc_deb_count (location debounce count), and we #defined loc_deb_lim (location debounce limit) as 10. We always maintain the unsigned char variables location_piece, referring to the location of the chess tile that the user has most recently selected, and old_location_piece, referring to the location of the chess tile that the user has previously selected. As such, the user would select one of his/her chess pieces (the location of which would be stored in old_location_piece) and would then select an empty chess tile or a chess tile containing a chess piece belonging to the opponent (the location of which would be stored in location_piece), and the user’s chess piece would move from old_location_piece to location_piece. It is these two variables that are debounced: the first time the user selects a chess piece by touching the location of the piece’s chess tile on the touchscreen, loc_deb is set to a numeric constant between 0 and 63 (inclusive), corresponding to this location; for every cycle (approximately 1/60 of a second) that the user continues to touch this location, loc_deb_count is incremented; once loc_deb_count reaches loc_deb_limit (10), old_location_piece is set to location_piece and location_piece is set to loc_deb, as shown schematically in the figure below:
|Parts||Source||Unit Price||Quantity||Total Price|
|Custom PC board||Lab||$4.00||1||$4.00|
For more detail: Touch screen video chess Using Atmega644