Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
CSSE2010 & CSSE7201
AVR Project
Semester One, 2024
Due: 4:00pm, Friday 24th May
Weighting: 20% (100 marks)
The University of Queensland
School of Electrical Engineering and Computer Science
Objective
As part of the assessment for this course, you are required to undertake an AVR project which will test you against some of the more practical learning objectives of the course, namely your C programming skills applied to the ATmega324A microcontroller.
You are required to modify a program to implement additional features. The program is a basic template of the game “Battleship” (described in detail on page 3). The AVR ATmega324A microcontroller runs the program and receives input from multiple sources and uses an LED matrix as a display for the game, with additional information being output to a serial terminal and – to be implemented as part of this AVR project – a seven-segment display and other devices.
The version of Battleship provided to you has very basic functionality – it will present a splash screen upon launch, respond to push button presses or a terminal input “s”/“S” to start the game, then display the boards for the game Battleship; one for the human player and one for the computer player. You can add features such as moving the cursor, game scoring, pausing, audio etc. The various features have different tiers of difficulty and will each contribute a certain number of marks. Note that marks are awarded based on demonstrated functionality only, regardless of how much effort or code has gone into attempting such functionality.
Don’t Panic!
You have been provided with approximately 1500 lines of code to start with – many of which are comments. Whilst this code may seem confusing, you do not need to understand all of it. The code provided does a lot of the hard work for you, e.g., interacting with the serial port and the LED matrix display. To start with, you should read the header (.h) files provided along with game.c and project.c.
You may need to look at the AVR C Library documentation to understand some of the functions used. Several intro/getting started videos are available on Blackboard, which contains a demonstration of some of the expected functionality to be implemented and walks through setting the project up with the provided base code, and how to submit. Note that the requirements in this document takes priority over anything shown in the feature demonstration videos.
Grading Note
As described in the course profile, if you do not score at least 10% on this AVR project (before any late penalty) then your course grade will be capped at a 3 (i.e., you will fail the course). If you do not obtain at least 50% on this AVR project (before any late penalty), then your course grade will be capped at a 5.
Your AVR project mark (after any late penalty) will count 20% towards your final course grade.
In addition, tiers may have more marks available in the features than the total marks allocated for that tier. You cannot earn more marks than the total allocation, however, you will be given all marks you are awarded for each feature up to this limit. This means that you can still get full marks for a tier, even if you are not awarded full marks for each feature, if you complete features with marks that would total above the allocated marks for that tier.
Your total marks for Tier B cannot exceed your total marks for Tier A. Your total marks for Tier C cannot exceed your total marks for Tier B.
Code Style
No marks are awarded nor deducted in the marking criteria for code style. However, poorly styled code will be detrimental to debugging and expanding the code, and so may lead to a loss of marks that way.
If your code is sufficiently poorly styled, then asking for assistance from course staff may be refused until your style is improved. This includes, but is not limited to, if your code:
-
• Utilises goto or digraphs/trigraphs;
-
• Fails to bitshift where doing so would be expected;
-
• Declares variables without meaningful names;
-
• Uses integer variables without exact width declarations (e.g. int instead of int8_t);
-
• Has inconsistent or contradictory indentation and/or brace positioning.
Academic Merit, Plagiarism, Collusion and Other Misconduct
You should read and understand the statement on academic merit, plagiarism, collusion and other misconduct contained within the course profile and the document referenced in that course profile.
You must not show your code to or share your code with any other student under any circumstances.
You must not post your code to public discussion forums or save your code in publicly accessible repositories. You must not look at or copy code from any other student. All submitted files will be subject to electronic plagiarism detection and misconduct proceedings will be instituted against students where plagiarism or collusion is suspected. The electronic plagiarism detection can detect similarities in code structure even if comments, variable names, formatting etc. are modified. If you copy code, you will be caught.
Program Description
The program you will be provided with has several C files which contain groups of related functions.
The files provided are described below. The corresponding .h files (except for project.c) list the functions that are intended to be accessible from other files. You may modify any of the provided files.
You must submit all files used to build your project, even if you have not modified some provided files. Many files make assumptions about which AVR ports are used to connect to various IO devices. You are encouraged not to change these.
• project.c – this is the main file that contains the game event loop and examples of how time based events are implemented. You should read and understand this file. A majority of the modifications and additions to the project code will be in this file and game.c.
• game.c/.h – this file contains the implementation of the game components and is used to store the state of the game. You should read this file and understand what representation is used for the game state and the board representations. A majority of the modifications and additions to the project code will be in this file and project.c.
• display.c/.h – this file contains the implementation for displaying the current state of the board. This file contains useful functions for displaying the board to the LED matrix.
• buttons.c/.h – this contains the code which deals with the push buttons. It sets up pin change interrupts on those pins and records rising edges (buttons being pushed).
• ledmatrix.c/.h – this contains functions which give easier access to the services provided by the LED matrix. It makes use of the SPI routines implemented in spi.c.
• pixel_colour.h – this file contains definitions of some useful colours for use with the LED matrix.
• serialio.c/.h – this file is responsible for handling serial input and output using interrupts. It also maps the C standard IO routines (e.g., printf() and fgetc()) to use the serial interface so you are able to use printf() etc. for debugging purposes if you wish. You should not need to look in this file, but you may be interested in how it works, and the buffer sizes used for input and output (and what happens when the buffers fill up).
• terminalio.c/.h – this encapsulates the sending of various escape sequences which enable some control over terminal appearance and text placement – you can call these functions (declared in terminalio.h) instead of remembering various escape sequences. Additional information about terminal IO will be provided on the course Blackboard site.
• spi.c./h – this file encapsulates all SPI communication. Note that by default, all SPI communication uses busy waiting (i.e., polling) – the “send” routine returns only when the data is sent. If you need the CPU cycles for other activities, you may wish to consider converting this to interrupt based IO, similar to the way that serial IO is handled.
• timer0.c/.h – sets up a timer that is used to generate an interrupt every millisecond and update a global time value that is used to time various game events (such as the curser flashing). This can be useful for implementing any features that require precise timing.
• timer1.c/.h & timer2.c/.h – largely empty files, that can be used for features that require timers/counters one and two.
NB: When you create a new project in Microchip Studio, a main.c file will automatically be created, containing an empty main() function. project.c also contains a main() function, but Microchip Studio will preferentially look the main() function in the main.c file, if it exists. Please ensure that you delete the main.c file so that Microchip Studio will look for the main() function in project.c.
Battleship Description
This AVR project involves creating a replica of the classic game “Battleship”. Battleship is a two-player game that coarsely simulates a naval battle. Each player has a grid board, on which they place narrow pieces representing ships. They then take turns in firing shots at each other into announced grid squares, after which their opponent tells them if they’ve hit one of their ships, or missed. In this implementation, there will be one human player and one computer player. The human player inputs their move on their turn with the IO board and/or terminal, while the computer player takes their turn automatically.
Each player has the following ships in their fleet, of the given length:
• Carrier (6);
• Cruiser (4);
• Destroyer (3);
• Frigate (3);
• Corvette (2); and
• Submarine (2).
A diagram of the LED matrix, as it appears when the game starts, is shown in Figure 1, and a diagram of the LED matrix as it may appear during the game is shown in Figure 2.
Human Board
Computer Board
Figure 1: LED Matrix Diagram for initial layout of Battleship
The left half of the LED matrix is the human board; it contains the human player’s ships, and the computer player will be firing shots at grid spaces on that board to try to hit those ships. The human player’s ships are visible to them, and shown in orange. The right half of the LED matrix is the computer board; it contains the computer player’s ships, and the human player will be firing shots at grid spaces on that board to try and hit those ships. The computer player has the same set of ships as the human player, but they are not visible to the human player, and are likely in different locations. The human player can select specific grid squares on the computer board by moving the flashing yellow cursor. The flashing is indicated with the half-yellow pixel in Figure 1 and Figure 2. Between the two boards is a gap in blue; this does not appear on the LED matrix, but is instead shown to separate the two boards, though the LED matrix does have a seam at this position.
Human Board
Computer Board
Figure 2: Potential LED Matrix Diagram for mid-game Battleship
As each player takes shots, the LED matrix fills in to show the result of the shot. If the shot hits a ship, that pixel is coloured red. If the shot misses, then that pixel is instead coloured green. This allows the human player to find the computer player’s ships.
When each pixel of a ship has been hit, that ship is sunk. When all of a player’s ships have been sunk, that player loses, and their opponent wins.
Initial Operation
The provided program has very limited functionality. It will display a splash screen which detects the rising edge on the push buttons B0, B1, B2 and B3, as well as the input terminal character “s”/“S”. Pressing any of these will start a game of Battleship.
Once started, the provided program detects a rising edge on the push button B0, but no action is taken on this input (this will need to be implemented as part of the Move Cursor Push Buttons feature).
You may find this summary useful when planning out your terminal layout. You may assume that the terminal will be at least as wide as the ASCII art title that displays on the splash screen in the provided code.
All information displayed on the terminal should be identifiable as to what it represents. For example, the game speed should have text to identify it, and not just be raw numbers, which could cause them to be confused with other information.
You must not spam the terminal with serial communication; you should only send a communication when information changes, and you should only update the relevant information, instead of clearing the entire screen and rewriting all the information. When the IO board is used for serial communication, the RX and TX lights will light up when data is being transferred. If the RX light is constantly lit, then you are constantly sending information, and you will not be awarded full marks. If the RX light turns on for a significant amount of time when you send data, then you may be sending more data that necessary, and if so, you will not be awarded full marks. Either of these issues can also cause the terminal screen to stutter.
Assessment of Feature Implementation
The program improvements will be worth the number of marks shown above. You will be awarded marks for each feature up to the maximum mark for that feature. Part marks will be awarded for a feature if only some part of the feature has been implemented or if there are bugs/problems with your implementation (which may include issues such as incorrect data direction registers). Your additions to the game must not negatively impact the playability or visual appearance of the game. Note also that the features you implement must appropriately work together, for example, if you implement game pausing then audio should pause.
Features are shown grouped in their tiers of approximate difficulty (Tier A, Tier B, and Tier C).
Submission Details
The due date for the AVR project is 4:00pm Friday 24h May. The AVR project must be submitted via
Blackboard. You must electronically submit a single .zip file containing only the following:
• All of the C source files (.c and .h) necessary to build the project (including any that were provided to you – even if you have not changed them);
• Your final .hex file (suitable for downloading to the ATmega324A AVR microcontroller program memory, see the getting started video to locate the .hex file); and
• A .pdf feature summary form (see below).
Please name your .hex and .pdf in the form proj_4nnnnnnn.hex/.pdf, where “4nnnnnnn” is your eight-digit student number.
Do not submit .rar or other archive formats – the single file you submit must be a .zip format file.
All files must be at the top level within the .zip file – do not use folders/directories or other .zip/.rar files inside the .zip file. If only the .hex file is submitted with no source files, then your submission will not be marked. The .hex file will be used if the marker is unable to compile/build the submitted source files.
If you make more than one submission, each submission must be complete – the single .zip file must contain the feature summary form, the .hex file and all source files needed to build your work. We will only mark your last submission and we will consider your submission time (for late penalty purposes) to be the time of submission of your last submission.
It is the responsibility of the student to ensure that their submission is correctly uploaded to the Blackboard submission portal with all of the files they intend to submit. This can be ensured by downloading your .zip file after submission is made, un-zipping the submission to check all files are correctly included and checking whether you are able to compile the project successfully. It is suggested that you use the Axon lab computers for this check.
The feature summary forms are on the last pages of this document. A separate electronically fillable .pdf form will be provided on Blackboard. Do not submit this entire document. This form can be used to specify which features you have implemented and how to connect the ATmega324A to other devices so that your work can be marked. If you have not specified that you have implemented a particular feature, we will not test for it. Failure to submit the feature summary with your files may mean some of your features are missed during marking (and we will not remark your submission). You can electronically complete this form, or you can print, complete and scan the form. Whichever method you choose, you must submit the .pdf file with your other files. If you have any assumptions or comments to convey to the marker, include these on the feature summary form.
Incomplete or Invalid Code
If your submission is missing files (e.g., will not compile and/or link due to missing files) then we will substitute the original files as provided to you. No penalty will apply for this, but no changes you made to the missing files will be considered in marking.
If your submission does not compile and/or link in Microchip Studio version 7 for other reasons, then the marker will make reasonable attempts to get your code to compile and link by fixing a small number of simple syntax errors and/or commenting out code which does not compile. A penalty of between 10% and 50% of your mark will apply depending on the number of corrections required. This will apply based off of compiling and linking with Microchip Studio on the Axon lab computers, regardless of the results of compiling or linking with other programs. If it is not possible for the marker to get your submission to compile and/or link by these methods, then you will receive 0 for the AVR project (and will have to resubmit if you wish to have a chance of passing the course). A minimum 10% penalty will apply, even if only one character needs to be fixed.
Compilation Warnings
If there are compilation warnings when building your code, then a mark deduction will apply – 1 mark penalty per warning up to a maximum of 10 marks. The warning list generated by Microchip Studio on
the Axon lab computers from a clean build will be the canonical list for these penalties. To check for warnings, rebuild all your source code (choose “Rebuild Solution” from the “Build” menu in Microchip Studio) and check for warnings in the “Error List” tab. If you are using other software for your project, you are encouraged to perform a final build on Microchip Studio on the lab computers.
General Deductions
If there are problems in your submitted AVR project that do not fit into any of the above feature categories, then some marks may be deducted for these problems. This could include problems such as general lag, errors introduced to the original program etc. The number of marks deducted will depend on the severity of the issues.
Late Submissions
As per the course profile, where an assessment item is submitted after the deadline (i.e., 4:00pm Friday 24th May), without an approved extension, a late penalty will apply. Assessment submissions received after the due time (or any approved extended deadline) will be subject to a 10% late penalty per day (or part thereof), up to a maximum of seven days. After seven days, a 100% late penalty will be applied.
Requests for extensions should be made via the process described in the course profile (before the due date) and be accompanied by documentary evidence of extenuating circumstances (e.g., medical certificate). The application of any late penalty will be based on your latest submission time.
Notification of Results
Students will be notified of their results via the My Grades section of Blackboard.
CSSE7201
The AVR programming described in this document constitutes part two of the CSSE7201 assessment, which contains the 10% pass hurdle for the course. Please see Blackboard for part one, and/or the course profile for more information regarding the assessment details.
Version
This is version thirteen of the project document. Changes between the current version and the previous version are shown in green. Changes between the previous version and version one are shown in blue.
Feature Summary
The University of Queensland – School of Electrical Engineering and Computer Science Semester One, 2024 – CSSE2010/CSSE7201 Project – Feature Summary
An electronic version of this form will be provided. You must complete the form and include it (as a .pdf) in your submission. You must specify which IO devices you have used and how they are connected to your ATmega324A. Failure to include this form with your submission will result in no marks being awarded for the project. Failure to specify connections and/or attempted features will result in no marks being awarded for the relevant features.
Student Number
Family Name
Given Names
4
Port
Pin 7
Pin 6
Pin 5
Pin 4
Pin 3
Pin 2
Pin 1
Pin 0
A
B
SPI connection to LED matrix
Button B3
Button B2
Button B1
Button B0
C
D
Serial RX
Serial TX
Baud rate: 19200
Feature
if
attempted
Comment
(Anything you want the marker to consider or know?)
Mark
Splash Screen
/4
Move Cursor with Push
Buttons
/6
Move Cursor with
Terminal Input
/6
Human Turn
/8
Computer Turn
/6
Invalid Move
/4
Sinking Ships
/4
Game Over
/6
Ship Setup – Human
/8
Cheating
/4
Seven-Segment Timer
/6
/50
Game Pause
/6
Computer Turn – Search
& Destroy
/8
Ship Setup – Computer
/6
Cheatin’ 2 – Electric
Boogaloo
/4
Salvo Mode
/6
Sound Effects
/6
/30
Firing Animation
/6
Joystick
/6
Computer Turn – Smart
Targeting
/6
High Score
/8
/20
Total: (out of 100)
General deductions: (errors in the program that do not fall into any above category, e.g., general lag in gameplay)
Penalties: (code compilation, incorrect submission files, etc. does not include late penalty)
Final Mark: (excluding any late penalty which will be calculated separately)