Lab Session 1

Review of C language

1.1 Session Outcomes

At the end of this session, the students will be able to,

1. Explain why C language is used to write core part of OS and C++ is

used for graphical User Interface (GUI) of larger operating systems.
2. List the topics in which he/she is weak and discuss the queries with the
team members and try to solve it. If these donot get solved, use Internet
resources and try to resolve queries.
3. Write pointer based program to access and operate on array elements.

1.2 Revision of C language features

1.2.1 Data types
C language has few built in data types. These are,

1. unsigned character: This data type can hold unsigned number of value
from 0 to 255. The memory required to store an unsigned character
variable is one byte.
2. signed character: This data type can hold signed number of value from
-127 to +128. If a variable is declared without mentioning signed or
unsigned, then it is considered as signed and therefore the maximum
value that it can hold becomes +128 (Not 255). Therefore whenever, we
donot require signed number to be stored, we must declare the variable as
signed or unsigned explicitely. it is a good practice to always explicitely
2 Review of C language

mention signed or unsigned while decalring a variable. The memory

required to store a signed character variable is also one byte.
3. unsigned integer: This data type can hold unsigned number of value from
0 to +232 . The memory required to store a signed integer variable is 4
bytes. (In some compilers, it may be 2 bytes.).
4. signed integer: This data type can hold signed number of value from
-(231 1) to +231 . If a variable is declared without mentioning signed
or unsigned, then it is considered as signed and therefore the maximum
value that it can hold becomes +231 (Not +232 ). Therefore whenever, we
donot require signed number to be stored, we must declare the variable as
signed or unsigned explicitely. It is a good practice to always explicitely
mention signed or unsigned while decalring a variable. The memory
required to store a signed integer variable is 4 bytes. (In some compilers,
it may be 2 bytes.)
5. double: This data type can hold the value from ...
Write additional data types

List the facilities in C language which one needs to know before studying
the RTOS source code.
These include data types, pointer, pointer to pointer, pointer data types,
structure, pointer to structure, size of structure type variable, arrays, shift left
and shift right operators, meaning of void, NULL.
It is also preferred to know about the coding styles that involves comment
block for the file and for function, indenting, readable variable names, com-
ments explaining need of a variable etc.

1.3 Home work

1. Write a C program that will create a structure and variables of that
structure type. Initialize the structure variable members and print them.
2. Write a C program to illustrate the concept of pointer. Also illustrate
effect of accessing integer data using integer pointer and same data using
character pointer. What will happen of an integer data is accessed using
double pointer?
3. Check if you have written above programs following coding standard. If
not, re-write those programs using propoer coding style.

1.4 Questions
1. What is a pointer?
2. Why pointer has its own data type?

Real Time Operating System, Dr. V. B. Dharmadhikari

Sect. 1.4 Questions 3

3. Can we change the data type of a pointer? How? If we change it, what
is its effect? Illustrate with a suitable C program.

Real Time Operating System, Dr. V. B. Dharmadhikari

4 Review of C language

Real Time Operating System, Dr. V. B. Dharmadhikari

 Lab Session 2
Introduction to uCOS-II based
application

2.1 Session Outcomes

At the end of this session, the students will be able to,

1. To get familiar with RTOS in Keil environment.

2. To understand the basic code of tasks and its operation.
3. To be able to build the code and simulate it using logic analyzer window.
4. To experience that all tasks run simultaneously despite having multiple
while(1) loops
5. To observe the timing and verify it.
6. To observe that even if the LEDs seem to switch on-off simultaneously,
they actually are NOT switched on-off simultaneously. There is a small
delay in between. Write the reason of this delay.
7. To observe that, after we stop the simulation, the code execution point
is shown from some file other that our application code file. Write the
reason for this.
8. To modify the timing of one task and observe that it does not affect the
timing of other tasks.
9. Write the mistakes which we did and how did we solve them.
10. Able to show that operating system source code also is compiled and is
part of the hex file.
11. The final hex file contains the OS code as well as the application code.
12. The RTOS runs on the processor where the hex file will be downloaded
(along with application code)
6 Introduction to uCOS-II based application

13. Able to write the task without copy paste.

14. Modify the self-written task for creating different waveform patterns.
15. Write the lab report of this lab.
16. Submit the lab report in time.

2.2 Details of session outcomes

2.2.1 To get familiar with RTOS in Keil environment
The students should be able to open the given uVision project in Keil IDE.
They should know the folders in the project window. If project window dis-
appears, they should be able to restore it. They should be able to explain the
need of having folders in the project window and various categories of the files
in the project.
The students should know the following categories of the files in the project.

1. Platform independent code of RTOS: These files are under folder

uCOS. This folder contains all the .c files of RTOS which contain code
that is independent of platform. Such files exist because, the RTOS
is written by the RTOS writer who maynot know the platform (ARM,
TI, Infineon etc.). Also the RTOS writer expects the RTOS code to be
portable to any platform. Here portable means, the RTOS should be
able to run on different platforms with least changes in the code. Most
of the RTOS code is platform independent and hence the .c files of such
platform independent code are put together in the uCOS folder.
2. Platform dependent code of RTOS: These files contain the code that
is part of OS but it is dependent on the platform used. These files are
under the folder ARM. Such files are required since the OS needs some
low level activity to be written in assemmbly language of the processor
used and hence it becomes platform dependent.
3. Board dependent code of application: When we select a particular
platform / processor, (such as LPC2148) then, we design the board that
contains hardwarre as per the requirements of the application. For exam-
ple, if the application requires few LEDs, an EEPROM, an external ADC
etc., then the board will be designed by the hardware designer, to have
these facilities on the board. Now the pins to which the external hard-
ware is connected is known to the hardware designer (and not to RTOS
write). Hence there will be some files (.c code) that contain functions to
control the hardware. Therefore the project will contain some files which
are board specific. In our project, such files are under MD2148 folder.
4. Actual application code: These files contain the actual application
code. These files are usually kept board independent so that the applica-

Real Time Operating System, Dr. V. B. Dharmadhikari

Sect. 2.2 Details of session outcomes 7

tion can be ported to other board/platform easily. These files are under
main folder in our project.

2.2.2 To understand the C code of tasks and its opera-

tion
The students will observe the code of each task and observe that the tasks are
infact C functions. They should observe that each task has its own while(1)
loop which ensures the task to be functioning forever. Also they will understand
that the all the tasks flash LEDs with some rate decided by the delays in the
code. Also they will observe that the delay function is not written by the user,
but it is function provided by the RTOS. The students maynot know why it
is done at this time, but they should understand that, OSTimeDly() should
be used in the task. Also they should understand that the argument of the
OSTimeDly function reperesents multiple of some interval which they can find
out experimentally through simluation. They need not understand why it is
done at this time.

2.2.3 To be able to build the code and simulate it using

logic analyzer window
The students should be able to activate the logic analyzer window. They should
be able to setup port pins, observe the timing etc.

2.2.4 To experience that all tasks run simultaneously

despite having multiple while(1) loops
The students will build the project, and simulate it. They will observe the
waveforms in the logic analyzer window and observe the waveforms correspond-
ing to each LED. When all the waveforms are seen, they it means that, al the
LEDs are being operated propoerly, and it also means that, all tasks are func-
tioning even if every task as its own while(1) loop. This indirectly means that,
the OS breaks the while(1) loop as per the need and passess control to various
tasks so that all tasks can fuction with proper timing.

2.2.5 To observe the timing and verify it.

The students will measure the on and off time period of the waveform and
check the relation between the arguments of OSTimeDly() functions and the
actual timing of the Waveform.

Real Time Operating System, Dr. V. B. Dharmadhikari

8 Introduction to uCOS-II based application

2.2.6 To observe virtual parallelism

The students should observe that, if all the delay values are equal, then the
waveforms of LEDs change state simultaneously. However, if the waveforms
are zoomed in then they can observe that the LEDs actually donot change
the state simultaneously, but they change the state one by one. With this
observation, the students will understand that the RTOS creates an illusion of
parallelism or virtual parallelism, but in reality the things are happening one
by one. The students should write the reson for the delay between the swith
on instance of LED0 and switch on instance of LED1.

2.2.7 To observe where does the cursor go when the

simulation is stopped
After we stop the simulation, the code execution point is shown to be in some
file other than our application code file. The students should write the reason
for this.

2.2.8 To observe the effect of changing the timing of one

LED
The students should change the timing of one LED, build the code and simulate
it. They will observe if the timing of other LEDs is affected or not. They
neednot know the reason now, but they will understand the use of RTOS, makes
the programming easy, since the application writer can change the timing of
one task as per need and it does not affect the timing of other tasks.

2.2.9 Mistakes and the solutions

While doing this lab activity, the students will make some mistakes or they
will some new things/skills. They need to write what mistakes they made and
how did they sove any problem that they faced.

2.2.10 RTOS also is compiled along with the user appli-

cation
The students should be able to show the RTOS files (without explaining their
content) in the project. They can also create a syntax error in the OS code
and compile. The compiler will show errors. This proves that OS files are also
compiles. The students must remove the error and recompile successfully.

Real Time Operating System, Dr. V. B. Dharmadhikari

Sect. 2.3 Report contents 9

2.2.11 The final hex file contains the OS code as well as

the application code
The students should observe the code size of the compiled project and note
down how much code memory is occupied by the RTOS.

2.2.12 Where is the RTOS?

The students should know where is the source code, where is the compiled code
and where is it running.

2.2.13 Write the task without copy paste

The students should carefully observe the task0 code. Then they should type
the same taks0 code without looking at the old code. They will comment the
old task0 code and compile the project. The project should build witout errors
or if errors occur, they shuld be able to remove the errors.

2.2.14 Modify the self-written task for creating different

waveform patterns
In the given sample project, the on-off periods are equal. The students be
asked to create the waveform with 2 units on, 2 units off, again 2 units on and
20 units off.

2.3 Report contents

Submit hand written report containing
1. Aim
2. Basic theory of RTOS covering what is RTOS, what is need of RTOS,
Advantages of RTOS, disadvantages of RTOS, Types of RTOS
3. Procedure to be followed for various observations
4. Observations. These will include the screenshots with figure numbers
5. Conclusions with reference to the observations (mention appropriate fig-
ure numbers.
6. List the things you learnt and the skills you acquired.

2.4 Questions
1. Explan the purpose of platform independent code of RTOS?
2. Why there are board specific files in RTOS based application?

Real Time Operating System, Dr. V. B. Dharmadhikari

10 Introduction to uCOS-II based application

3. How will you identify that a particular .c file is a board specific file?
4. The hex file of RTOS based application contains the code of application
along with RTOS (T/F).

Real Time Operating System, Dr. V. B. Dharmadhikari

 Lab Session 3
Detailed structure of an RTOS
based application

3.1 Session Outcomes

At the end of this session, the students will be able to understand the basic
code of a simple RTOS based application. The same is detailed below. The
students should be able to understand, explain/illustrate the

1. Need of the config.h file and facilities in that file

2. Need of stdlib.h ans stdio.h files
3. Defining the stack for each task and datatype of its elements
4. Task function declarations
5. TargetInit() and OSInit() functions
6. Need of OSTaskCreate function and understanding of the arguments of
it
7. Need of OSStart()
8. Return type and Pointer argument of task function
9. Stepwise execution of RTOS based application
10. Creating task and deleting task within a task
11. Observing the effect of OSTimeDly on the execution sequence of appli-
cation
12. Observing practically the Application running on a LPC2148 microcon-
troller kit
12 Detailed structure of an RTOS based application

3.2 Details of session outcomes

3.2.1 Need of the config.h file and facilities in that file
The students should be able to open the config.h file and explain the various
important facilities in it for configuring the RTOS.
They should know why to configure the RTOS.
The RTOS based application will finally run on a microcontroller board.
The microcontroller on that board may have crystal of 4MHz, 10MHz or some
other value. In order to have proper timing in the application, the RTOS must
be told the crystal value. This value can be set in config.h.
The RTOS needs to be configured because, the requirements of each appli-
cation can be different. For example, one application may need maximum 25
tasks, whereas the other application may need only 7 tasks. In such case, if
we configure the RTOS for 25 tasks, than it will use more RAM. This is be-
cause, the OS needs to keep track of each task, its state etc for which it needs
RAM space to store them. Therefore, if an application needs less number of
tasks, it is better to configure the RTOS for those many tasks and reduce the
use of RAM. This can be done by setting proper value on line number 30 of
OS CFG.h

#define OS_MAX_TASKS 15

The OSTimeDly() function has to be given an argument between 0 to 65564

that represents the number of unit interval of time. What this unit interval
means is to be configured in the file OS cfg.h.

#define OS_TICKS_PER_SEC 10

Here, the ticks per second is set to be 10. If there are 10 ticks in a second,
then the tick time (interval between two ticks) is equal to 100mSec. So the
statement OSTimeDly(2); will result in 200mSec delay.

3.2.2 Need of stdlib.h ans stdio.h files

These files contain the declarations of various functions which are commonly
required. These include string operations, memory allocation and deallocation
functions, printf, scanf etc. Refer to techonthenet.com or google for stdlib.h
and stdio.h

3.2.3 Defining the stack

Every task needs to have its own stack (This stack is different from the CPU
stack used for push pop during interrupts). Also the OS needs to know address

Real Time Operating System, Dr. V. B. Dharmadhikari

Sect. 3.2 Details of session outcomes 13

of the stack of each task. This is required because, the OS needs to save the
context of each task on to its own stack so as not to cause problem to other
tasks.
The stack is an area in the memory (RAM), with contiguous locations.
Therefore the stack is defined using arrays. If there are 3 tasks, there sould be
3 stacks (i.e.) 3 arrays. The Size of each array depends on the amount of data
that is pushed on to the stack. Usually it is kept to be 64 stack locations. The
size of each stack can be the same can also be different based on the need.

OS_STK TaskStk0 [TaskStkLengh]; //Define the Task stack

OS_STK TaskStk1 [TaskStkLengh]; //Define the Task stack
OS_STK TaskStk2 [TaskStkLengh]; //Define the Task stack

The data type of each element of the array is an integer. This can be viewed
clicking on the OS STK and clicking on go to definition.

3.2.4 Task function declarations

In the sample application code, after the stacked are defined, the task functions
are declared. This is required since the body of all task functions (definition)
appears after main function. Therefore, as per the C language systax require-
ment, there must be declaration of the task functions before main(). This is
requirement of C language and not the requirement of RTOS.

3.2.5 TargetInit() and OSInit() functions

The TargetInit() function initializes the timer0 which is used by the OS for
time tick. OSInit() function initializes many variables, structures required for
operation of the OS itself. Try commenting each function and simulate the
application. Observe the effect of commeting each of these functions.

3.2.6 Need of OSTaskCreate function

After the OSInit() function, there are functions which are used to create the
tasks. These are as follows:

OSTaskCreate (Task0,(void *)0, &TaskStk0[TaskStkLengh - 1], 6);

OSTaskCreate (Task1,(void *)0, &TaskStk1[TaskStkLengh - 1], 7);
OSTaskCreate (Task2,(void *)0, &TaskStk2[TaskStkLengh - 1], 8);

Here, three functions are shown. Each of these functions creates a task. So
here we create three tasks. The actual number of tasks to be created in an
application depend on the requirements of the application. For example, an
application may require ADC task, Relay task and Display task, whereas some

Real Time Operating System, Dr. V. B. Dharmadhikari

14 Detailed structure of an RTOS based application

other application may require Serial task, Keyboard task in addition to the
earlier tasks. Hence the number of tasks depend on the logic of the application.
We need to understand that, a task is written (in the C program) as a
C funtion. So it is written at the program development time (i.e.) body of
the task function is written during the development of the C program of the
application. Now, in an RTOS based application, it is not enough to just write
body of the task function, it is necessary to tell the RTOS, information of the
task. The reason for this is that, the task function is invoked by the RTOS
and NOT by the main() of the application. It means, there is no explicite call
to the task function from the main() program. This is because, we are using
RTOS and the RTOS is expected to schedule the execution of tasks properly.
Please note that, creating a task DOES NOT mean writing the C program
of the body of the task function. It is something different than that, which
we are going to understand. The body of the function is written while we
develop the application. It means we write it before compiling. However, the
OSTaskCreate function is executed during the execution of the application.
Hence, creating task happens at run-time and writing body of the task function
happens during development time.
Now lets understand if we have already written body of the task function,
why do we need to call the OSTaskCreate function? Lets understand this.
The primary function of the RTOS is to schedule the execution of tasks and
handove the control of CPU to appropriate task (actually the highest priority
ready task). If RTOS wants to run a task, then, the address of the task (from
ROM) needs to be loaded in PC (Program Counter) of CPU. For this, OS needs
to know the address of the task function. This address needs to be provided to
OS by the application writer. Along with the address of the task function, we
also need to provide information of stack address and priority to RTOS. For
providing this information, the OSTaskCreate function is called.

3.2.7 Argument 1: Task Address

Since the application is written in C language, we donot know the address of
the starting location of the task function. So, how to give address of the task
function to RTOS? There is a way for this. In C language, the name of a
function represents the starting address of that function. Therefore, if we wish
to pass the address of a task function to the RTOS, then that can be done
by passing the name of the task funtion. Therefore the first argument of the
OSTaskCreate funtion is the name of the task.

3.2.8 Argument 2: Task Parameter

A task is written in the form of C function. Such task function has facilty of
providing an argument (or information) to be used by the task. Note that, the

Real Time Operating System, Dr. V. B. Dharmadhikari

Sect. 3.3 Questions 15

task function is NEVER explicitely called from main(). This information is

passed by the application developer to the OS from the main function.
Since the type of information an aplication developer may want to pass to
task is not known to the OS writer, the OS writer has made provision to pass
any data type and any amount of data, by allowing void pointer to be passed.
With a pointer we can pass any amount of data and by passing void pointer
we can pass pointer that can point to any data type.

3.2.9 Argument 3: Task stack address

The next parameter is the task stack address. It is the address of the last
element of the array used as stack of the task. While creating a task, address
of its own stack address is passed as the third argument to OSTaskCreate
function.

3.2.10 Argument 4: Task priority

RTOS uses priority based task scheduling since it allowed the highest priority
ready task to be immediately served. Therefore the OS must know the priority
of each task. This information is provided by the application developer to
RTOS using 4th argument of the OSTaskCreate function. This argument is
an integer (0 to 58). Lower number indicates higher priority. (0 means highest
priority). The priority of each task should be set by the application developer
based on the needs of the application.
Need of OSStart() Return type and Pointer argument of task function Step-
wise execution of RTOS based application Creating task and deleting task
within a task Observing the effect of OSTimeDly on the execution sequence
of application Observing practically the Application running on a LPC2148
microcontroller kit

3.3 Questions
1. Explan the purpose of platform independent code of RTOS?
2. Why there are board specific files in RTOS based application?
3. How will you identify that a particular .c file is a board specific file?
4. The hex file of RTOS based application contains the code of application
along with RTOS (T/F).

Real Time Operating System, Dr. V. B. Dharmadhikari

References

[1] ecomputernotes.com. Os types. http://www.ecomputernotes.com.

[2] Informiit.com. Study history of operating systems. http://www.informit.

com.

[3] Wikipedia. Os definition. http://www.wikipedia.com.

Real Time Operating System, Dr. V. B. Dharmadhikari

Index

Inverting Apllifier, 1

Virtual Short, 1

Real Time Operating System, Dr. V. B. Dharmadhikari