15 Puzzle

Design Document

James Beukers
Jordan Jacobson
ECE 3710; Project 2
May 3, 2013
 15 Puzzle

Table of Contents
List of Figures 2
List of Tables 2
1. Introduction 3
2. Scope 3
3. Design Overview 3
3.1 Requirements 3
3.2 Dependencies 3
3.3 Theory of Operation 4
3.4 Design Alternatives 5
4. Design Details 6
4.1 Hardware Design 6
4.2 Software Design 7
4.2.1 Register Configuration 10
5. Testing 11
5.1 Test 1-Hardware 11
5.2 Test 2-Menu 11
5.3 Test 3-Scramble 12
5.4 Test 4-User touches and game actions 12
5.5 Test 5-Save high scores 12
5.6 Test 6-Solve-it function 12
6. Conclusion 12
Appendix A-Hardware schematic 13
Appendix B-Software 14

List of Figures
Figure 1: The main menu 4
Figure 2a: Completed puzzle 4
Figure 2b: Scrambled puzzle 4
Figure 3: Winning state 4
Figure 4: High score menu 5
Figure 5: Second level 5
Figure 6: Hardware Setup 6
Figure 7: Software Flow Chart 7

List of Tables
Table 1: LCD Register Configuration 10
Table 2: Touch Panel Register Configuration 10
Table 3: Timers and DAC Register Configuration 10
Table 4: Real Time Clock Register Configuration 11

2
 15 Puzzle

1. Introduction
The 15 Puzzle Game was invented by Noyes Palmer Chapman around 1874. The classic version of the
game consists of a square board that contains 15 numbered squares. Because there are only 15 num-
bered squares, there is a blank square on the board. The game is played by moving the numbered
squares on the board until the numbers are in order from 1 to 15, starting with the 1 square in the top
left corner. These puzzles are also very often made with a picture broken into 16 squares, with the
bottom right square being removed. Now-a-days the 15 puzzle can be played on a computer or a hand
held electronic device. The game is greatly enhanced on an electronic device because the device has the
ability to keep track of a high score, output sound, and introduce multiple images to have as the basis of
the puzzle. In this project a 15 Puzzle game is implemented using the STM32F103 ARM Microcontrol-
ler and a 3.2" TFT LCD Display Module.

2. Scope
In this document an overview is given of the 15 Puzzle game design which is based upon requirements
outlined in the project proposal. Included in this document are the explanations of the methods and
techniques in which the project was designed, implemented and tested in order to meet the require-
ments that are outlined in the project proposal. Also included are digital images to help the reader more
fully understand the description of the design. There are two appendices, one of which contains a
hardware schematic, and the other which contains the full code of the program excluding the very large
and bulky hexadecimal arrays that store the data for the images that are used. Because the hexadecimal
arrays that store the images are so large only the declarations of the arrays have been included without
all of the hexadecimal values.

3. Design Overview
3.1. Requirements.
1. It shall display a picture on the LCD screen.
2. The game shall have a menu in which the user can make a selection (play puzzle, check high
score)
3. It shall scramble the picture into different blocks.
4. It shall recognize user touches on the touch screen.
5. The game shall make corresponding action based on user touch location. If user touches a
button the program shall access the button, if the user touches a block, it shall move the block
accordingly.
6. It shall output sound.
7. The fastest time and smallest number of moves shall be saved to nonvolatile memory.
8. It shall also have a solve-it function that shows the steps to solve the puzzle (optional)

3.2. Dependencies.
5 volt power source
8 MHz Oscillator
3.2" TFT LCD Display Module /Touchscreen
Analog test board
STM32F103 ARM Microcontroller

3
 15 Puzzle

3.3. Theory of operation.

Upon power on or reset, the main menu
is displayed on the LCD as shown in
Figure 1. The program then waits for a
user selection and displays the corre-
sponding screen. If the game play
screen is chosen, the puzzle is shown
for one second as seen in Figure 2a and
then the puzzle is scrambled with the
16th square deleted as shown in Figure
2b.

a) b)
Figure 2: The completed puzzle is shown for a moment (a)
and then is scrambled and a square is deleted (b).

The user is then required to press the screen over a block ad-
jacent to the empty square. Nothing occurs if the user presses
on a block not adjacent to the empty square.

After the user makes a move the timer is started and the num-
ber of moves is displayed and incremented after each move.
Included in the game play screen are two buttons displayed at
the bottom of the screen.
One is the ‘menu’ button,
to return to the main menu
Figure 1: The main menu and the other is a ‘solve’
button (this is also seen in
Figure 2b).

If the user presses the solve button, the program proceeds to

solve the puzzle from the current state and will continue until the
puzzle is solved.

After each user move, the program checks to see if it is in the

winning state. If it is, then the timer is stopped and the time, as
well as the number of moves, is displayed. The number of moves
and time are then compared with the current high score values
and if necessary are loaded into the Flash memory as the new
high scores. In the winning state as seen in Figure 3 the screen
also displays a flag with “Congratulations!! YOU WON!!” and Figure 3: The LCD screen
the speaker outputs a triumphant trumpet sound. The user may showing the winning state of the
then select to go back to the menu by pressing the menu button game. At this point as well, a
or choose the shuffle button (now in place of the solve button) to triumphant sound is played.
reshuffle the squares and restart the game.
4
 15 Puzzle

If the high score menu is chosen the high scores are dis-
played as shown in Figure 4 as well as a menu button to re-
turn to the main menu.
3.4. Design Alternatives
As more puzzles and sounds were created it was found that the
microcontroller did not have sufficient memory to fit the code.
Options including using the SD card to provide more memory
were looked into; however, there were difficulties with the
SDIO module sharing pins with other modules on the board and
time did not permit for these issues to be solved.

Figure 5 (below to the right) shows the second puzzle which

consists of a picture rather than numbered blocks. Using a pic-
ture adds difficulty as well as variety and color to the game. It
was discovered, however, that due to the limited memory of the
board both levels could not be loaded to the board at the same
time. The second level of the game is in a separate header file
Figure 4: High scores: the least
that can be loaded to the board, so both levels can be played
number of moves and the quickest
depending on the header file that is added.
time.
An alternative method that would allow multiple levels would be to
create a function to draw the separate squares rather than have a
saved table of pixel values. This alternative however, would create
bad graphics and require a total rewrite of the code.

Another alternative method that was considered was to have the pic-
tures used for the puzzle formatted differently. Lower quality pictures
were implemented but the results were very undesirable, causing dis-
coloration and difficulty in distinguishing each square.

A method using the same pixel table to draw the blocks and then the
numbers on top of the blocks separately was also considered. This
method would save memory because only one pixel table instead of
fifteen would be needed; however, this required lots of new code and
would reduce the quality of the graphics.
Figure 5: Shows another
These methods were not chosen due to the poor graphic quality and level to the puzzle game
the amount of time it would take to alter the code to allow these new adding more difficulty as well
methods. as variety and color.

A method to save the high score in nonvolatile memory in the LCD as a pixel was considered, however,
the better option of saving to Flash memory was chosen. Flash memory was chosen because saving the
high score to a pixel would create an odd pixel on the screen and would require code changes to ensure
that it never got erased.

Instead of using the ASCII text functions provided in lab 6 for the menu screen and high score screen, it
was considered to create buttons similar to those used in the current game play screen (see Figure 2b).
This would create a much better looking interface as well as provide for a greater uniformity between
the different game screens.
5
 15 Puzzle

4. Design Details
4.1 Hardware Design
15 Puzzle is implemented on an STM32F103 ARM Cortex-M3 Microcontroller board. The game
hardware consists of a 3.2" TFT LCD Display Module/Touchscreen connected to the LCD Port on
the board as seen in Appendix A and an analog test board connected to the 5V, GND, and Port A5
pins of the board as also seen in Appendix A. The game is also dependent upon the external 8MHz
oscillator and a reset button included with the board, as well as an external 5V USB power supply
(see Appendix A).

The game is displayed through the LCD module and receives user input through the touchscreen.
The touchscreen is connected to the microcontroller through SPI and shares Port A5 with the DAC
output for the speaker. The speaker on the analog test board is used to output the game sound. Be-
cause Port A5 is shared by both SPI and the DAC it is necessary to disable the DAC when using SPI
and visa-versa so that each functions properly when needed. Remapping the pins or using another
SPI module is not an option as the remapped pins and other modules share pins with the LCD mod-
ule on Port B.

Figure 6: picture of hardware setup.

6
 15 Puzzle

4.2 Software Design

The 15 Puzzle software design has four main states: the Menu Screen, the High Score Screen, the
Game Play Screen, and the Winning Screen. The Menu Screen displays two options to the user. They
can select to look at the high score or play the game. The High Score Screen displays the fastest time
the game has been won in, and the least number of moves made to win the game. The Game Play
Screen displays the puzzle and allows the user to play, select to use the solver, or go back to the menu.
The Game Play state also keeps track of the number of moves made, and the time it takes to win. Once
the game has been won the user has the option to shuffle the puzzle and start over at the Game Play
Screen, or go back to the menu. The winning state displays a congratulations message on the screen,
outputs a sound, outputs the time it took to win on the screen, and checks if the score was a high score.
If the score was a high score it is saved to the flash memory on the microcontroller.

Menu Screen

Game Play High Score

Play Solve Menu Button

Start Time

Count Moves

Check User Push

Winning State

Output Time
Shuffle Button
Output Sound
Figure 7: Flow Chart of Software Design
Save High Score
7
 15 Puzzle

Code Outline
The code for the project consists of three C files: main.c, lcd.c and touchscreen.c. The main.c
file is very short and just contains configuration function calls, and a switch statement to de-
termine which screen is displayed. Inside the cases of the switch statement there are function
calls to display the screen for the appropriate state. Case 0 of the switch statement is the
Menu Screen, Case 1 is the Game Play Screen, and Case 2 is the High Score Screen.

The C file lcd.c contains all of the functions to configure and use the LCD display. See Table
1 on page 10 for details on the configuration. The majority of this code is the same as the
code from lab 4, with some necessary changes in order for it to be compatible with this pro-
ject.

The C file touchscreen.c contains the bulk of the code for the project. The desire was to have
more C files that contained just a few related functions. However, due to issues with global
variables accessed by many different functions, a large majority of the code was placed in the
touchscreen.c file. This file also contains the configurations of the touch screen, timers, DAC
and RTC. See Tables 2-4 on pages 10-11 for details on these configurations.

For more details on the code for the project see Appendix B which contains the full code for
the project. The code has very detailed comments that should be easy to read and understand.

Description of Flow Chart

Menu Screen State
When the program starts it is set to the Menu Screen state by default and the "menu"
function is called from Case 0 in the switch statement in main.c. The menu function
is defined in touchscreen.c. The menu function makes use of the ASCII table and
functions from lab 6 to display the two menu options of "Play 15 Puzzle" and "High
Score". Once the user presses on one of those options, the program proceeds to the
corresponding case in the switch statement defined in main.c

Game Play State

If the user pushes the "Play 15 Puzzle" button from the menu screen, the program
proceeds to Case 1 in the switch statement in main.c. From here the "GameScreen"
function is called which writes the game screen to the LCD screen. The solved puzzle
is displayed for 1 second before it is scrambled by a scrambler function. The scram-
bler functions make use of the timer TIM3 and the location of the user's push on the
touch panel from the main menu to randomly scramble the screen.

Once the puzzle has been scrambled the user has three options: play the game, press
the "Solve" button to have the solver algorithm solve the puzzle, or press the "Menu"
button to return to the main menu screen. The program is constantly monitoring the
touch panel and locating any touches on the screen so that the correct action may be
performed. As soon as the user starts playing the game, a timer implemented by the
Real Time Clock is started to keep track of the time it takes the user to solve the puz-
zle. The time isn't displayed until the winning screen. Also the number of moves the
user makes are kept track of and displayed on the screen as the user plays.

8
 15 Puzzle

The solver function isn't perfect. It solves the puzzle some of the time, but there are
some bugs in the algorithm so it gets stuck sometimes.

High Score State

If the user pushes on the "High Score" button from the Menu Screen the program will
proceed to case 2 in the switch statement in main.c. In this case the "HighScore"
function is called and the fastest time the game was won in, and the least number of
moves the game was won in are displayed to the screen. These are displayed using
the ASCII table and functions from lab 6. Also displayed on this screen is a button to
bring the user back to the Menu Screen. If the user pushes anywhere other than the
menu button on this screen the push with have no effect.

Winning State
Once the user or the solver has completed the puzzle the following things always
happen in the winning state:
 The missing piece of the puzzle is added so the full picture is displayed
 A message saying "Congratulations!! YOU WON!!" is displayed on the
screen
 The time it took to complete the puzzle is output to the screen
 A winning sound is output through the speaker
 If the score is a high score it is saved to flash memory

In the winning state the "Solve" button changes to a "Shuffle" button so the user has
the option to push the "Shuffle" button to re-shuffle the puzzle and start again, or to
push the "Menu" button to return to the Menu Screen.

9
 15 Puzzle

4.2.1 Register Configuration

Register Configuration for the LCD Screen Display(TABLE 1)
Register Value What it does
RCC_APB2ENR 0x0000001D Bits 2 - 4 enable GPIO Ports A, B, and C. Bit 1 enables
AFIO
GPIOA_CRL OR with 0x00003000 Set port A pin 3 to be 0011 for Back light
GPIOB_CRL 0x33333333 Set port B pins 0 - 15 to be in output mode
GPIOB_CRH 0x33333333 Set port B pins 16 - 31 to be in output mode
GPIOC_CRL OR with 0x33000333 Set port C pins 0,1,2,6,and 7 to output mode for the LCD
RST, WR, RD, CS, and DC respectively.
AFIO_MAPR OR with 0x02000000 Set bit 24 to enable Single Wire and disable JTAG
The rest of the LCD initialization is the same as that which was given in LAB 4

Register Configuration for the Touch Panel(TABLE2)

Register Value What it does
RCC_APB2ENR 0x00001000 Set bit 12 to enable clock for SPI1
GPIOA_CRL OR with 0xAAA83300 1010 was written to pins 5 - 7 on port A to make them
Output Mode, max speed 2MHz with Alternate function
push-pull. 8 was written to pin 4 to make it an input with
pull up/pull down. 3s were written to pins 2 and 3 to
make them general purpose outputs with push-pull.
SPI1_CR1 0x0000034C Bit 9 was set to enable software slave management. With
this enabled the value of the SSI bit is forced onto the
NSS pin. Bit 8 is the SSI bit. It is set to 1 to force a 1
onto the NSS pin. Bit 6 was set to enable SPI1 on the
board. Bit 3 was set to control the baud rate and get it to
the correct value. Bit 2 was set to have the SPI1 be in
Master configuration.

Configuration of Timers and DAC(TABLE 3)

Register Value What it does
RCC_APB1ENR OR with 0x00000002 Set bit 1 to enable clock for TIM3
TIM3_CR1 OR with 0x00000001 Set bit 0 to enable TIM3
TIM3_ARR 0x000000FF Set TIM3 reload value to be FF
RCC_APB1ENR OR with 0x20000004 Set bit 2 to enable TIM4 and pin 29 to enable the DAC
TIM4_CR1 OR with 0x00000011 Set bit 4 to make a down counter, bit 0 to enable TIM4
TIM4_CR2 OR with 0x00000020 Set bit 5 to select update event as TRGO
TIM4_DIER 0x00000001 Set bit 0 to enable interrupt trigger upon count expire
TIM4_ARR 0x000007D0 Set auto reload value for TIM4 to be 2000 for 8000Hz with
16MHz clock
DAC_CR OR with 0x00290000 Set bits 21:19 to select Timer 4 TRGO to start conversion,
bit 18=0 disable trigger, bit 17=0 enable buffer, set bit 16
to enable DAC channel 2, bit 15:0 = 0x0 disable DAC
channel 1

10
 15 Puzzle

Configuration of the Real time clock (TABLE 4)

Register Value What it does
RCC_CR 0x10000 Enable the high speed 8MHz external oscillator
RCC_CR 0x20000 This bit must be polled to wait until the external oscillator is ready
before continuing in the configuration
RCC_CFGR 0x708C002 Select the PLL as the system clock. Set the external oscillator (HSE)
as the input to the PLL and set the PLL pre-scalar as HSE/2
RCC_CR 0x2000000 This bit must be polled to wait until the PLL is ready before
continuing in the configuration
RCC_CR 0x1000000 Enable the PLL after it has been configured
RCC_APB1ENR 0x18000000 Set the power enable (PWREN) and backup enable (BKPEN) bits
for the RTC to enable the power and backup interface clocks.
PWR_CR 0x100 Set the DBP bit to enable access to the configuration registers of the
RTC
RTC_CRL 0x20 This bit (RTOFF) is polled to wait until RT if ready to be configured
RTC_CRL 0x10 Set the CNF bit to enable configuration of the RTC registers (must
be done first)
RTC_CRL 0x4 Reset the RSF flag and then poll this bit until it is set to wait until
the RTC is synchronized
RTC_CNTL 0x0 Set the count value to zero
RTC_PRLL 0xFFFF Set the preload low register (PRLL) for 1 second at 16MHz
RCC_BDCR 0x8300 Enable the RTC and set it to use the HSE as its source clock
RTC_CRL 0xFFEF This value is anded with the current value of the register to reset the
CNF bit to disable further configuration of the RTC
RTC_CRL 0xFFFE This value is anded with the current value of the register to
acknowledge the interrupt in the IRQ Handler function for the RTC
The function NVIC_EnableIRQ(3) was used to enable the interrupt for the RTC

5. Testing
Multiple tests were run to verify each requirement. These consisted of hardware and program tests to
verify proper game play.

5.1 Test 1 -Hardware

This test is to verify that the hardware is functioning properly. The hardware is connected and powered
(see Appendix A). The LCD Module is to be connected through the LCD Port and the analog test board
is to be connected as shown in Appendix A. Power should be an external 5V DC power supply. These
connections were made and power was supplied through the USB cable from the computer to the
board. The game was played and all hardware was functional. The LCD displayed the pictures as
shown in Figures 1-5 and the speaker output sound as described in section 3.3. Thus requirements 1
and 6 are verified (see section 3.1 for requirements).

5.1 Test 2 –Menu

This test is to verify that the game contains a menu in which the user may make selections. The game
was powered on and the main menu screen was displayed which contained the selection to play the
game or view the high scores, thus requirement 2 is verified.

11
 15 Puzzle

5.1 Test 3 -Scramble

This test is to verify that the game scrambles the picture into different blocks. The game was powered
on and came to the main menu screen (see Figure 1). The “15 PUZZLE” menu item was chosen and the
game went to the game play screen and then scrambled the board (see Figure 2b). This verifies
requirement 3 (see section 3.1 for requirements).

5.1 Test 4 –User touches and game actions

This test is to verify that the game recognizes user touches on the touchscreen. The game was powered
on and came to the main menu screen (see Figure 1). When the screen was touched over a menu item
the game switched to the correct screen. In the game play screen when a block adjacent to the empty
square was pressed it was moved into the empty location, thus requirements 4 and 5 are verified (see
section 3.1 for requirements).

5.1 Test 5 –Save high scores

This test is to verify that the fastest time and the smallest number of moves are saved as the high scores
in nonvolatile memory. This was verified through game play. When a new high score was met it was
saved into memory. To ensure that it was nonvolatile the game was powered off and back on again. By
checking the high scores in the high score menu it was verified that they had indeed been saved. This
verifies requirement 7 (see section 3.1 for requirements).

5.1 Test 6 –Solve-it function

This test is to verify that the game contains a solve-it function that shows the step-by-step process of
solving the puzzle. The game was brought to the game play screen and the solve button was pushed
(see Figure 2b). The program then commenced to solve the puzzle displaying each move to the user
until the puzzle was solved. This verifies requirement 8 (see section 3.1 for requirements).

6. Conclusion
The design described in this document is a version of 15 Puzzle implemented on a STM32F103 ARM
Microcontroller board with LCD and analog test modules. Six tests were run to verify all eight re-
quirements (see section 3.1 for requirements, sections 5 for tests) and all tests passed. The design func-
tion as all requirements specify, however it is not optimal and other design alternatives are available
(see section 3.4). With more time, implementations using the SD card to provide more memory can be
made to allow multiple levels at the same time and provide memory space to store higher quality
graphics and sound. There are also some errors in the solve function as it doesn’t solve every case,
however, with more time and knowledge in algorithms and programming these can be fixed.

12
 15 Puzzle

Appendix A
Hardware Schematic

13
 15 Puzzle

Appendix B
Main.c

14
 15 Puzzle

lcd.c

15
15 Puzzle

16
15 Puzzle

17
15 Puzzle

18
15 Puzzle

19
 15 Puzzle

Lcd.h

20
 15 Puzzle

Touchscreen.c

21
15 Puzzle

22
15 Puzzle

23
15 Puzzle

24
15 Puzzle

25
15 Puzzle

26
15 Puzzle

27
15 Puzzle

28
15 Puzzle

29
15 Puzzle

30
15 Puzzle

31
15 Puzzle

32
15 Puzzle

33
15 Puzzle

34
15 Puzzle

35
15 Puzzle

36
15 Puzzle

37
 15 Puzzle

Touchscreen.h

38
 15 Puzzle

Tables.h

39
15 Puzzle

40