CSSE2010 / CSSE7201 Assignment 2

2025-05-19 Admin 写评论

Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

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 outputto 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 LEDdisplay. 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.

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 donot 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. Resubmissions prior to grade finalisation are possible to meet the 10% requirement in order to pass the course, but a late penalty will be applied to the mark for final grade calculation purposes.

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 callthese 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.

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

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).

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

 tart_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 sameas 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 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  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.

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.

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 200 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 200ms. The LEDs should then revert (L0, L3 off; L1, L2 on) and the elevator should again wait 200ms 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 600ms

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.

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, 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.

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 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 obviouslyno 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 themarker 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.

发表评论

电子邮件地址不会被公开。 必填项已用*标注