CAB202 Assignment, Exercise 1: Microcontroller Assignment (Device 1)


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: 28 May 2021 23:59:59

Assessment Weight: 40%


FAQ (2 new):

1. Q: What do I need to submit as part of the assignment?

A: You need to submit a report via BB and the source code via AMS. Students taking the unit online must include a link to their tinkercad project in the report.

2. Q: Where I can find templates and howto's?

A: Instructions, templates and the link for submitting the report are now available in the assessment page on BB.

3. Q: How do I submit my report?

A: Instructions and the link for submitting the report are now available in Assessment page in BB.

4. 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/ (http://cplusplus.com/reference/), under the heading "C Library") are permitted. In addition, headers of the form <avr/xxx.h>, plus <util/delay.h>, are permitted. Third party libraries are permitted if they are not Arduino libraries (they must be referenced). If X is not covered by these descriptions, X cannot be used. And certain libraries, such as time.h, are not available in a microcontroller, so they cannot be used either. Some examples of header files you should avoid are Arduino.h, Wire.h, SoftwareSerial.h, SPI.h, LiquidCrystal.h, Servo.h

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

6. Q: How do I share a link to my TinkerCAD?

A: See Q1 above. In your private TinkerCAD project there is a button on the top right bar in the screen labelled "Share". Selecting that button will open up a pop-up menu with a button labelled "Invite People", select that button. Please select the "Generate new link" button to check your link is fresh for marking. Copy the link that you can see in the Collaborate pop-up menu into your report.

7. Q: How is the assignment marked?

A: You must demonstrate your project to your marker either in a face to face session or via an online meeting using zoom or equivalent. If demonstration is face to face, then the marking will occur during your on campus tutorial session. If demonstration is online, you must organize an online meeting with your tutor.

8. Q: What counts as "direct" for LCD direct write?

A: You can use "lcd.h" and "lcd_model.h", but not anything from "graphics.h".

9. Q: What does it mean to make an LED matrix?

A: Rows and columns of the LED grid should be wired together, and a multiplexing strategy should be employed to drive the LEDs. This resource (https://docs.broadcom.com/doc/AV02-3697EN) goes in-depth (much more than required for this task) into driving LED matrices, the first 2 pages give an introduction.

10. Q: What does it mean to make a switch matrix?

A: As with the LED matrix, rows and columns of the grid should be wired together, and a multiplexing strategy employed. Here (https://www.analog.com/media/en/technical-documentation/application-notes/AN_660_0.pdf) is a resource which describes how you might implement this.


Specification

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

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

a. The application is NOT a compendium of unrelated software and hardware snippets aggregated into a single package in a coincidental manner.

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

c. 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:

3. The application must demonstrate proficiency with the following specific functional capabilities, each of which is directly related to CAB202 learning outcomes.

a. Digital I/O – switch (i.e push button, push/momentary switch)

b. Digital I/O – interrupt-based debouncing

c. Digital I/O – LED

d. Analog Input – ADC

e. Analog Output – PWM, hardware-based; OR software-based “bit-banging”

f. Serial I/O – hardware based; polling OR interrupt mediated

g. LCD – simple text display

h. Timer modules – other than for debouncing or PWM

4. The application must demonstrate use of extended hardware functionality. Extended functionality involves hardware capabilities not explicitly demonstrated in class, and require you to interpret the information available in the datasheets. You must implement any number of the following items, for up to a maximum of 6 points:

(2 points) LED matrix display built from first principles. This is not a number of LEDs arranged in a square grid with each connected to its own pin on the microcontroller.

○ (2 points) Keyboard switch matrix built from first principles. This is not a number of switches arranged in a square grid with each connected to its own pin on the microcontroller.

○ (3 points) Signal processing tool: record analog signal and display on LCD (oscilloscope), record and play back (audio recorder)

○ (3 points) Distributed computing application: Matrix multiplication. For example, split matrix, send to different microcontrollers, process data, and results are sent back to be consolidated.

○ (2 points) LCD direct write: Low level, direct and at pixel level writing to the LCD. Examples may include animated bit-maps, sprites, line or pixel art

○ (2 points) Serial I/O – SPI or I2C, hardware-based; OR via bespoke code –“bit banging”. For example, this could be used to interact with a BH1750 light sensor without using the cab202_sensors library.

○ (2 points) Using sensors other than the ones provided in the kit, must provide you own driver/library. Examples includedlude infrared distance sensors, accelerometers, gyroscopes.

○ (1 point) Pin Change interrupt - Some pins on the Atmega328p are able to produce interrupts when the voltage on them is changed.  Use this for a switch or other inputs instead of polling.

○ (1 Point) Internal pull-up resistors - The Atmega328p can be configured to provide pull-up resistors to I/O pins internally, so that no external resistors are required.  Use this instead of external resistors.

○ (1 Point) Flash memory - Store data in the microcontroller's flash (program) memory to save SRAM space.

○ (5 Points) NeoPixels - Control a NeoPixels component (note you cannot use NeoPixels.h as it is an arduino library). This is a difficult task as it requires a signal with accuracy tighter that 1us (the shortest delay possible using delay.h functions).  It will require your code to take a specific number of clock cycles, which may make it necessary to write assembly code.

5. For the online students, the application must be implemented via a private TinkerCad Circuit emulation. Include a shared link to this as part of your report submission.

6. The application must be runnable – that is, all functionality claimed for the application must be able to be exercised during the demonstration. For online students, all software must be included in the TinkerCad Circuit, and which executes correctly when the “Start Simulation” action is invoked.

7. The software required to run your application must be fully self-contained, and consist entirely of original software crafted by you.

a. Third party libraries or source code obtained from any source other than the CAB202 teaching materials are permitted, however they must be referenced in your code and report.

b. You may use all functions in the standard C library, including any file which may be included via a C pre-processor directive

#include <somefile.h>

and which compiles correctly on AMS.

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

8. 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:

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

10. A written report containing the following sections:

a. Introduction: 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. (Max. length: 1/2 A4 Page)

b. 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: (Max Length: 1-2 A4 pages)

■ 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”.

c. 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. (Max Length: 1 page)

■ A link to the TinkerCad Circuit by itself does not meet this requirement

11. For online students, a shared link to your private TinkerCad Circuit where the prototype application is implemented.

○ This should be included in your report.

Details of the submission mechanism for report will be supplied by the end of Week 10.


Assessment Criteria

The application cannot be assessed accurately unless all four items listed at paragraphs 9, 10, and 11 above are submitted. 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:

1. Report (14 marks)

a. Introduction (4 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.

b. Schematic Diagram (5 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.

c. Wiring Instructions (5 marks)

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.

2. Overall functionality (20 marks)

a. Functionality (1.5 marks per learning outcome)

Fractional score
Indicative quality characteristics
0%
  Inspection of code and execution 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.

b. Integration (1 mark 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.

3. Extended hardware functionality (6 marks)

Fractional score
Indicative quality characteristics
0%
  No extended functionality is present.
25%
  Some attempt has been made to implement the extended functionality. Some feature works sporadically but it is
  difficult to use in line with its expected purpose; Features causes application to malfunction frequently. Implemented
  features are clearly explained in the report.
50%
  A moderate effort has been made to implement the extended functionality. Feature works most of the time, but occasional
  defects interfere with its expected purpose; Feature causes application to malfunction sporadically. Implemented features
  are clearly explained in the report.
75%
  Extended features work mostly without error according to expectation, but rare minor defects are evident when feature
  is used. Implemented features are clearly explained in the report.
100%
  Extended functionality implemented goes beyond the learning objectives of the unit. The used microcontroller functions are
  not directly covered in the unit content. Features work flawlessly. Implemented features are clearly documented and
  explained in the report.


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 (https://www.student.qut.edu.au/studying/assessment/late-assignments-and-extensions) 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 \
-I../../cab202_graphics \
-L../../cab202_graphics \
-lcab202_graphics \
-I../../cab202_sensors \
-L../../cab202_sensors \
-lcab202_sensors \
-std=gnu99 \
-Wl,-u,vfprintf \
-Wl,-gc-sections \
-funsigned-char \
-funsigned-bitfields \
-ffunction-sections \
-fpack-struct \
-fshort-enums \
-Wall \
-Wno-strict-aliasing \
-lm \
-o n10573097.obj
avr-objcopy -O ihex n10573097.obj n10573097.hex


○ If compilation is successful, AMS will verify that your program has compiled successfully and return. Your program will not be executed because there is no meaningful test that can be performed automatically on a program such as this.

○ The transcript will contain a copy of the compiled .hex file. You can paste this into a text document (using notepad++ or a Linux-compatible text editor) and save it as a *.hex file for local testing.