Introduction to Real-Time Operating Systems

IL2206 EMBEDDED SYSTEMS
Laboratory 2: Introduction to Real-Time
Operating Systems
Version 1.4.1
1 Objectives
This laboratory will help you to
• acquire hands-on experience with real-time system concepts; and
• develop a real-time application on a typical real-time operating system
2 Preliminary Work
This laboratory shall introduce the students to Real-Time Operating Systems
(RTOS). The topic of this laboratory is the synchronization and communication between tasks in a real-time operating system applications. An RTOS
offers several objects for this purpose, like semaphores, mailboxes, message
queues and events. These objects are also used to connect interrupts to tasks.
In this laboratory, students shall deepen their understanding and practice the
use of these components by implementing a multi-task application.
If you want to learn more about real-time systems, you may be interested
in the course IL2212 Embedded Software that is given in period 3.
Further Interest in Real-Time Systems?
It is very important that students are well-prepared for the labs, since both
lab rooms and assistants are expensive and limited resources, which shall be
used efficiently. The laboratory will be conducted by groups of two students.
However, each student has to understand the developed source code and the
preparation tasks. Course assistants will check, if students are well-prepared.
Whenever you have completed a task of the laboratory, mark the task as
completed by putting a cross into the corresponding circle.
1
All program code shall be well-structured and well-documented. The
language used for documentation is English.
Documentation
For this laboratory all tasks of Section 2.1, 3 and 4 shall be considered as
preparation tasks. However, if you have worked seriously and encounter
problems, you can still book and visit a laboratory session to discuss with
the assistants.
Preparation Tasks for this Laboratory
2.1 Literature
Read chapter 16 and 17 of Labrosse’s book on MicroC/OS-II [Lab02] with
focus on mechanisms for synchronization and communication. The book
chapters are available via the course web page. It is important that you get
a good understanding how these mechanisms work in order to use them
efficiently. Go through the MicroC/OS-II documentation and check the
available mechanisms and their associated functions. Read [Alt].
You should also have a look on the project templates provided in the lab
repository, for example hello ucosii or the ones generated by the Eclipseliterature read ⃝ Nios2 IDE.
2.2 Questions
1. For this and the following questions you may need to again consult
chapter 16, which describes the functions in MicroC/OS-II in detail.
When dealing with message queues does MicroC/OS-II provide a
(a) non-blocking write?
(b) blocking write with timeout?
(c) blocking write?
(d) non-blocking read?
(e) blocking read with timeout?
(f) blocking read?
2. Which memory management functions can you use to allocate or free
memory in MicroC/OS-II? How do they work and what is the advantage
of these functions compared to usual C-functions as malloc?
3. The function OSQPend returns a pointer void*.
(a) What is a void*-pointer and how can it be used?
(b) How can you regenerate the message that has been send using the
void*-pointer.
2.2 completed ⃝
2
3 RTOS Tasks
This section is an introduction to RTOS tasks their communication and
synchronization mechanisms.
3.1 Accessing a Shared Resource: I/O
In the program TwoTasks.c found under il2206-lab/app/lab2-rtos in the
course repository, two different tasks write messages to the standard output.
Please observe also how you can get statistic information about the stack size.
• What is the expected output of this program in the first glance?
• The program might not show the desired behavior. Explain why this
might happen.
• What will happen if you take away OSTimeDlyHMSM() statements? Why?
• Semaphores can help you to get the desired program behavior. What
are semaphores? How can one declare and create a semaphore in
MicroC/OS-II?
• How can a semaphore protect a critical section? Give a code example!
• Who is allowed to lock and release semaphores? Can a task release a
semaphore that was locked by another task?
• Explain the mechanisms behind the command OSSemPost() and
OSSemPend()!
Modify the program so that it shows the expected behavior and save it as
a file TwoTasksImproved.c.
Draw the new application as a block diagram containing processes,
semaphores and shared resources. Use the graphical notation which has been
used in the lectures and exercises for this purpose, and included in Figure 4
from Appendix A. 3.1 completed ⃝
3.2 Communication by Handshakes
Modify the TwoTasks.c in such a way that implements two tasks which
communicate with each other via a handshaking procedure. Both tasks have
two states 0 and 1. In each state the tasks shall print a message to indicate
the status of the active task, e.g. “Task 0 - State 0”, if task 0 is in state 0. The
program shall then show the following execution pattern
Task 0 - State 0
Task 1 - State 0
Task 1 - State 1
Task 0 - State 1
Task 0 - State 0
Task 1 - State 0
...
independent of the task periods. Use semaphores to solve the problem!
Before you write the program, draw state diagrams including semaphores for
task 0 and task 1. Save the new program as Handshake.c. 3.2 completed ⃝
3
3.3 Shared Memory Communication
Modify your program Handshake.c in such a way that task 0 sends integer
numbers (starting from 1) to task 1. Task 1 shall multiply the numbers with
-1 and send them back to task 0. Task 0 shall then print these numbers to the
console. For the communication between task 0 and task 1 a single memory
location sharedAddress shall be used, i.e. both task 0 and task 1 read and
write to/from this location! Save the file as SharedMemory.c.
The execution of the program shall give the following output.
Sending : 1
Receiving : -1
Sending : 2
Receiving : -2
...
Draw a block diagram containing processes, semaphores and shared
3.3 completed ⃝ resources!
3.4 Context Switch
MicroC/OS-II provides also functions to set (OSTimeSet) and measure
(OSTimeGet) time. The function prototypes are shown below.
INT32U OSTimeGet(void);
void OSTimeSet(INT32U ticks);
However, these functions are far too slow to measure the context switch
time, since the real time clock frequency is usually between 10 and 100 Hz.
In order to measure the context switch overhead, you can use a timer or
performance counter. The steps to include and use them in your program can
be found in [Alt10, PER]. Be concious about the names of the performance
counters and timers when you are instantiating them in code by checking the
system.h file or the BSP you are using.
Modify your program Handshake.c to measure the time that is needed
for a context switch. Save this program as ContextSwitch.c. Please think
carefully how to measure the context switch time as accurate as possible. You
are needed to make an average on at least 10 measured values - excluding the
3.4 completed ⃝ values which differ so much to the average.
4 Cruise Control Application
In the next part of this lab you will have to develop a toy cruise control
application using the DE2/DE-115 board. If activated, a cruise control system
shall maintain the speed of a car at a constant value that has been set by the
driver.
The system has the following inputs:
• Engine (ON/OFF). The engine is turned on, in case the signal ENGINE is
active. The engine can only be turned off, if the speed of the car is 0
m
s
.
4
• Cruise Control (ON/OFF). The cruise control is turned on, if the signal
CRUISE_CONTROL is activated and if the car is in top gear (TOP_GEAR is
active) and if the velocity is at least 20 m
s
and the signals GAS_PEDAL and
BRAKE_PEDAL are inactive.
• Gas Pedal (ON/OFF). The car shall accelerate, if the signal GAS_PEDAL is
active. The cruise control shall be deactivated, if GAS_PEDAL is active.
• Brake (ON/OFF). The car shall brake, when the signal BRAKE is active.
Also the cruise control shall be deactivated, if the signal BRAKE is
activated.
• Gear (HIGH/LOW). The car has two different gear positions (high, low)
indicated by the signal TOP_GEAR. If TOP_GEAR is active then the gear
position is high, otherwise low. The cruise control is deactivated, when
the gear position is moved to low.
The inputs are connected to the following IO-units on the DE2/DE2-115
boards according to Table 1.
Signal Pin LED
ENGINE SW0 LEDR0
TOP_GEAR SW1 LEDR1
CRUISE_CONTROL KEY1 LEDG2
BRAKE_PEDAL KEY2 LEDG4
GAS_PEDAL KEY3 LEDG6
Table 1: Connection of Signals to IO-Pins on the DE2-Board
The system consists of four periodic tasks as illustrated in Figure 1. The
car will travel on an oval track of the length 2400m, which has the profile as
illustrated in Figure 2.
Vehicle
Button
IO
Control
Law
Switch
IO
Throttle
Speed
Brake Pedal
Gear
Engine
Gas Pedal
CruiseControl
Engine
Figure 1: Tasks in the Cruise Control System
5
0m 400m 800m 1600m 1200m 2000m 2400m
Figure 2: Profile of the oval track, which has a length of 2400m
4.1 Understanding the Initial Program
In the course repository, under il2206-lab/app/lab2-cruise there is an
executable skeleton program cruise skeleton.c, which implements the
vehicle task and an initial skeleton for the control task. In the skeleton
program, the control task uses a constant throttle of 40. The task VehicleTask
implements the behavior of the car and its functionality shall not be changed
during this laboratory. The only permitted code modification in VehicleTask
is the replacement of the timer (see Task 4.2).
Study the initial program carefully in order to have a clear understanding
4.1 completed ⃝ of the program. Execute it on the board.
4.2 Use Soft Timers to Implement Periodic Tasks
The skeleton program uses the statement OSTimeDlyHMSM to implement
periodic tasks, which will not give an exact period. Use instead soft timers
for this purpose and connect them with semaphores to your tasks. Use the
same period for the soft timers as in the original skeleton program.
See: OSTmrCreate in µC/OS-II Reference Manual, Chapter 16.
Do not forget to enable the soft timers by selecting a hardware timer to be
the timestamp clock for the system, besides the system clock itself, in the
scipts that generate the BSP!
Compilation flow
4.2 completed ⃝
4.3 I/O-Tasks
Create the tasks ButtonIO and SwitchIO, which read the buttons and switches
on the DE2-board periodically. The task SwitchIO creates the signals ENGINE
and TOP_GEAR, while the task ButtonIO creates the signals CRUISE_CONTROL,
GAS_PEDAL and BRAKE_PEDAL. Use the red LEDs to indicate that a switch is
active and the green LEDs to indicate that a button is active, as specified in
4.3 completed ⃝ Table 1.
4.4 Control Law
Implement the control law in the ControlTask so that it fulfills the specification from Section 4. Note that the braking functionality is implemented
inside the VehicleTask and requires a message to be sent, whereas the
ControlTask sets the throttle. For this example, the toy car has some hardwired safeguard circuitry which disables the car’s throttle whenever the
6
brakes are activated. Furthermore, you can assume that the dynamics of the
car is of a simple mass moving through the profile given subject to linear wind
resistance.
The control law shall react according to the state of the buttons and
switches. When the cruise control is activated, the current velocity shall be
maintained with a maximum deviation of ±4
m
s
for velocities of at least 25 m
s
.
Use the green LED LEDG0 to indicate that the cruise control is active.
Implement the dummy functions show position and
show target velocity. show position shall indicate the current position of
the vehicle on the track with the six leftmost red LEDs as specified in Table 2.
LED Position
LEDR17 [0m, 400m)
LEDR16 [400m, 800m)
LEDR15 [800m, 1200m)
LEDR14 [1200m, 1600m)
LEDR13 [1600m, 2000m)
LEDR12 [2000m, 2400m]
Table 2: LED assignment to show the position of the vehicle
show target velocity shall display the target velocity, which the cruise
control is trying to maintain, on the seven segment display (HEX5 and HEX4).
The display shall be reset to 0 when the cruise control is deactivated. 4.4 completed ⃝
4.5 Watchdog
To allow for the detection of an overloaded system, add a watchdog task
and an overload detection task to the system. The overload detection task
shall report to the watchdog with an ’OK’ signal, when there is no overload
condition, i.e. the system’s utilisation is less than 100%. In case the watchdog
task does not receive the ’OK’ signal during a specified interval, the watchdog
should infer that the system is overloaded, i.e. reached 100% utilisation, and
it shall consequently issue an overload warning message.
Add another task to impose an extra load on the system. It shall be
possible to dynamically adjust the amount of processing time that the task
utilizes. To set the utilization, the switches SW4 to SW9 shall be used.
The switch pattern shall be interpreted as a binary number (with SW4 as
the lowest bit), i.e., 2
6 values can be represented. The utilization shall be
adjustable in 2% steps. Everything higher than 100% (i.e., all numbers above
50) shall be considered as 100% utilization. Hint: think about the system’s
hyperperiod while interpreting the utilisation ratio “x%”.
Figure 3 illustrates the resulting system with overload detection. The grey
box contains the original system. Note that there are no connections from
the original system to the overload detection system, i.e., watchdog task and
overload detection task.
Test at which utilization, in “%”, a system overload occurs under different
circumstances (e.g. cruise control activated, car standing still, pushing gas
pedal, ...).
7
Extra
Load
Watch
Dog
Overload
Detection
Utilization
OK
Vehicle
Button
IO
Control
Law
Switch
IO
Throttle
Speed
Brake Pedal
Gear
Engine
Gas Pedal
CruiseControl
Engine
Figure 3: Cruise Control System with Overload Detection
Pay attention to the priority design choice for the tasks, i.e. watchdog,
extra-load task, overload detection task, so that any system overload is
4.5 completed ⃝ effectively detected.
5 Examination
Demonstrate the programs that you have developed for the laboratory staff
during your laboratory session. Be prepared to explain your program in
detail. In order to pass the laboratory the student must have completed all
tasks of Section 2.1, 3 and 4 and have successfully demonstrated them for the
laboratory staff.
References
[Alt] Altera. Using MicroC/OS-II RTOS with the Nios II Processor Tutorial.
Version TU-NIOSII-MCRC/OS-II-1.2.
[Alt10] Altera. Profiling Nios II Systems, 3.0 edition, July 2010.
[Lab02] Jean J. Labrosse. MicroC/OS-II: The Real-Time Kernel. CMP Books,
2002.
[PER] Performance counter unit core. In Embedded Peripherals IP User
Guide, chapter 37. Intel.
8
A RTOS graphical primitives
In order that the lab assistants understand your applications, draw them as
graphics using the symbols in Figure 4.
Figure 4: Graphical primitives for describing RTOS applications
9