Microcomputer Engineering 2
Assignment Manual 2018/2019
Part 1: Introduction
Part 2: The Assignments
Basic IO with C++ and mbed Mini-Project
Part 3: Circuit Diagrams
Microcontroller Board
I/O Board
Dr. Peter Green
School and Electrical and Electronic Engineering
University of Manchester
EEEN20019 Microcontroller Engineering II
1. Organisation of Assignments and Assessment
This section contains important information. Please read it!
1.1. Introduction TO FINISH
This unit aims to help you develop the knowledge and skills to program simple embedded
systems in the C programming language. This is a practical objective, so the module is
supported by two laboratory-based assignments. These assignments make up the
coursework for this unit.
Each assignment requires a range of activities:
(i) Independent study of lecture notes, exercise sheet questions and answers,
and technical documentation
(ii) The completion of assessed preparatory work before the start of the ?????
(iii) Laboratory work involving the development of C++/C programs based on the
specifications contained in the Assignment Scripts included in this document.
1.2 Laboratory Organisation
(i) You will attend four laboratory sessions.
The first 2 are concerned with Assignment 1, the second two with Assignment 2.
Lab sessions last for 1 hour 50 minutes and take place in the Barnes Wallis
building.
(ii) You will be allocated to one of four groups (1, 2, 3 or 4). The allocation of students
to groups will be posted on Blackboard at the end of week 1.
(iii) Each group attends laboratory sessions every two weeks.
The first lab sessions are in week 3.
(iv) There are 2 Assessment Sessions (week 7 and week 12), where your programs will
be marked.
1.3 Equipment
The equipment to be used in the laboratory assignments is:
• A laboratory PC
You will be allocated a PC in the Barnes Wallis cluster and you will use this machine in
all your Micro 2 sessions.
• An ST Nucleo Board (NB) - Nucleo F401RE.
• An mbed Application Shield (AS)
• A USB cable to connect the NB to a PC
6
You will each be given a NB/AS/USB cable when you return your PIC microcontroller board1.
Details of when NSs etc will be distributed will be posted on Blackboard. This is likely to be at
the start of week 2. The NB/AS/USB cable must be returned along with all your Embedded
Systems equipment at the end of semester 2
YOU MUST bring your NB/AS/USB cable to all Micro 2 sessions in the Barnes Wallis cluster.
Spares cannot be provided. You are also advised to bring a calculator, a copy of the
lecture notes, a copy of the laboratory script, paper and a pen/pencil. Personal laptops
and tablets can be used and tablets can be used in lab sessions BUT NOT IN
ASSESSMENT SESSIONS.
1.4 Marks
The coursework is worth 20% of the total unit mark. The mark allocation for the individual
coursework components is detailed in the table below:
Coursework
component
Mark as a fraction of
the total unit mark
Takes place Assessed in
Assignment 1 9% Weeks 3, 4, 5 and 6 Week 7
Assignment 2 11% Weeks 8, 9, 10 and 11 Week 9
1.5 Missed Laboratories and Deadlines
If you think you have a legitimate reason for missing a laboratory session, contact your
personal tutor to explain the situation. If your tutor agrees that your reason is legitimate, then
he/she should send me an email detailing why you need to reschedule your lab session.
However, on-line preparatory work must be completed by the original deadline.
1.6 Laboratory Rules
Pen drives/other removable media may NOT be used during lab sessions. Programs written
before the start of the session should be stored on your P drive, and downloaded at the start
of the session. Alternatively, you may arrive early and copy your own pre-written code from a
pen-drive before the session begins.
All other rules regarding conduct in laboratories in general, and the Barnes Wallis cluster in
particular, must be observed.
1.7 Assessment of Programs
The programs that you develop for Assignment 1 will be assessed in Week 7. Those developed
for Assignment 2 will be graded in Week 12.
1 The return of a PIC board does NOT apply to direct entry students.
7
• You must upload ALL your Assignment 1 programs to Blackboard by midnight on the
Friday of Week 62. If you do not, you will receive a mark of 0 for Assignment 1.
• You must upload ALL your Assignment 2 programs to Blackboard by midnight on the
Friday of Week 112. If you do not, you will receive a mark of 0 for Assignment 2.
• All uploaded programs should include the following information in comments at the
start of the program: student name, student id, lab group, program title, and date.
• Any additional information required for assessment will be specified via Blackboard
at least 1 week before the Assessment Sessions.
• Details of the upload procedure will be posted on Blackboard before Week 6.
During each of the Assessment Sessions, you will be interviewed by a demonstrator or
member of staff for up to 10 minutes. During this time you will be expected to demonstrate
your most complex working program (see Section ??? for further details). You will also be
required to explain how your programs work and to answer questions about them.
Note:
• Programs that do not work will be awarded a mark of 0.
• The quality of your explanations and answers will have a significant effect on the
marks that you will be awarded
1.7.1 The Last Week of the Semester
Attendance at both Assessment Sessions is mandatory. Note carefully that if you leave
Manchester before the Assessment Session in Week 12 you will be awarded a mark of 0 for
Assignment 2.
1.7.2 Plagiarism
Plagiarism in programming assignments is very easy to detect, even if function and
variable names have been changed. Do not be tempted to cheat and copy someone
else’s work – you will not gain any understanding or expertise, and you will be caught.
The School’s disciplinary procedures will be invoked against ANYONE involved in acts
of plagiarism. See your course documentation for further details.
2 In the event of DOCUMENTED problems with Blackboard, programs may be emailed to:
. These will be accepted so long as the email transmission
time is before midnight.
8
EEEN20019 Microcontroller Engineering II
2. General Advice
Most inexperienced programmers find programming a difficult3 and frustrating
experience, but one which is ultimately very rewarding. In recognition of this difficulty,
you should expect to spend between 12 and 16 hours on each of the two
assignments. This includes the scheduled laboratory session. The time that you spend
working on the assignment before the laboratory session should include the following:
• Thoroughly reading the assignment scripts.
• Thoroughly reading the relevant lecture notes, specified in the assignment
script.
• Attempting problems on the exercise sheets, as specified in the assignment
script.
• Reading any technical documentation indicated by the assignment script. This
will include the microcontroller’s data sheet [1], reference manual [2], the
HAL/LLL document. All are available on the unit’s Blackboard pages.
• Completing the preparatory work.
• Developing and testing prototype versions of the programs described in the
laboratory script. You should try to ensure that you have completed at least
the first part of an assignment before the start of the corresponding
laboratory session.
• Asking questions after lectures or by email, if appropriate.
These activities will significantly enhance your ability to complete the assignments
successfully, and will help with your preparation for the written examination in
January.
1.6 Contacting Me
I am happy to be contacted via email about any aspect of the unit. It is usual for me to
receive very high volumes of email from the class, given the nature of the unit, but I
try to respond within 24 hours. To help me be responsive, I would ask you to do the
following:
(i) Always start the subject of the email with MCE2, for example:
Subject: MCE2 Query about assignment 1
3 In fact, most programmers find programming difficult, full stop. It is simply that
the more experienced you become, the more you become accustomed to the
pain.
9
This is necessary as I use an email filter to separate out emails related to this unit
from the rest of my mail. If you don’t do this, I may miss your message and you
may not get a response to your question.
(ii) ALWAYS include your group number in your emails. If you don’t, I’ll simply reply
by asking for this information.
10
Unit Plan 2018/2019
Date Week Labs Type of
session
Groups Lectures
24/9/18 1 No Lab 1. Intro
2. ARM Review
3. Intro to OOP
1/10/18 2 Intro and
basic C++ 1
hour per
group
4. OOP C and O 1
5. Mbed
6. Digital IO
8/10/18 3 Digital and
analogue IO
with mbed
Lab 1 2
7. ADC 1
8. ADC 2
15/10/18 4 Digital and
analogue IO
with mbed
Lab 3 4
9. Interrupts 1
10. Interrupts 2
22/10/18 5 Timers and
callbacks
with mbed
Lab 1 2
11. Timers 1
12. Timers 2
29/10/18 6 Timers and
callbacks
with mbed
Lab 3 4
Revision
Revision
5/11/18 7 Timers and
callbacks
with mbed
Assessment 1, 2, 3
4
13. OOP C and O 2
14. Inheritance
12/11/18 8 Mini-project Lab 1 2
15. Serial Comms 1
16. Serial Comms 2
19/11/18 9 Mini-project Lab 3 4
17. LLL Programming 1
18. LLL Programming 2
26/11/18 10 Mini-project Lab 1 2
19. Buffers
20. FSMs 1
3/12/18 11 Mini-project Lab 3 4
21. FSMs 2
Revision
10/12/18 12 Mini-project Assessment 1, 2, 3
4
Revision
Revision
11
3. Software Development Environments
Two software development environments will be used in this unit:
• Mbed
• Keil µVision
Both of these are ARM products and will be discussed briefly below.
3.1 Mbed
Mbed is a ‘platform’ – essentially, it is a set of C++ class libraries (APIs4) that enable
programmers to control embedded systems peripheral devices in a large variety of Cortex-
based microcontrollers. Other key parts of the platform. are:
• A real-time operating system (RTOS)
• An on-line compiler
The RTOS is beyond the scope of this unit (but such matters are discussed in the 3rd year unit
Concurrent Systems). However, extensive use of the on-line compiler will be made. This is
extremely easy to use, and the best way to start is to watch the following video:
https://www.youtube.com/watch?v=L5TcmFFD0iw
This shows how to register with Mbed and then how to use the compiler. Once you have access
to the on-line compiler you will be asked to specify the board you are working with. For this
unit, the NUCLEO-F401RE board should be specified, and an icon representing it will appear
near the top-right corner of the page.
Go to the Mbed pages for the Nucleo-F401RE board:
https://os.mbed.com/platforms/ST-Nucleo-F401RE/
This contains a short video introduction to the board (worth watching), information about pin-
out and headers, and links to technical documentation from ST. It also has a Nucleo-based
video introduction to using Mbed and the on-line compiler which is also worth watching.
4 The class libraries are APIs (Application Programming Interfaces), as are the LLL and the HAL. APIs
consist of pre-written code (classes or functions) that enables applications programmers to access
necessary resources e.g. hardware devices, operating system functions, communications protocols etc.
12
This page also has links to a variety of simple Mbed programs that can be downloaded and run
on your board:
You are STRONGLY advised to download programs and experiment with them. However, you
should be careful not to use this code directly in your assessed programs, as this would be an
act of academic malpractice.
Additional programs are available via the Application Shield’s Mbed page:
https://os.mbed.com/cookbook/mbed-application-shield
These may also be imported into the on-line compiler. However, they may require a small
amount of customisation with respect to, for example, the pins that are specified in object
constructors.
3.2 Keil µvision
This is a sophisticated IDE (Integrated Development Environment) enabling C or C++
programs to be developed for an enormous range of ARM-based platforms. It can be
used to develop programs that use the Lower Layer Libraries (LLL), the Hardware
Abstraction Layer (HAL) and Mbed.
Keil is more difficult to use than Mbed, but its support for program development,
particularly in terms of debug, is very much better than the Mbed on-line compiler.
A free version of Keil is available for download at:
https://www.keil.com/download/product/
13
This limits the size of compiled programs to 50 Kbytes i.e. it does not allow very large
programs to be compiled. However, this will not cause problems for the programs that
will be developed in this unit. Moreover, the full version of Keil is available on the
Barnes Wallis cluster (100 licences) which is not subject to this limitation.
A video that describes setting up mVision can be found on the MCE2 Blackboard pages
at: ??? Note that Keil only runs under Windows. However, if you have an Apple
machine, you may be able to install Windows as a separate process and run µVision
of top of that.
Keil will be used during the second half of the unit.
14
2. Program Development
In order to develop a program that meets its requirements, it is necessary to have a clear
understanding of the program’s specification, and to design a solution. This involves deciding
upon what components are needed in the program and how they work together.
Components in a C program are functions and data structures, whereas in a C++ program, they
are classes and objects. The standard method for organising large C programs in terms of .h
and .c files5, which is discussed in Example Program 5, has similarities with the Object
Oriented approach, so the remarks below are made in terms of OO concepts.
Which components are needed in a program? The full answer to this question requires a
course in Systems Analysis, and more will be said on this topic in the Embedded Systems
Project. However, for this unit, hardware devices that must be controlled by a program are
good candidates for components, as are objects that control the behaviour/sequencing of
other objects, for example, the Sequencer class in Example Program 3. Objects that
temporarily store data such as buffers and stacks are also common. Note that the selection of
components is an ITERATIVE process – you are unlikely to select exactly the right set at the
start of development6.
Once a plausible set of components has been selected, it is necessary to determine how they
work together e.g. which functions call which other functions, the parameters that are needed
and the results that are returned. Related flow-of-control issues involving interrupts/callbacks
must also be considered.
Next the operation of each function must be specified. In other words the algorithm used in
the function designed or chosen7.
To summarise, a design for a C++ program would involve at least the following:
• A list of classes and a class diagram.
• A list of function prototypes for each class
• Declarations of any complex private data structures (e.g. list, stacks, buffers etc).
• A description of the operation of each function in terms of pseudo-code, state
machines etc.
5 Programs are divided into several source files (.c). Each .c file has a .h file with the same name
(e.g. my_code.c and mycode.h). The .h file defines the prototypes of functions implemented in
the corresponding .c file. It may also contain constants and typedefs. In OO terms the .h file
defines the public interface of an object, whose implementation (in terms of function code and
shared variables) is private - hidden inside the .c file.
6 You need to get used to the idea that you need to rework a solution to a design problem until it is
satisfactory. This is a fact of life in ALL engineering design.
7 If an efficient algorithm exists to implement a particular function, it is often wise to use it. Numerical
solution of differential equations, numerical integration, sorting and searching are 4 examples
where algorithms would be chosen and not designed from scratch.
15
After the design has been completed, the program must be implemented i.e. the actual code
must be written. Note carefully how much thinking needs to be done before the coding stage
is reached. Experience shows that starting to code without adequate preparation almost
always leads to programs that do not work.
You should take steps to back-up your programs, in particular those that actually work! As you
will see, some of the later tasks make use of code developed in earlier tasks. Do not simply
edit the earlier program, make a copy and edit that. Much of the code that you develop in
this module will be useful to you in other contexts (e.g. the Embedded Systems Project, your
third year project etc etc.), so be careful to preserve your investment of time and effort.
16
3. Programming Style.
Embedded systems programming is an important activity in many engineering enterprises.
These organisations always require code to be understandable, reusable and extendable.
Hence, you are expected to adopt a mature, professional style. of C/C++ programming. This
was introduced by example in your first year course and this will be continued in the example
programs presented in this unit. However, the basic guidelines are as follows:
(i) Use meaningful names for classes, functions, variables and types.
(ii) Use indentation with control constructs i.e. the statements ‘belonging’ to functions, if,
while, for etc. Statements within such a construct should be indented by 3 or 4 spaces
with respect to the if, while, for etc statement.
(iii) Make good use of comments, but avoid comments that state the obvious e.g.
x = 0; // x is set to 0
(iv) Don’t use ‘magic numbers’ in your code. ‘Magic numbers’ are constant values used in
expressions, as function parameters etc appearing without any explanation. For
example:
g_force = 9.8*mass;
circumference = 6.28*radius;
include the ‘magic numbers’ 9.8 and 6.28. Instead you should define these constants at
the start of the program via
#define G 9.8
#define PI 3.142
or
const float g = 9.8, pi = 3.142;
and then use the appropriate name in the statements to calculate acceleration and
circumference. Basically, application constants and system constants (e.g. fixed
addresses) should be defined as constants at the start of the program (or in a header
file).
(v) Use appropriate control constructs e.g. if you need a loop to execute a fixed number of
times, use a for loop, NOT a while loop with a counter that you create.
(vi) Use functions liberally, including 1 line functions, where it makes sense to do so. See
the example programs.
(vii) In C programs, do not use extern variables in place of auto or static variables8.
Many of you will consider doing this. Don’t.
(viii) White space (blank lines, tabs, spaces etc) are all good within reason, but don’t over-
use them.