ECED4402: Real-time Systems

Lab Manual

*CubeSat image from online article: “NASA 2024 Moon Mission Calls for CubeSats", accessed on September 10, 2021.

Department of Electrical and Computer Engineering

Lab instructions prepared by Andre Hendricks and J-F Bousquet

Lab 4 - Managing a Schedule with a Remote
Device

Dalhousie University
Department of Electrical and Computer Engineering
ECED4402 - Real-Time Systems
1 Objectives

The specific objectives of this lab are:

1. Software interrupts.

2. Enable communication between two remote computers.

2 Equipment

The equipment that will be used in the lab includes:

• The embedded processor development board.

• A USB download cable.

• A breadboard.

• A set of 4 light emitting diodes (LEDs).

• A set 1−kΩ resistors to limit the LEDs’ current.

• Two push-button with a debouncing capacitor.

3 Assessment

This lab is to be completed in teams of 2 students. A formal lab report must be handed in. The mark
breakdown is organized as follows

• Report:

– Introduction: 2 marks;
– For each exercise (10 marks);
1. Objectives
2. Answer to questions
3. Critical analysis summarizing concepts and challenges
4. (Bonus) Demo that the system works (using video, or picture)
– Conclusions: 2 marks.

2
4 Reading Material

Before the lab, it is recommended that you become familiar with these instructions. It is also recommended
that you become familiar with the following documentation:

• Mastering the FreeRTOS™ Real Time Kernel, by Richard Barry

– "Chapter 5 - Software Timers.

• Datasheet for SAMD20G18 found here.

3
5 Lab Manipulations

In groups of two students, in this lab you will:

1. Analyze the use of software timers.

2. Analyze an existing design relying on serial protocols.
3. Develop a development procedure to program and test a real-time system with remote sensors.
4. Program and test the system.

5 .1 Software Timers

In this exercise, we will utilize software timer to create a traffic light. The traffic light consists of several
LEDs: Green LED used to indicate "Go", the yellow LED used to indicate a warning that the Red is soon to
follow and the red LED to indicate "STOP".Additionally, there is the a white LED that is used to indicate to
pedestrians that it is safe to walk. The white LED will be solid white for half the time that the green LED is
turned on. After which, it will start blinking. The white LED is off when the yellow or red LEDs are active.

Software timers allow for code to be quickly ran whenever little to no processing is required. The timer
created in this instance will follow the procedure. Red light = 3 seconds. Green Light = 3 seconds. Orange
light = 3 seconds with blinking at a frequency of 1 Hz. The white LED will have a frequency during its
blinking phase of 2 Hz. This could be ran using a task , however, it is going to be shown that for a simplistic
state machine like this the software timer are more suited.

Using the original code provided here, analyze the original code and predict the output.

Build, and run the code. Observe the output.

1. Run the code, and observe the output.

Concluding questions.

1. What are the pros and cons of using software timers?

2. Is there a time resolution limit? if so, What is that limit?
3. Is there a limit to the number of FreeRTOS timers? if so, what causes the limit.
4. Does software timers have a higher priority level compared to hardware timers. If both were triggered at
the same time which would run first?

4
5 .2 Controlling a remote underwater sensor

5 .2.1 Introduction

To monitor the ocean, underwater sensors are deployed in various regions of the globe. For example, Argo
(https://argo.ucsd.edu/) is an international program that collects information “from inside the ocean using a fleet
of robotic instruments that drift with the ocean currents and move up and down between the surface and a mid-
water level”. Similarly, at Dalhousie, the Ocean Tracking Network (https://oceantrackingnetwork.org/), tracks
the behaviour of various aquatic species, using tags, and a network of tag sensors deployed on the littoral, in
lakes and rivers. As another example, to monitor activity at the sea surface, Saildrone provide surface vehicles
for climate, mapping, and maritime security applications. Typically, the remote sensing platforms are typically
equipped with heterogeneous instruments that can measure different signals to obtain information about the
chemical, biological, geographical environment.

In this exercise, a program running on an embedded processor must be developed to interface in real-time
with a remote sensor platform. The program will be required to enable a minimum of two sensors: a depth
sensor, and an acoustic sensor. The program must also acquire the sensor information in real-time. For this
purpose, a communication protocol is defined to interface between the controller and the remote platform. The
communication link is running on a USART physical layer.

To support you in the development of this exercise, a software design is provided to you. A hierarchical
design includes (from bottom - up) a driver to access the USART on external hardware pins, a communication
datalink that creates frames for sending and receiving, and an application layer that is organized in multiple
tasks to control the different sensors. The design description includes the structural and behavioural description
of the different modules.

5 .3 System Description

The underwater sensor is a network of 3 devices as shown in Figure 1. It consists of a host computer, the
sensor controller and the remote sensing platform. The host computer will allow the user the get information
from the remote sensing platform and interface with the sensor controller. The sensor controller communicates
with the remote sensing platform in order to process sensor data and keep track of the sensor status. The remote
sensing platform (provided by instructor) interfaces with the ocean sensors directly and temporarily stores their
data in a buffer that is updated periodically based on the sensor.

At the core of the network, the sensor controller resets and configures a remote sensor, gets the information
on a periodic basis, and forwards the interpreted data to a host computer.

The remote sensor program is already fully implemented for you. The sensor code is provided here.

5
 Figure 1: The Network of Devices

5 .4 Modules

For the sensor controller, a proposed design is described below. Note that that a program sub-divided in
multiple files with incomplete code is provided to you and can help you complete your own design.

The modules required to implement the controller are shown in Figure 2. Each module represents a file.

The System Controller is intended to reset the remote sensor platform, and enable the sensors individually.
Its behaviour is defined in the task Run();

The Acoustic Sensor Controller receives the acoustic data from remote platform. The design allows for data
analysis and manipulation, before it is forwarded to the host computer. Its behaviour is defined in the task
RunAcousticCtlr();

The Depth Sensor Controller receives the depth data from remote platform. The design allows for data
analysis and manipulation, before it is forwarded to the host computer. Its behaviour is defined in the task
RunDepthCtlr()();

A CommDatalink object is used to send strings in the appropriate format, and parse incoming messages from
the USART Driver.

The USART driver is the interface to the hardware. It holds two connections: one for the host com-
puter(through the deubgger), and a second for the remote sensing platform. The transmit pin for the second
connection is PB08, while the receive pin is PB09.

6
Figure 2: Representation of the Modules for the Sensor Controller

7
5 .5 The behaviour

The state machine for the system controller is shown in Figure 3. On startup, the system is initialized, and a
reset should be sent. Then, the acoustic and depth sensors can be configured and enabled. When the sensors are
enabled, the sensor information is interpreted, and returned to the host computer. If a message is not received
after a specified period of time, the sensors are disabled, and the program is closed.

For this original version of the system controller, the interpretation simply consists of forwarding the acoustic
data and depth data to the debug port. In future iterations, the data can be analyzed at this node, before being
forwarded.

Figure 3: State Machine for the Controller

In addition to the system controller task, two additional tasks are created to receive, and buffer the remote
sensor information.

5 .6 The communication protocol

The format of the messages transmitted between the controller, and the remote sensor are shown in Table 1.
They follow a similar protocol as the NMEA protocol. Note that a checksum is appended to the message.

8
 Table 1: Description of the messages

Direction Parameters
ResetSensor $CNTRL,00„*, CS\n TX -
SensorResetAck $CNTRL,01„*, CS\n RX -
Enable Acoustic Sensor $ACSTC,00,PERIOD,*,CS\n TX PERIOD( 8 characters) is
the period for the update
of the acoustic sensor data
request
Acoustic Sensor Enabled Ack $ACSTC,01„*,CS\n RX -
Acoustic Data $ACSTC,03,DATA,*,CS\n RX ID (8 characters) is the
acoustic data identifier re-
quested
Enable Depth Sensor $DEPTH,00,PERIOD,*,CS\n TX PERIOD( 8 characters) is
the period for the update
of the acoustic sensor data
request
Depth Sensor Enabled Ack $DEPTH,01„*,CS\n RX -
Depth Data $DEPTH,03,DATA, *, CS\n RX ID (8 characters) is the
acoustic data identifier re-
quested

An example of a test sequence to communicate to the remote sensor is the following

• $CNTRL,00„*,49: to reset the remote sensing platform.

• $ACSTC,00,00005000,*,4D: to configure the acoustic sensor to return information at a period of 5

seconds.

• $DEPTH,00,00002000,*,41: to configure the depth sensor to return information at a period of 2

seconds.

5 .7 Instructions
1. Analyze the code for the remote sensor.

(a) Draw a diagram showing the relationship between the modules, similar to that of Figure 2.
(b) What are the TX and RX pins for the external USART?
(c) What is the buffer size for the USART receiver?
(d) Does the USART transmitter rely on a callback function?
(e) Review and explain the algorithm to generate the checksum. What is the purpose of the checksum?

9
Figure 4: State Machine to Parse a Message

10
 (f) Confirm that the parse message state machine matches the state machine shown in Figure 4. Are all
the conditions shown in Figure 4 implemented?
(g) Use a flowchart to explain the RemoteSensorTask() function.
(h) Use a flowchart to explain the SensorTask() function state diagram.
(i) How are we ensuring that when a new message is received in the RemoteSensorTask() function, it
is processed in a timely fashion by the SensorTask() function?

Build and download the program to your board.

1. Develop a plan to develop a sensor controller. The plan should include the hardware connections between
the controller and the remote sensor. It should show a diagram showing the modules. It should also
include a flow chart for each of your tasks.
A test procedure should also be defined, using two embedded processors connected through the external
USART pins.

2. (BONUS) Complete the program to implement the state machine shown in Figure 3, as well as the two
additional tasks to receive data from the sensors. A draft of the code with libraries is provided here.

3. (BONUS) Demonstrate that in regular mode of operation, the acoustic and depth data are returned to the
debug port.

In your report include an analysis of the proposed design, and a number of tools to improve the organization,
and efficiency. Do you see potential bugs/omissions in the behaviour of the original code?

6 Conclusion

In this lab, first you analyzed a program using timers to run a traffic light controller. Second, you analyzed
and produced a design using serial communication protocols to exchange information between multiple nodes.
This final exercise is an example of a real-time system that integrates multiple concepts for Real-Time Operating
Systems, including access to peripherals, semaphores, mutexes, and timers. By using these tools, we can now
see the potential to create a complex processing system on a single processor core.

11
7 Appendix

7 .1 Example Project: "Quick Start for Debug Print"

If you need to re-create the project, the steps from lab 1 are summarized below:

1. Launch Microchip Studio.

2. Create a new Example Project. Select the project named "Quick Start for Debug Print (FreeRTOS) -
SAM D20 Xplained Pro".

3. Change the device from SAMD20J18 to SAMD20G18.

4. Connect the custom board and Atmel-ICE programmer.

5. Select the SAM-ICE programmer.

This will create a project with a single task that sends a string to the debug COM port.

12