ELE000042C代写、代做C/C++编程语言

日期：2025-01-11 09:03

School of Physics, Engineering and Technology

[ELE000042C] [Programming and Digital Interfacing]

Assessment 2024/25

Summary Details

This assessment (Coding and interfacing project and brief report) contributes 100% of the assessment for

this module.

Submission is via VLE. The deadline is 1400 on Monday 13/01/25. Please try and submit early as any late

submissions will be penalised. Assessment information including on late penalties is given on the School of

PET Student Information Community Site

Academic Integrity

It is your responsibility to ensure that you understand and comply with the University’s policy on academic

integrity. If this is your first year of study at the University, then you also need to complete the mandatory

Academic Integrity Tutorial.

Please note:

● Unless the coursework specifies a group submission, you should assume that all submissions are

individual and should therefore be your own work.

● All assessment submissions are subject to the Department’s policy on plagiarism and, wherever

possible, will be checked by the Department using Turnitin software.

0

Contents

Summary Details.................................................................................................................................................. 0

Academic Integrity ............................................................................................................................................... 0

1 Assessment brief................................................................................................................................................ 2

2 Assessment requirements .................................................................................................................................. 3

2.1 Specifications and Restrictions ..................................................................................................................... 3

2.2 Submission requirements............................................................................................................................. 4

2.2.1 Report.................................................................................................................................................. 4

2.2.2 Project folder and functionality proof..................................................................................................... 4

3 Suggestions and guidelines................................................................................................................................. 5

3.1 Hardware connection guidelines................................................................................................................... 5

3.2 Basic to advanced software implementation ................................................................................................. 5

3.3 Making the submission on time and getting lab sign-offs................................................................................ 6

3.4 Tips on working........................................................................................................................................... 6

4 Indicative marks breakdown............................................................................................................................... 7

Appendix ............................................................................................................................................................. 7

A.1 Nucleo G071RB pinout................................................................................................................................ 7

A.2 Marking criteria in more detail..................................................................................................................... 8

A 2. 1 Notes.................................................................................................................................................. 8

A.3 Marking Rubric (Indicative).......................................................................................................................... 9

1

2

1 Assessment brief

90% of your module mark is achieved through submitting a code and a report on the task described below. Remaining

10% of your module mark is gained, as the module progresses, by providing evidence of being signed-off for the

successful completion of each of the assessed lab activities1 listed in section 3.3.

Your task, outside the lab activities, is to:

1. Write a program, using the Mbed OS environment and the Nucleo board provided (Nucleo G071RB), to display

the letters of your first and last name, in a scrolling fashion, on a single 7 segment display (provided in your kit

is the common cathode variant and is the one you must use) when a button specifically assigned (by you) is

pressed to trigger the display of each name. See figure 1 for pin-out of the 7 seg unit.

2. Write a short description of your code development process (more on this in section 2)

Figure 1: A 7-segment LED display pin information

This is an individual coursework and that means all the work must be your own. Collusion and plagiarism will attract

zero marks.

Read this document carefully and get back to me with any questions or concerns you may have via email or ask me

during the lab sessions. Please do not ask the GTAs about the assessment and do not rely on your peers for accurate

information.

1 10% of the module mark: Gained by READING the lab sheets BEFORE coming to the lab and making the necessary effort to

ATTEND each lab and COMPLETE DIRECTED TASKS and getting SIGNED-OFF. You do not need to submit any work arising from

your lab sheets, but you will need to declare having successfully completed the sign-off activities (which will then be verified).

2 Assessment requirements

2.1 Specifications and Restrictions

1. First 5 Letters* of your first name must be displayed when a button is pressed once by the user, and

First 5 Letters* of your last name must be displayed when another button is pressed once by the user.

E.g., For my (Rohan Kakade) first and last name, the outputs sequence would be as shown in figure 2 (1s inter letter gap is assumed here, but it can be anything reasonable). Click here for example videos.

Figure 2: Sample output for a system that display my first and last name

*Important note: If your first or last name contains less than 5 letters, then append any number(s) of your

choice to make it 5 characters each.

e.g., if your first name is “Tate” and your last name is “Sefe”, then you can display Tate1 Sefe2 or you can display

Tate3 Sefe8 etc. Hope you get the idea! If not, ask me.

2. Each lettermust be displayed for a suitably long time such that its comfortable for the user to read (you decide).

1s would be typical.

3. Both your first and last name must be displayed on the same 7 segment display i.e. you mayNOT use a second

7 segment display.

4. Letters must be displayed only in the format dictated by figure 3. No other format permitted.

5. The names must be your names (as recorded in university records) and not your nick names or shortened

names or your favourite person’s name etc.

6. The system functionality should be repeatable without requiring hard reset (i.e. without using the on-board

black button).

Figure 3: How alphanumeric characters should appear on the 7-segment display.

3

4

2.2 Submission requirements

8 elements constitute your assessment. They are described next. Please read carefully.

2.2.1 Report

Following 6 elements must be contained in a single document submitted in PDF format.

1. Block diagram of the system (on its own page ideally)

• Diagram showing how components are interfaced to the Nucleo board

• Do not draw by hand. I recommend using this free web tool, but you can use any tool you prefer.

• Embed/include links to datasheets of each component interfaced and the datasheet of the nucleo board

(Nucleo G071RB)

2. System schematic (on its own page ideally)

• Circuit Diagram showing how components are wired to the nucleo board that includes pin numbers and

component values. I recommend using EasyEDA online editor2

, but you are welcome to draw these using

any tool you like.

3. Flowchart (on its own page ideally)

• Algorithm of your final program in flowchart format.

• Please do not draw by hand. I recommend using this free web tool, but you can use any tool you prefer.

4. Code development story (1500 words max)

• Explanation of how the program was iteratively developed to its final stage. Show that you fully

understand what your program does and why it does it

• Do not paste in entire codes! Comment on what changes between different code versions and why these

changes were made.

• 1500 words max translates to about 3 pages with 1.5 line spacing and 12pt format. Length of your report

will vary depending on complexity of your code; more words do not equal higher marks.

5. Functionality proof (picture)

• Pictures of each letter of your name being displayed as expected (10 pictures in total; make a collage with

2 rows and 5 columns – first row for first name, second row for second name like in figure 2).

6. Sign-off proof

• A simple declaration at the end of the report saying “I claim sign-off for xx number of assessed labs”,

where xx is the number of assessment lab activities you have been signed-off for. The markers will verify

your claim.

2.2.2 Project folder and functionality proof

Following two elements must be submitted along with your report.

7. Functionality video proof (.mp4 file)

• Short (10-30s max) video (record using your phone or any other device) that clearly demonstrates the

functionality of your program. Should not exceed 90 MB.

• Ensure circuit connections and the Nucleo board are visible. Good wire management and neat breadboard

connections will be awarded.

• No marks for making fancy video edits and for adding audio commentary. No cuts or breaks in the

recording i.e. functionality demonstrated in one take

• Recording must be in .mp4 format (so that its playable on a standard video player like VLC)

8. The Mbed project folder (.tar file)

The entire Mbed project folder (must include main.cpp and any header files)

• Find and delete the file called compile_commands.json from your project to restrict the file size to under

25MB file size limit of the VLE. Right-click your completed project and choose “Download current selection”

OR left-click the “Download active project” menu option from the File menu.

2 If you are using EasyEDA for schematic creation, then you might need to look for the STM32G071RBT6 component in its library.

Refer to the lecture notes (on Schematic diagrams) for guidance.

3 Suggestions and guidelines

3.1 Hardware connection guidelines

1. LEDs are rated to have a maximum forward current and exceeding this can burn them out. Each LED on the 7-

segment display has a 20 mA max forward current rating. With 2.1 V forward voltage, the series resistor used

should be at least (3.3-2.1)/0.02 i.e. 60 Ω. I recommend using 100 Ω resistor between a nucleo pin and any

given segment. See figure 4.

Figure 4: Suggested 7-segment display interfacing to Nucleo

(schematic made in easyEDA)

2. You may choose to use the blue on-board button as one of the buttons, but the second button will need to be

connected externally. Don’t forget to configure the pull-up or pull-down resistor to avoid a floating input

condition. E.g., “DigitalIn buttonname(D0,Pullup);” will initialise digital pin D0 with a pull-up resistor.

3.2 Basic to advanced software implementation

3. A basic implementation, for pass mark, would demonstrate functionality using very linear programming that

simply checks each button and then turns on and off the LEDs to display a certain letter with thread_for_sleep()

to time the scrolling through of the letters. Nothing fancy here, but it meets the assessment brief.

4. Next level up - A simple system.

• This could deploy functions and set mechanisms to resolve button press conflicts and perhaps have

different scroll through times for the first and last names.

• It could also perhaps display some information on the serial monitor such as number of times the user

requests displaying each name.

• You could do something fun (yet simple) like displaying a default animation which gets erased and

written with the letter sequence invoked by the button.

• This is not an exhaustive list!

5. At the upper end - An intermediate and advanced system

• This could employ event-driven techniques for handling button events using callbacks to make code

more compact and efficient.

• You could create a class for driving the 7-segment display with methods (member functions) that allow

controlling the inter-letter times and selecting the precise letter to be displayed. There is opportunity

to pass on all pin states as a byte array to allow writing for example something like

“display(11111101);” to display ‘a’.

• Even better – you could pass on a letter or entire strings. Something like “display(‘r’);” or

“display(“rohan”);”

• Another interesting implementation could be asking the user to enter the names to be displayed and

then the letters of the chosen letters are displayed on button presses as before. This will require your

program be able to display any of the 26 alphabets.

5

6

• You could utilise interrupt service routines that allow the processor to do something else while the

buttons are not pressed. There might be an opportunity to use multiple threads.

• Again, this is not an exhaustive list by any means!

6. At whatever level you write your program, its important you clearly communicate your code development (it

carries the most marks!). Remember to save different versions of your program, so that you can present

snippets of each while discussing how your code has evolved.

3.3 Making the submission on time and getting lab sign-offs

7. As with anything important, do not try and submit at the last hour. You do not want to lose unnecessary marks

due to late handins.

8. For the sign-offs, it is your responsibility to ensure you get signed-off by a member of module staff (me or the

lab GTAs) BEFORE you leave the lab. Preparation is thus key; reading the lab brief document for the first time

during the lab will not work! If you miss a lab, for any reason, it is your responsibility to get signed-off in the

following lab(s).

9. Sign-off are only permitted in-person and attempting to get all/majority of the assessed weeks’ work signed

off in one lab will likely end in disappointment3 . Sign-offs over email will be permitted in exceptional situations

as judged appropriate by the module leader/school office.

10. The assessed labs (that require sign-off): Lab 3 (Functions), Lab 4 (Objects), Lab 5 (Motor control and

accelerometer sensing), Lab 7 (Interrupts), Lab 8 (Mutexes and Semaphores), Lab 9 (Pointers), Lab 10 (Arrays)

and Lab 11 (Strings).

3.4 Tips on working

11. Practice making a video of your circuit and check that you can upload to your university google drive and that

you are able to generate a link to this for inclusion in your report.

12. Start working on your project during the semester, rather than telling yourself “I’ll do it over Christmas”,

because you will likely have a hundred other things going on then (social events, exam prep, other coursework,

holiday etc.)

a. Clone this baremetal project if you don’t plan to use multiple threads or any event-driven techniques

(faster builds). Or clone this project if you want to use concurrent techniques (slower builds). These two

projects differ only in the contents of their mbed_app.json files, so it's easy enough to convert from one

configuration to the other if you find you need to.

b. Create a blank word document for your report or download and edit the report template document

available on the VLE (will save you time). If you are not using the template document, then in your

document create 8 headings (1 block diagram, 2 schematic, 3 flowchart, 4 code development story, 5

functionality pictures, 6 How to use guide, 7 Project planning evidence (Gantt chart) and 8 Sign-offs

declaration) to match requirements stated in section 2.2.1 and start working on headings 7, 1, 2 and 3 in

that order before starting to write any code and proceeding to other sections. System planning before

implementation.

c. Unless you are informed otherwise, once your report is ready, convert it to PDF format and give it a name

“PaDIprojectreport”

d. Once your Mbed project is ready and you are happy with the functionality

i. Record video of functionality and save it in .mp4 format.

ii. Download .tar file of your project (i.e. the entire Mbed project folder) as indicated in section 2.2.2.

iii. Move the .tar file, your .mp4 file and report’s .pdf file into one folder called “PaDIProject”

iv. Zip the folder and upload to the VLE submission page before the deadline

v. Celebrate! You are done!

3 You can expect 3-4 staff for 80 students in each session. Now imagine if 10 people were trying to get signed off with a few

saying “Can I get signed-off for the last 5 labs please?”

7

4 Indicative marks breakdown

# Criteria Weight

1 System planning and Interfacing methods

Block diagram, schematic, flowchart and use of appropriate h/w interfacing method

10%

2 Code development story

Evidence of code understanding

30%

3 Code structure (including code comments)

Evidence of clear, logical and readable code

15%

4 Functionality

Evidence of demonstrating core functionality

15%

5 Complexity and added functionality

Evidence of going beyond the base requirements and demonstrating innovation

20%

6 Lab sign-offs evidence

Evidence of lab activities completed.

(Evidence = sign-off by GTA/module in the lab)

10%

Appendix

A.1 Nucleo G071RB pinout

Available here

8

A.2 Marking criteria in more detail

# Criteria

[Refer to section 2.2, section 3.2, and section 3.3] for further details

Grade

0 = Little/No evidence

1 = Some evidence

2 = Good evidence

3 = Strong evidence

Weight

1 System planning and Interfacing methods

Evidence of system planning and appropriate hardware interfacing

10%

2 Code development story

Evidence of code understanding

30%

3 Code structure (including code comments)

Evidence of clear, logical and readable code

15%

4 Functionality

Evidence of demonstrating core functionality

15%

5 Complexity and added functionality

Evidence of going beyond the base requirements and demonstrating innovation

20%

6 Lab sign-offs evidence

Evidence of lab activities completed

(Evidence = sign-off by GTA/module leader in the lab)

[see notes] 10%

A 2. 1 Notes

Regarding lab sign-offs, your grade is calculated as per rubric. Key thing to note is that you if you receive less than 3 ‘assessed lab’ sign-offs, you do not get any marks in

this criteria, and full mark is only achieved by getting exactly 8 sign-offs (i.e. all assessed labs signed-off).

9

A.3 Marking Rubric (Indicative)

Criteria / Weight Little/No Evidence

Grade 0

Mark range: 0 - 39

Some evidence

Grade 1

Mark range: 40-59

Good evidence

Grade 2

Mark range: 60-79

Strong evidence

Grade 3

Mark range: 80-100

System planning

/ 10%

• Block diagram (BD),

schematic (SC) and

flowchart (FL) not provided

OR

Two or more of these are

presented in an incorrect

format.

• Hardware interfacing

might not have been

evidenced.

• One of the elements (BD,

SC, FL) is missing.

• Diagrams presented are

in the correct format, but

might contain missing or

incorrect information.

• There might be some

errors in hardware

interfacing.

• BD, SC and FL are ALL

presented, and each is

presented with good

level of detail.

• Flowchart contains

some level of specificity

to the target board and

Mbed OS.

• Hardware interfacing is

undertaken correctly

using appropriate

components.

• BD, SC and FL are ALL

presented, and each

presented with a high level

of detail.

• Due consideration and

justification provided for

choice of pins

• Flowchart is drawn to high

level of specificity to the

target board and Mbed OS.

• Appropriate components

used for interfacing with

good wire management.

Code development story

/ 30%

• Code sections from just a

single version of the code

are presented.

• No evidence of how and

why the code was

structured the way it was.

• An initial and a final

version of the key

sections (of the code) has

been presented.

• Some rationale provided

for the program design

choices made.

• Some changes may not

be explained at all or

explained inadequately.

• Multiple versions of the

code are discussed,

• Clear evidence for how

and why the code has

evolved to its final state.

• Changes made in a few

places were not

explained very clearly.

• A ‘how to use’ guide has

been presented.

• Multiple versions of the code

(key sections) are discussed,

with clear evidence for how

and why the code has

evolved to its final state.

• All design choices made

were explained very clearly.

• The various versions were

logged date wise and Gantt

chart presented.

• Very succinct and clear ‘how

to use’ guide has been

presented

10

Code structure

/ 15%

• Code has not been laid out

in any logical manner; poor

readability.

• Indentations are absent

and traces of legacy code

sections still present.

• Variables, functions and/or

classes not named

meaningfully.

• No comments provided to

explain complex and non obvious statements.

• Code may not compile.

• Code is largely structured

in a logical manner, but

comments are largely

missing to explain

complex and non obvious statements.

• Variables, functions

and/or classes are largely

named meaningfully.

• Choice of code structures

resulted in avoidable

repeated lines, leading to

higher memory use and

slower execution.

• No attempt made for

addressing error handling

and edge cases.

• Code compiles.

• Logical flow from start

to finish; good

readability.

• Well-indented in most

places

• Meaningful variable,

functions and/or classes

names.

• Comments are provided

consistently, with only

minor omissions, to

explain complex and

non-obvious

statements.

• Structured to reduce

execution time and

memory consumption.

• Error handling and edge

cases may not be

addressed effectively.

• Code compiles.

• Logical flow from start to

finish; excellent readability.

• Well-indented throughout

• Meaningful variable,

function and/or class names

and function names.

• Comments are provided

consistently to explain

complex and non-obvious

statements.

• Structured to considerably

minimise execution time and

memory consumption.

• Error handling and edge

cases are addressed

effectively.

• Code compiles.

Functionality

/ 15%

• Base

functionality not

achieved.

OR

• Functionality not

demonstrated.

Marks: 0

• Partial functionality achieved.

• Demonstrated through video and pictures of some/most of the letters

displayed as per design.

Marks: 50

• System is fully functional

(meets the requirements).

• Functionality demonstrated

(video and pictures)

Marks: 100

Complexity and added

functionality

/ 20%

SECTION 3.2

Base level achieved.

Mark range: 0-49

Intermediate level achieved.

Mark range: 50-79

Advanced level achieved.

Mark range: 80-100

Lab Signs-off evidence

/10%

SECTION 3.3

0<= Sign-offs <= 2

Marks: 0

3<= Sign-offs <=5

Marks: 30,45,60

6 <= Sign-offs <= 7

Marks: 70, 85

Sign-offs = 8

Marks: 100

11