CAB202 AMS
• Home
Hello, QUTAD\n10447288 !
CAB202 Assignment, Exercise 1: Microcontroller Assignment (Device 1)
Return to Exercise List »
Results so far:
No submission has been made so far. (0%).
Assessed weight: 0%. You may continue to attempt this item until you reach 100 submissions. So far, you have made 0 submissions.
Requirements:
CAB202 Microcontroller Assignment
Due Date:
31 May 2020 23:59:59
Assessment Weight:
40%
FAQ
• Q: Am I allowed use library X (where X is the name of any Arduino library)?
A: The standard C libraries (http://cplusplus.com/reference/, under the heading “C Library”) are permitted. In addition, headers of the form
• Q: How original does my application have to be?
A: Your idea doesn’t have to be very original; for example, porting a real-life game (such as Mah Jong, Old Maid, Snap, Piggy In The Middle) or homage to existing video game genres is reasonable. But your implementation must be completely original.
Practical applications such as home automation devices are fine in principle, but may have difficulty incorporating multiple learning outcomes in a coherent and cohesive manner. Certain applications may require substitution of other similar devices in the TinkerCad implementation. If that is the case, the substitution must be an incontestably direct replacement for the substituted object, such that the analogy between real device and substituted TinkerCad component is clear and not contrived.
Specification
• You are required to invent, design, implement, document, and demonstrate the prototype of a microcontroller-based product – hereafter referred to as the application – which showcases your mastery of learning outcomes in CAB202.
• The application must perform some meaningful service, carry out a specific useful function, or in general be a cohesive and sensible construct which will deliver valuable functionality.
• The application is NOT a compendium of unrelated software and hardware snippets aggregated into a single package in a coincidental manner.
• The specific task, purpose, or valuable functionality inherent in your application is left to you to choose. Thus, this task is an opportunity for you to indulge your interests and ideally create a prototype product which will have enduring value for you, either in the course of your professional development, or as a chance to implement something of practical utility for yourself or others.
• A very broad range of application areas will be accepted, including but not limited to such things as prototype hand-held games, home automation helpers, assistive technologies for people with disabilities, musical instruments, or scientific instruments.
• Note well: if you decide to implement a hand-held game, you must implement a playable and original game which exercises every element of claimed functionality.
Constraints
Your application prototype must conform to the following constraints:
• The application must demonstrate proficiency with up to 8 distinct instances of the following specific functional capabilities, each of which is directly related to CAB202 learning outcomes.
• Digital I/O – switch
• Digital I/O – interrupt-based debouncing
• Digital I/O – LED
• Analog Input
• Analog Output (PWM) – hardware-based; OR software-based “bit-banging”
• Serial I/O – hardware based; polling OR interrupt mediated
• LCD – simple text display; OR: bit-mapped graphics, including sprites, line or pixel art
• Timers – other than debouncing or PWM
• Other advanced hardware interaction. Options include:
• LED matrix display built from first principles;
• music synthesis tool;
• signal processing tool;
• distributed computing application
• Serial I/O – SPI or I2C, hardware-based; OR via bespoke code –“bit banging”
• Subject to prior approval in writing from Unit Coordinator or delegate
Subject to prior approval in writing from Unit Coordinator or delegate
• In this context, “distinct instance” mean that each category will be scored once. Thus, using 8 buttons counts as a single instance of learning outcome (a) in the list above. Debouncing 4 switches counts as a single instance of learning outcome (b). No learning outcome will be allocated credit more than once during marking.
• The application must be implemented via a private TinkerCad Circuit emulation. Include a shared link to this as part of your submission.
• The application must be runnable – that is, all functionality claimed for the application must be able to be exercised via software included in the TinkerCad Circuit, and which executes correctly when the “Start Simulation” action is invoked.
• The software required to run your application must be fully self-contained, and consist entirely of original software crafted by you.
• Third party libraries or source code obtained from any source other than the CAB202 teaching materials are strictly prohibited.
• You may use all functions in the standard C library, including any file which may be included via a C pre-processor directive
#include
• Generic techniques or algorithms sourced from external sites and adapted to your setting is permitted, however the implementation of such algorithms must be demonstrably your own work. Due citation is required for any such algorithms.
• All software must be written using the C programming language.
• Attach all source files below and use the Submit button to verify that your software conforms to this requirement.
Submission Requirements
You must submit the following items:
• Complete source code for the software required to run your application must be submitted using the form below.
• The program MUST compile successfully in AMS, or a score of 0 will be recorded for this assessment item.
• A shared link to your private TinkerCad Circuit where the prototype application is implemented.
• This should be included in your report.
• A recorded audio-visual screen-cast (maximum of 5 minutes duration) which demonstrates all functionality for which you are claiming credit.
• The submitted video must be viewable, audible, and submitted according to the prescribed submission mechanism, or a score of 0 will be recorded for this assessment item.
• The video must be well-scripted and presented in a professional manner using audio as well as visual channels to convey information. Some examples of acceptable and unacceptable scripting follow:
• Good: “Now as I turn Player 1 Potentiometer clockwise, observe as the paddle icon moves upward on the LCD.” – synchronised properly with corresponding visual cues and clearly visible results.
• Good: “Watch the status LEDs on the breadboard as I click the Increment button four times. You expect to see the LEDs light up in order from left to right with each button release. One, two, three, four. See, the fourth LED is no lit up.” – with appropriate pauses and if necessary with careful mouse gestures to direct the viewer’s gaze.
• Not good: “OK, let’s move the paddles. Yup that works.”
• Not good: Led Zeppelin’s “Immigrant Song” played at volume 11 over the top of the voice-over. Or any other musical backing, unless your application is a synthesizer of some kind.
• Not good: Any distractions, either visual or auditory. This includes the neighbour’s lawn mower.
• Not good: “Here we go…”. – followed by a lengthy period of silence punctuated by strained grunts and exhalations –” see, that works perfectly!”
• Not good: Dialog of high quality, but accompanied by flailing mouse movements or other visual effects which hurt the marker’s eyes.
• A written report containing the following sections:
• A succinct but comprehensive introduction which fully describes the use case targeted by your application, justifying the value of the application, and setting out clearly how each claimed learning outcome is showcased by your application, and describes how each component contributes to the overall functionality of the application.
• A detailed set of wiring instructions which clearly and without ambiguity defines every component and hardware connection in your application. Some examples of acceptable and unacceptable wiring instructions follow:
• Good: ”Connect LED 2: place LED 2 on the breadboard to the right of LED 1; connect pin 13 to the cathode of LED 2; connect the anode of LED 2 to one end of a distinct 220 Ohm resistor; connect the other end of the resistor to ground”.
• Not good: ”Plug a LED into pin 13”.
• Not good: ”Connect Door Open Switch: see attached diagram”.
• A fully labelled schematic diagram which shows the named components and their connections. All components are thoughtfully laid out and the overall presentation of the diagram ensures that it will be easy for users to create the application.
• A link to the TinkerCad Circuit by itself does not meet this requirement
Details of the submission mechanism for report and video will be supplied by the end of Week 10.
Assessment Criteria
The application cannot be assessed accurately unless all four items listed at paragraphs 8, 9, 10, and 11 above are submitted. bmitted. If any of these items is absent, a score of 0 will immediately be awarded for the whole assignment.
The marking criteria applied are as follows:
• General reporting of results – 8 marks, comprising:
• Video presentation (4 marks)
Fractional score
Indicative quality characteristics
0%
Supplied video is unable to be viewed or contains inaudible sound-track.
25%
Supplied video is grossly substandard; Little effort has been made to script and present the capabilities of the application; Video deviates wildly from time requirements; Video should have been re-recorded to enable clear understanding of the application.
50%
Supplied video is of marginally acceptable standard; Approximately half of claimed functionality is clearly and carefully scripted; Video does not adhere to time requirements; Video scripting and editing is tolerable, but a number of segments should have been re-recorded to enable clear understanding of the application.
75%
Supplied video is generally well scripted, presenting most aspects of claimed functionality in a careful and clear manner, and meets timing requirement. There may be minor lapses in quality, clarity, or other small problems with video preparation.
100%
Supplied video is excellently scripted, presenting all aspects of claimed functionality in a careful and clear manner, and meets timing requirement.
• Report Introduction (2 marks)
Fractional score
Indicative quality characteristics
0%
Report does not have a readily discernible introduction.
25%
Introduction is grossly substandard. Little effort has been made to articulate the use case, value proposition, or alignment with learning outcomes; Introduction is poorly organised, with little attention paid to general principles of academic and professional communication.
50%
Introduction is marginally acceptable. Some attempt has been made to set out the use case and value proposition behind the application; Introduction is adequately structured, with attention paid to the basic principles of academic and professional communication; Introduction fails to indicate how a number of learning outcomes are demonstrated by the supplied application.
75%
Introduction is generally well written. The relationship to learning outcomes or the target use case of a small number of components in the system may not be clear; There may be minor lapses in quality, clarity, or other small problems with expression or organisation of ideas in the introduction.
100%
Introduction provides succinct but comprehensive coverage of the use case targeted by the application, its value proposition, and how each claimed learning outcome is showcased. Introduction accurately and clearly describes how each component contributes to the overall functionality of the application.
• Schematic Diagram (2 marks)
Fractional score
Indicative quality characteristics
0%
Report does not include wiring instructions.
25%
Schematic diagram is largely incomplete, or otherwise of very low quality. Many components in the physical design are unlabelled, have confusing labels, or do not appear to follow a logical labelling pattern; Components are visually disorganised or badly laid out; Connections between components are hard to decipher, or appear to be electronically invalid. The schematic diagram would not yield a working circuit.
50%
Schematic diagram is marginally adequate. All components appear in the schematic diagram, but some have misleading or confusing names and locations; Some of the connections between components are clear and unambiguous, but some are confusing or appear to be electrically invalid; Some components are thoughtfully laid out, but the overall presentation of the diagram means it might be hard to assemble the circuit by following the diagram.
75%
All components appear in the schematic diagram. Each component has a carefully chosen name, and most of the connections between components are clear and unambiguous. Most of the components are thoughtfully laid out and the overall presentation of the diagram ensures that it will be easy for users to create the application, however there may be minor defects in layout such as occasional failures of alignment or logical grouping.
100%
All components appear in the schematic diagram. Each component has a carefully chosen name, the connections between components are clear and unambiguous. All components are thoughtfully laid out and the overall presentation of the diagram ensures that it will be easy for users to assemble the application.
• Demonstrated Learning Outcomes – 32 marks.
This category is broken down by target learning outcome, with a separate mark allocated for each learning outcome. Therefore, there will be 8 occurrences of each of the following criteria in the final marking sheet, one per learning outcome:
• Wiring Instructions (0.5 marks per learning outcome)
Fractional score
Indicative quality characteristics
0%
Report does not include wiring instructions.
25%
Wiring instructions are grossly substandard. Most components in the physical design are unlabelled; Instructions for many components are unclear or ambiguous; Components are glossed over, or imprecise terminology is used; The wiring instructions, if followed to the letter, would not possibly yield a working circuit.
50%
Wiring instructions are marginally adequate. Instructions for some components are clear and without ambiguity, but the position and connections between many components are unclear or potentially ambiguous. If followed to the letter to build a circuit, there is a moderate to high probability that the circuit would fail.
75%
Wiring instructions are mostly clear and without ambiguity, but for a small number of components or connections the instructions are unclear or potentially ambiguous.
100%
Wiring instructions clearly and without ambiguity define every component and hardware connection in the application.
• Functionality (1 marks per learning outcome)
Fractional score
Indicative quality characteristics
0%
Inspection of code and running simulation indicates the that feature does not work; Feature causes application to malfunction constantly.
25%
Some attempt has been made to implement the feature. Feature works sporadically but it is difficult to use in line with its expected purpose; Feature causes application to malfunction occasionally.
50%
A moderate effort has been made to implement the feature. Feature works most of the time, but occasional defects interfere with its expected purpose; Feature causes application to malfunction rarely.
75%
Feature works mostly without error according to expectation, but rare minor defects are evident when feature is used.
100%
Feature works flawlessly according to expectation.
• Demonstration (0.5 marks per learning outcome)
Fractional score
Indicative quality characteristics
0%
From watching the video, it is unclear that the feature works correctly; Feature is demonstrated, but causes application to malfunction constantly.
25%
The video makes it clear that some attempt has been made to implement the feature. Feature as demonstrated works sporadically but it seems to fall short of its expected purpose; During demonstration feature causes application to malfunction occasionally.
50%
The video makes it clear that moderate effort has been made to implement the feature. Feature works most of the time, but occasional defects interfere with its expected purpose; Feature causes application to malfunction rarely.
75%
Demonstration confirms that feature works mostly without error according to expectation, but rare minor defects are evident when feature is used.
100%
Demonstration indicates that feature works flawlessly according to expectation.
• Integration (2 marks per learning outcome)
Fractional score
Indicative quality characteristics
0%
The feature is unrelated to the application. There are no software or data dependencies between this feature and any other component of the application.
50%
The feature is marginally related to the application. There are software or data dependencies between this feature and other components of the application, but they appear to form an isolated sub-system which is not related to the rest of the application.
100%
Report sets out clearly how each claimed learning outcome is showcased by your application, and describes how each component contributes to the overall functionality of the application. Clearly documented software dependencies in the source code relate this feature to other components of the application.
Academic conduct
This is not a group assignment. While we encourage you to discuss the assignment and brain-storm with your associates, you must ensure that your submission is your own individual work.
• Share ideas, not code!
• An impeccable standard of academic integrity is required. Breaches of academic integrity, including plagiarism or any other action taken to subvert, circumvent, or distort the assessment process, will not be tolerated. QUT policy regarding academic conduct is available in the QUT MOPP Section C/5.3 Academic Integrity. In particular, under the provisions of MOPP statement C/5.3.7, Part (e), we reserve the right to require you to authenticate your learning. You may be required to show evidence of materials used in the production of the assignment such as notes, drafts, sketches or historical backups. You may also be required to undertake a viva or complete a supervised practical exercise.
• Do not post your solution in any form of publicly accessible online repository or file sharing service, or allow anybody else to obtain access to your solution in any way. Doing so will be classified as academic misconduct under the clauses pertaining to collusion, especially in the event that a copy of your source code obtained from such a service is submitted by another student, regardless of whether this has occurred without your knowledge and permission.
• Abundant code samples, demonstrations, and exercises have been made available to support your effort toward this programming task. Written permission must be obtained from the Unit Coordinator if you want to use technology other than the libraries supplied this semester to implement your application. Permission will only be granted if there are compelling special circumstances that make it impossible for you to use the libraries supplied this semester.
Breaching any of the foregoing conditions will result in an immediate and final score of 0 for the Assignment.
Notes:
• For purposes of AMS assessment, this activity has been classified as non-assessed. This does not mean the assignment is non-assessable – it means that the system is not able to assess the assignment automatically. AMS will not enforce a hard close-down for submissions, however in line with QUT policy, late submissions without an approved extension will not be marked. If special circumstances prevent you from meeting the assessment due date, you can apply for an extension before the due date. If you don’t have an approved extension you should submit the work you have completed by the due date and it will be marked against the assessment criteria.
• Attach only one version of your program in any single submission.
• When you have attached the required file, press the “Submit” button.
• Source files for each submission will be placed in a single distinct folder on the server, and compiled with the following command:
• avr-gcc \
• *.c \
• -mmcu=atmega328P \
• -Os \
• -DF_CPU=16000000UL \
• -std=gnu99 \
• -Wl,-u,vfprintf \
• -Wl,-gc-sections \
• -funsigned-char \
• -funsigned-bitfields \
• -ffunction-sections \
• -fpack-struct \
• -fshort-enums \
• -Wall \
• -Wno-strict-aliasing \
• -lm \
• -o n10447288.obj
• avr-objcopy -O ihex n10447288.obj n10447288.hex