Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CSSE2010/CSSE7201 AVR Project
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.
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.
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.
CSSE2010/CSSE7201 AVR Project, Semester One, 2024 2
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.
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.
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.
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.
CSSE2010/CSSE7201 AVR Project, Semester One, 2024 3
• 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.
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.