CSSE2010讲解 、辅导 C/C++，Python编程
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 1
The University of Queensland
School of Electrical Engineering and Computer Science
Semester 1, 2025
CSSE2010 / CSSE7201 Assignment 2
Due: 4:00pm Friday May 30th, 2025
Weighting: 20% (100 marks)
Objective
As part of the assessment for this course, you are required to undertake an assignment which will
test you against some of the more practical learning objectives of the course. The assignment will
enable you to demonstrate your understanding of
? C programming
? C programming for the AVR
You are required to modify a program in order to implement additional features. The program is
a basic template of an Elevator Emulator (a description is given on page 3).
The AVR ATmega324A microcontroller runs the program and receives input from a number of
sources and outputs a display to an LED display board, with additional information being output
to a serial terminal and – to be implemented as part of this assignment – a seven segment display
and other LEDs.
The version of the Elevator Emulator supplied to you has basic functionality only – it will present
a start screen upon launch, respond to button presses or a terminal input ‘s’ to start, then display
the emulator. A list of features and their implementation details are provided in “Program
Features”. The different features have different levels of difficulty and will be worth different
numbers of marks.
Don’t Panic!
You have been provided with approximately 2000 lines of code to start with – many of which are
comments. Whilst this code may seem confusing, you don’t 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
display. To start with, you should read the header (.h) files provided along with Elevator- Emulator.c. You may need to look at the AVR C Library documentation to understand some
of the functions used.
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.
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 2
Grading Note
As described in the course profile, if you do not score at least 10% on this assignment (before
any 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 assignment (before any penalty), then your course grade will be
capped at a 5. Your Assignment 2 mark (after any penalty) will count 20% towards your final
course grade.
Program Description
The program you have been provided with has several C files which contain groups of related
functions. The files provided are described below. The corresponding .h files (except for Elevator- Emulator.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 assignment, 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.
? Elevator-Emulator.c – this is the main file that contains the event loop and examples of
how time-based events are implemented. Here also, you will find the implementation of
the elevator and the floors, as well as code that handles the movement of the elevator. You
should read and understand this file.
? display.h/display.c – this file contains the implementation for displaying the current state
of the board. This file contains useful functions for changing the state of the LED matrix.
? buttons.h/buttons.c – this contains the code which deals with the IO board push buttons.
It sets up pin change interrupts on those pins and records rising edges (buttons being
pushed).
? ledmatrix.h/ledmatrix.c
– 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.
? serialio.h/serialio.c – 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 must include serialio.h in the relevant file for the functions to work. You should
not need to look in serialio.c, 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).
? spi.h/spi.c – this file encapsulates all SPI communication that is used to communicate with
the LED Matrix.
? terminalio.h/terminalio.c – 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.
? timer0.h/timer0.c – sets up a timer that is used to generate an interrupt every millisecond
and update a global time value.
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 3
Elevator Emulator Description
This assignment involves creating an elevator emulator. The LED Matrix shows four floors in
green (referred to as floors 0 through 3) and a 2x3 red LED grid which represents the elevator, on
the left-hand side. Note that the X and Y coordinate system used (seen in Figure 1) does not
correspond with the X and Y coordinates labelled on the LED Matrix PCB.
Figure 1: Initial layout of elevator emulator (note that pixel positions are referenced from the bottom left)
Travellers appear on each floor and the elevator moves to their floor, picks them up and takes
them to their destination floor. The elevator moves up and down and, for the sake of algorithmic
simplicity, is only capable of moving one traveller at a time. Each traveller can be one of four
colours, with each different colour corresponding to a different destination floor.
In the following example (Figure 2) a light red passenger appears on floor 1. Light red indicates
the traveller’s destination is floor 0. The elevator moves to their floor, picks them up and then
moves down to the destination. Note that there is a fixed amount of time (defined in code) between
each of the frames shown.
Figure 2: Example, moving a traveller from floor 1 to floor 0
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 4
Initial Operation
The provided program has limited functionality. It will display a start screen which detects the
rising edge on the buttons connected to pins B0, B1, B2, B3 and the input terminal character ‘s’.
Pressing of any of these will start the elevator emulator.
Wiring Advice
When completing this assignment, you will need to make additional connections to the
ATmega324A. To do this, you will need to choose which pins to make these connections to. There
are multiple ways to do this, so the exact wiring configuration will be left up to you, and you
should communicate this using your submitted feature summary form (last page).
Program Features
Marks will be awarded for features as described below. Part marks will be awarded if part of the
specified functionality is met. Marks are awarded only on demonstrated functionality in the
final submission – no marks are awarded for attempting to implement the functionality, no
matter how much effort has gone into it, unless the feature can be demonstrated. You may
implement higher-level features without implementing all lower-level features if you like (subject
to prerequisite requirements). The number of marks is not an indication of difficulty. It is much
easier to earn the first 50% of marks than the second 50%.
You may modify any of the code provided and use any of the code provided by course material,
e.g. Blackboard, Ed Lessons, Learning Labs, etc. For some of the easier features, the description
below tells you which code to modify or there may be comments in the code which help you.
Getting Started
Your program must have at least the features present in the code supplied to you, i.e., it must build
and run on Microchip Studio, show the start screen, and display the initial screen when a button
or ‘s’ is pressed. The initial screen shows the four floors in green and the elevator on the bottom
floor, shown in red. No marks can be earned for other features unless this requirement is met, i.e.,
your assignment mark will be zero.
Start Screen (Level 1 – 4 marks)
Modify the program so that when it starts (i.e. the AVR microcontroller is reset) it outputs your
name and student number to the serial terminal. Do this by modifying the function
start_screen() in file Elevator-Emulator.c.
Hint:
Printing to the putty terminal is handled with either
printf(“”); or printf_P(PSTR(“”));, look for
these lines on the code to change what is being sent to the
terminal. (Note, the difference between these two commands
is where the string is stored in memory. Normally strings are
stored in SRAM, PSTR() stores the string in program
memory which is important for systems (like the Atmega)
which have a limited amount of SRAM).
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 5
Set Destination with Buttons (Level 1 – 8 marks)
The provided program does not allow for the elevator to be moved to all floors. Currently, only
B0 and B1 will set the destination of the elevator to floors 0 and 1, respectively. Modify the
program so that B2 and B3 moves the elevator to floors 2 and 3 respectively (in the code, these
are represented by FLOOR_2 and FLOOR_3).
Hint:
When B0 and B1 are pressed an internal variable, called
destination is changed. The loop in the
start_elevator_controller() function then
handles moving the elevator at a constant rate to the desired
location.
The code for setting the destination of the elevator is in
handle_inputs(). Have a look at the comments there
to get you started.
Set Destination with Terminal Input (Level 1 – 8 marks)
The provided program does not register any terminal inputs once the emulator has started. Modify
the code such that it is possible to set the destination of the elevator using the ‘0’, ‘1’, ‘2’, and ‘3’
keys on your keyboard. I.e. these keys should have identical functionality to B0 à B3.
Hint:
On the start screen, the emulator can be started by pressing
‘s’ or ‘S’, looking at the function start_screen()
should give you an idea of how to read serial input from the
terminal.
Also be careful when writing your code. ‘1’ is not the same
as the integer 1, in this case it is a character.
Terminal Display #1 (Level 1 – 6 marks)
On the terminal display (PuTTy), clearly show the following information to the user: Current floor
(i.e. last floor reached, do not indicate that the elevator is between floors) and the direction of
travel. The direction of travel should be one of: “Up”, “Down”, or “Stationary”.
Traveller Placements (Level 1 – 8 marks)
(Assumes that “Set Destination with Buttons” is implemented.) Modify the program so that a
‘traveller’ is placed at the location corresponding with a button press. I.e. if B0 is pressed the
traveller is placed on Floor 0, if B1 is pressed then Floor 1, and so on. ‘Placing’ a traveller here
means turning on an LED on the LED Matrix that is immediately above the green floor pixels,
with a gap of one LED between the elevator and the traveller. The diagram below shows a traveller
placed on floor 2. Your code so far should already handle going to a floor when a button is pressed
(i.e. where there will now be a traveller). Only one traveller can be active at a time, if a traveller
is present (or being moved in the elevator), your code should ignore other button presses until the
existing traveller has been moved (note, this will change when “Traveller Queue” is implemented
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 6
later). At this stage you should make the colour of the traveller COLOUR_LIGHT_RED (defined
in pixel_colour.h). More colours for travellers will be introduced in Moving Travellers #2.
Figure 3: Example of traveller on FLOOR_2
Moving Travellers #1 (Level 1 – 8 marks)
Move travellers from their floor to the ground floor (FLOOR_0). Modifying the destination to
other floors is handled in “Moving Travellers #2”. When a traveller has been placed, the elevator
moves to their floor. Modify your code so that once the elevator has reached the travellers floor
the traveller disappears (i.e. they have gone onto the elevator) and then the elevator moves down
to the ground floor (so that the traveller can exit the elevator, although you do not need to indicate
that the traveller has gotten off the elevator). Once this has occurred, the elevator should be ready
to pick up another traveller.
Currently, you do not need to worry about the behaviour of the elevator when placing a traveller
on the ground floor. See “Moving Travellers #2” for further details.
It is worth noting here that this functionality is different to a ‘real-life’ elevator. For the sake of
simplicity of this assignment, the elevator emulator here is not capable of carrying multiple
passengers. Only one traveller is moved at a time.
Speed Control (Level 1 – 6 marks)
The speed of the elevator should be controllable with switch S2. If S2 is 0, a slow speed is enabled.
If S2 is 1, the speed of the elevator is increased. It is up to you to choose suitable fast and slow
speeds. Both speeds should be reasonable, but distinguishable. Approximately 100-300 ms
between each time the elevator moves one LEDs distance would be considered reasonable. The
provided functionality has a delay of 200 ms each time the elevator moves one LEDs length.
SSD Direction Indicator (Level 1 – 6 marks)
Modify your code to display the direction of travel of the elevator on the left SSD digit. SSDs
have segments labelled A à G (see the diagram below). When the elevator is moving up, the A
segment should be illuminated. Moving down should be indicated by the D segment, and not
moving should be indicated by the G segment. No other segments should be illuminated. Only
one segment should be illuminated at any one time. At this stage the right SSD is not used, and
should remain blank. If you choose not to implement “SSD Current Floor”, you may make a note
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 7
on your feature summary (underneath the wiring table) about how you have connected your CC
pin.
Figure 4: SSD Diagram (https://theorycircuit.com/arduino-projects/7-segment-arduino-interface/)
Move Travellers #2 (Level 2 – 8 marks)
(Assumes that “Move Travellers #1” is implemented.) Use the first two switches (S0 and S1)
to choose a floor destination (with S0 being the LSB). The value from these two switches
corresponds with each of the four floors. The colour of the LED indicating the presence of the
traveller should correspond with that traveller’s destination.
Use the following colours to indicate where a traveller is going: (colour definitions in
pixel_colour.h)
? Travelling to FLOOR_0 à COLOUR_LIGHT_RED
? Travelling to FLOOR_1 à COLOUR_LIGHT_GREEN
? Travelling to FLOOR_2 à COLOUR_LIGHT_YELLOW
? Travelling to FLOOR_3 à COLOUR_LIGHT_ORANGE
The elevator will go to the floor of the traveller and pick them up. Modify your code such that the
elevator then goes to the correct destination floor associated with their colour. I.e. we are no longer
taking all the travellers to the ground floor. Note that when the elevator is finished moving the
traveller, it stays where it is until another traveller is ready to be moved.
At this stage, you must also add logic to your code that stops the user from placing a traveller on
a floor which is also their destination floor. For example, if a traveller is placed on floor 3 and
their destination is also floor 3 (their colour would be light yellow), your code should detect this
and ignore that traveller (they should not be shown on the screen, and when “Queue Travellers”
is implemented, they should not be added to the queue).
SSD Current Floor (Level 2 – 8 marks)
Modify your code such that the right SSD shows the current floor. Like the terminal display, it
should just show the last floor that was reached. However, if the elevator is not currently at a floor
(i.e. it is between floors), the ‘DP’ bit of the SSD should also be set. There must be no flickering
or ghosting present on the SSDs. Each SSD must be clear with no dimming of any of the segments.
Hint:
SSD multiplexing using the CC pin was covered in the Labs.
You are encouraged to revisit the content from these labs to
help you for this feature.
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 8
Terminal Display #2 (Level 2 – 4 marks)
On the terminal display, show the number of floors the elevator has moved with a traveller and
without. This should be indicated with two counters, one for number of floors travelled with a
traveller on board, and number of floors travelled without. I.e. you must handle counting the
number of floor boundary’s crossed, not the number of destinations travelled too. Similarly to
“Terminal Display #1” you must not print constantly to the terminal display. Only print to the
terminal when relevant changes are made.
Sound Effects (Level 2 – 8 marks)
Add the following sound effects to the program which are to be output using the piezo buzzer:
? A 3 kHz tone that plays for 50 ms every time a traveller is placed on a floor.
? A 500 Hz tone that plays for 100 ms every time a traveller is picked up or dropped off by
the elevator.
Note, it is not expected that the tones be the exact frequency or duration defined here. A small
amount of error in the frequency or duration is acceptable. We do not expect you to measure the
output of your piezo to ensure it is the exact correct frequency or duration. If you want to verify
the frequency of your buzzer, use this link (https://www.szynalski.com/tone-generator/) to hear
what a square wave of that frequency sounds like.
It is possible that two sounds overlap (e.g. a traveller is picked up <50ms after it is placed by a
button). How you handle this is up to you and will not be tested during marking. You may choose
to override the tone that is currently playing or not play a tone at all if one is already playing.
Hint:
It will be difficult to implement these sounds without the use
of a timer. It is recommended that to produce the desired
frequencies, you refer to the Labs where PWM was covered.
IOBoard LED Door Animation (Level 3 – 6 marks)
Using the IOBoard LEDs L0 à L3, create an animation each time the elevator reaches the floor
of a traveller and when a traveller’s destination is reached. Initially L0 and L3 should be off and
L1 and L2 should be on; this should show for 400 ms after the elevator has reached the traveller’s
floor. After this, L0 and L3 will turn on and L1 and L2 will turn off (to indicate the doors of the
elevator opening). This should also be shown for 400ms. The LEDs should then revert (L0, L3
off; L1, L2 on) and the elevator should again wait 400ms before continuing to the destination
floor. Figure 5 shows the animation. Note that the animation should not interfere with the rest of
the running code - for example, the SSD must continue to work and once Traveller Queue has
been implemented it must be possible to continue to add travellers while the animation is playing.
Figure 5: LED animation, lasting a total of 1200ms
The waiting traveller goes onto the elevator (i.e. disappears) sometime during the middle 400ms
of the LED animation (i.e. when the doors of the elevator are ‘open’). The traveller is allowed to
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 9
get on the elevator the same moment the animated doors open or close, it does not need to be in
the middle of the 400 ms when the doors are open. If a traveller is dropped off at the floor where
the next traveller is waiting (assuming “Travel Queue” is implemented), the above animation
should only play once. You must make sure that both dropping off the current traveller and picking
up the next traveller (assuming they are on that same floor) only triggers one cycle of the
animation.
Traveller Queue (Level 3 – 6 marks)
For this feature, your program should support many travellers queuing for the elevator. The
program should allow for button presses to be registered and handled even when there is already
one or more travellers waiting on the elevator. If a traveller is already present on a floor, and
another traveller is added, the new traveller should appear on the right side of the existing traveller.
If more travellers are present on a floor than can be shown on the LED matrix, they should queue
off the screen (i.e. not be visible until the queue has shortened). The elevator should, in the order
that travellers were added, move to the position of each traveller and move them to their
destination floor. It must be possible to have a queue of up to at least 10 travellers waiting for
the elevator. The code should internally store the order in which travellers were added and follow
that order when picking up and dropping off passengers.
It is worth noting once again that this elevator does not work the same way as a ‘real-life’ elevator.
This elevator is not meant to be the most efficient, even though sometimes it would make more
sense to not move travellers in the order in which they appear. For the sake of algorithmic
simplicity, in this emulator however, the elevator will move one traveller at a time, in the order
that they appear.
Table 1, in conjunction with Figure 6, shows an example of several buttons being pressed, and the
relevant LEDs that appear on the matrix.
Table 1: Example of a queue (order of button presses from left to right)
B0 Pressed B1 Pressed B0 Pressed B3 Pressed B1 Pressed B2 Pressed
S0: 1 S1: 1 S0: 1 S1: 1 S0: 0 S1: 1 S0: 0 S1: 1 S0: 1 S1: 0 S0: 0 S1: 0
Traveller added
From: FLOOR_0
To: FLOOR_3
Traveller added
From: FLOOR_1
To: FLOOR_3
Traveller added
From: FLOOR_0
To: FLOOR_1
Traveller added
From: FLOOR_3
To: FLOOR_1
Traveller added
From: FLOOR_1
To: FLOOR_2
Traveller added
From: FLOOR_2
To: FLOOR_0
Figure 6: Example image of several travellers queued, as per Table 1. Numbers on the LEDs are illustrative only and indicate the
order that the LEDs turned on.
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 10
Joystick – Service Mode (Level 3 – 6 marks)
(Assumes that “Speed Control” is implemented.) Add support to use the joystick to move the
elevator up and down. When S3 is switched on, the elevator should no longer move automatically
to pick up and drop off passengers but should instead be controlled by the joystick. When the
joystick is pushed up slightly, the elevator should move up at the slow speed (as was implemented
in “Speed Control”). When the joystick is pushed fully upwards, the elevator should move up at
the quick speed (as was implemented in “Speed Control”). Note that the other axis of the Joystick
will remain unused.
The elevator should not move above the top position or below the bottom position even when the
joystick is pushing it beyond its limits.
Be aware that different joysticks may have different min/max/resting output voltages and you
should allow for this in your implementation – your code will be marked with a different joystick
to the one you test with. You should also consider that the centre of each joystick is not consistent
between joysticks. Consider implementing a “dead space” so that the elevator does not move when
the joystick is not being pressed.
Assessment of Program Improvements
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 emulator must not negatively impact the usability or visual appearance of the
emulator. Note also that the features you implement must appropriately work together, for
example, if you implement LED Animation then Sound Effects should continue to work.
Features are shown grouped in their levels of approximate difficulty (level 1, level 2, and level 3).
Submission Details
The due date for the assignment is 4:00pm Friday 30 May 2025. The assignment 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 assignment (including any that
were provided to you – even if you haven’t changed them); and
? A PDF feature summary form (see below).
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 you make more than one submission, each submission must be complete – the single zip file
must contain the feature summary form, 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.
The feature summary forms are on the last pages of this document. A separate electronically- fillable PDF form will be provided to you also. This form can be used to specify which features
you have implemented and how to connect the ATmega324A to peripherals so that your work can
be marked. If you have not specified that you have implemented a particular feature, we will not
CSSE2010 / CSSE7201 Assignment 2, Semester 1, 2025 11
test for it. Furthermore, not including your relevant pin connections for a particular
peripheral will incur a deduction of 2 marks per peripheral not specified.
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 a PDF file with your other files.
Incomplete or Invalid Code
If your submission is missing files (i.e. won’t 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 obviously
no changes you made to missing files will be considered in marking.
If your submission does not compile and/or link in Microchip Studio 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. 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 assignment (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 (in Microchip Studio, with default
compiler warning options) then a mark deduction will apply – 1 mark penalty per warning up
to a maximum of 10 marks. To check for warnings, rebuild ALL of your source code (choose
“Rebuild Solution” from the “Build” menu in Microchip Studio) and check for warnings in the
“Error List” tab.
Your code must compile and run using the default Microchip Studio and PuTTY setup on the lab
computers. It is your responsibility to ensure that your code works as such. Programs such as
PlatformIO and other serial terminal tools may behave differently to the software required in this
course. Similarly, your serial connection must work through the IO Board, and not through the
Pololu programmer, or other serial to USB devices.
General Deductions
If there are problems in your submitted assignment 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.
Late Submissions
Late submission will result in a penalty of 10% per calendar day or part thereof, i.e. a
submission less than one day late (i.e. submitted by 4:00pm Saturday 31 May, 2025) will be
penalised 10%, less than two days late 20% and so on. (The penalty is a percentage of the
maximum possible mark you can earn, not the mark that you earn) 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.