MTRX2700 - Mechatronics 2
Lab 2 - C coding for microcontrollers
This lab is to be completed during the labs in weeks 6 and 7. The outcomes are to be
presented during your allocated lab session in week 8.
Objectives.
In this lab you will get a practical understanding of the theoretical concepts from this course. We will be
using the C language to create programs that can:
● Understand how the microcontroller handles memory (pointers, iterators)
● Demonstrate the use of interrupts for communicating over serial
● Demonstrate the use of timers to perform time critical functions
● Perform an integration of software modules.
Assessment process.
This assessment is to be completed in groups of 3 or 4 students. To help facilitate the group work, this
problem should be approached by having one or more students responsible for each module (area/topic)
- though it is important that each group member understands how all modules work and can describe the
details to a tutor.
A good approach to achieve this is for each student to focus on a task, do some research on the topic
and present their findings to the group. The group can provide feedback, and learn more about the topic
themselves in the process. Before completing the task, the software plan should be completed where
you write an outline of how the task/module will be completed (at this point, you should write function
templates), including documentation for the inputs and outputs of each function.
Testing is an important part of software engineering. Ideally, the testing plan should come before writing
any code. What are the valid range of inputs/outputs that should be handled by each function. What are
the constraints and limitations? You should get a different person to be involved in the construction of a
testing plan for each software module.
Required documentation
The documentation required for this project should be incorporated into the group git repository. This will
allow the tutors to access the code/documentation, and provide a history of the project including
who contributed to each component.
The git repository should include the following parts which are used for the assessment process:
● The code - the folder structure of the repo should be logical and should be able to be described
to the tutor.
● The documentation should be presented as the README for the group repo. This is the
only documentation that will be considered during the assessment process. The readme should
be viewed through the github web interface for the demonstration. An example README is
shown in the image below. The README document should include the following details:
○ The details about the project (group members, roles, responsibilities)
○ High level information about the code - the function, how the program is broken down into
modules.
○ Instructions for the user
○ Details about testing procedures
● The minutes and agendas from the group meetings. Stored in a folder in the repo called
“minutes”
The day of the assessment
During the lab in week 8, each group will be required to present their solution. There will be some bonus
for presenting early in the session, and some penalty for presenting late in the session. The details for
this are still to be determined. The tutor will be looking through the git repository which must be
completed and ready to go before the demonstration. Each member of the group will be called on to
describe various aspects of each module with a focus on the assessment discussion points listed at the
end of each exercise.
Before the demonstration, your group must tag the repo for release. Click on “tags” as shown in the
image below, and create a new release called “assessment demonstration”.
Assessment day checklist
❏ Git repo documentation complete and ready for assessment
❏ Create a release version tag called “assessment demonstration”
❏ Group members prepared to describe the software modules and testing plan
❏ Plan how you will be live demonstrating the functions of each software module to the tutor.
Exercise 1. Benchmarking the performance of arithmetic functions
Objective
Timing of mathematical functions is an important consideration for programming real-time systems. This
exercise looks to understand and benchmark the time it takes to perform various tasks using the HCS12
microcontroller.
Core functionality
Calculate and compare the time taken for each of the math operations [add, multiply, divide, square root,
sin/cos] given the different data types [int, long, 32-bit float, 64-bit float].
Extensions
● Output the time information to the serial
● Make the serial output “pretty” using a table like structure in ASCII
● Make the table structure a module that would be useful for later projects, can it handle different
lengths of information in the table, what are the constraints?.
Hints
● The hardware timer allows you to measure the time between events, make sure to consider what
happens if the timer overflows.
Discussion points for assessment
● The lengths of the various data types
● Timing overheads from other operations
● Influence of the compiler/optimiser
Exercise 2. Serial with interrupts
Objective
In lab 1, the serial was implemented using the polling approach. In this lab we will be using interrupts to
allow the serial receiving and transmitting to occur in the background, as to not disrupt other tasks.
Core functionality
Implement the serial receiving and transmitting using interrupts in C
Extensions
● Make a software module for a serial port where all parameters are defined in a struct
● Make this work for more than one serial port using the modules that you have created (it is ok to
demonstrate this using the simulator with SCI0 and SCI1)
Hints
● The simulator can use both serial ports SCI0 and SCI1 without any problems. On the dragon
board, SCI0 is generally not available (without setting the switches to “run” instead of “load”) as it
is used for debugging.
Discussion points for assessment
● How to buffer the data (for receive and transmit)
● How long (roughly) does the interrupt handler take to service the interrupt.
Exercise 3. Module for the major project
Choose one of the following modules to design, build and test.
Option 1
Display characters on the hardware 2-line LCD display.
I. Make a module that can output formatted data to both the 2-line LCD display, and to be able to
send the same data to the serial output. The mode should be able to be selected using a flag.
Extension
I. Use the serial VT100 terminal characters when outputting to the serial port so that the serial
display can redraw updated strings in the same lines of the terminal program (like putty). This
should allow you to replicate the 2-line LCD display in the serial terminal.
Option 2
Read the data (analog) from the accelerometers on the board
I. Design a module to interface with the analog to digital converter
II. Look at the accelerometer from the dragon board. Find the expected scale from the datasheet .
Without the hardware, you can simulate the voltages that would be expected and test the reading
of the analog values.
III. Read the analog accelerometer sensor, scale the values and output a meaningful measure of
acceleration to the screen/serial.
Extension
I. Determine on the dragon board hardware which direction is down in real time - display this on a
screen (LCD, serial, etc)
Option 3
Make the speaker work, play a tune.
I. Build a module that can interface to the speaker. The interface should pass a string or struct
containing the note/rest values to play, and they will be played in the hardware speaker.
Extension
I. Store the data in an array in the music module and have a flag to indicate when it is finished
II. Allow the module to determine how many notes/how much time is left until the end of the song.
Option 4
PWM output
I. Generate a PWM signal using timers (using the hardware, make this with a frequency of 100Hz;
in the simulator make this with a frequency of 1Hz)
II. Make the duty cycle change relative to an input that can be selected to be either the
potentiometer (in hardware, or simulated through ATD0 channel 7), or using a set of DIP switches
Extensions
I. Make the frequency and duty cycle parameters that can be passed through from the serial port
II. Make this modular such that it will work for any number of PWM outputs.
Marking Scheme.
Marks will be allocated based on the following criteria
● Does the core functionality, and any extensions perform as expected
● Quality of the solution
○ Code documentation
○ Modularity of the code
○ Code/algorithm structure
○ Plan for testing
● Presentation and discussion
This project is different from the previous lab. The solution you present should be contained within a
single project, with some mechanism used to select what components you want to display/demonstrate.
During the assessment process, we will require the demonstration of each component, the order in which
you do this is up to you.
There will be approximately 30% allocated to each of the 3 exercises, with some marks allocated to
administrative tasks including the management of the group, distribution of tasks, completion of meeting
minutes and agendas (which must be included in the repository in a folder called “minutes”) and
clarity/layout/quality of the project README documentation.
Please note - the tutors will be taking into account the challenges of working with remote group
members. We understand that this can add another layer of complexity to the learning process. This is a
very important challenge that requires good management and communication, well structured planning
and strong leadership.

欢迎咨询51作业君