MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Module 5
5.1 RTOS and IDE for Embedded System Design
Operational System Basics
• The operating system acts as a bridge between the user applications/tasks and the
underlying system resources through a set of system functionalities and services.
• The OS manages the system resources and makes them available to the user
applications/tasks on a need basis.
• A normal computing system is a collection of different I/O subsystems, working, and
storage memory.
• The primary functions of an operating system is
• Make the system convenient to use
• Organise and manage the system resources efficiently and correctly
• Figure 10.1 gives an insight into the basic components of an operating system and their
interfaces with rest of the world.

The Kernel

• The kernel is the core of the operating system and is responsible for managing the
system resources andthe communication among the hardware and other system
services.
• Kernel acts as the abstraction layerbetween system resources and user applications.
• Kernel contains a set of system libraries and services.
• For a general purpose OS, the kernel contains different services for handling the
following.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Process Management

• Process management deals with managing the processes/tasks.

• Process managementincludes setting up the memory space for the process, loading the
process’s code into the memoryspace, allocating system resources, scheduling and
managing the execution of the process, setting upand managing the Process Control
Block (PCB), Inter Process Communication and synchronisation,process
termination/deletion, etc.

Primary Memory Management

• The term primary memory refers to the volatile memory (RAM) where processes are
loaded and variables and shared data associated with each process are stored.
• The Memory Management Unit (MMU) of the kernel is responsible for
• Keeping track of which part of the memory area is currently used by which process
• Allocating and De-allocating memory space on a need basis (Dynamic memory
allocation).

File System Management

• File is a collection of related information.

• A file could be a program (source code or executable), text files, image files, word
documents, audio/video files, etc.
• Each of these files differ in the kind of information they hold and the way in which the
1TFLinformation is stored.
• The file operation is a useful service provided by the OS.
• The file system management service of Kernel is responsible for
• The creation, deletion and alteration of files
➢ Creation, deletion and alteration of directories
➢ Saving of files in the secondary storage memory (e.g. Hard disk storage)
➢ Providing automatic allocation of file space based on the amount of free space
available
➢ Providing a flexible naming convention. for the files
• The various file system management operations are OS dependent.
• For example, the kernel of Microsoft® DOS OS supports a specific set of file system
management operations and they are not the sameas the file system operations
supported by UNIX Kernel.
- I/O System (Device) Management Kernel is responsible for routing the I/O
requests coming fromdifferent user applications to the appropriate I/O devices
of the system.
• In a well-structured OS, thedirect accessing of I/O devices are not allowed and the
access to them are provided through a set ofApplication Programming Interfaces (APIs)
exposed by the kernel.
• The kernel maintains a list of allthe I/O devices of the system.
• This list may be available in advance, at the time of building the kernel.
• Some kernels, dynamically updates the list of available devices as and when a new
device is installed (e.g. Windows XP kernel keeps the list updated when a new plug ‘n’
play USB device is attached to the system).
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The service ‘Device Manager’ (Name may vary across different OS kernels) of the
kernel is responsible for handling all I/O device related operations.
• The kernel talks to the I/O device through a set of low-level systems calls, which are
implemented in a service, called device drivers.
• The device drivers are specific to a device or a class of devices.
• The Device Manager is responsible for
➢ Loading and unloading of device drivers
➢ Exchanging information and the system specific control signals to and
from the device

Secondary Storage Management

• The secondary storage management deals with managing the secondary storage
memory devices, if any, connected to the system.
• Secondary memory is used as backup medium for programs and data since the main
memory is volatile.
• In most of the systems, the secondary storage is kept in disks (Hard Disk).
• The secondary storage management service of kernel deals with
➢ Disk storage allocation
➢ Disk scheduling (Time interval at which the disk is activated to backup data)
➢ Free Disk space management
➢
Protection Systems

• Most of the modern operating systems are designed in such a way to support multiple
users with different levels of access permissions (e.g. Windows XP with user
permissions like
• ‘Administrator’, ‘Standard’, ‘Restricted’, etc.). Protection deals with implementing the
security policies to restrict the access to both user and system resources by different
applications or processes or users.
• In multiuser supported operating systems, one user may not be allowed to view or
modify the whole/portions of another user’s data or profile details.
• In addition, some application may not be granted with permission to make use of some
of the system resources.
• This kind of protection is provided by the protection services running within the kernel.
Interrupt Handler

• Kernel provides handler mechanism for all external/internal interrupts generated by the
system.
• These are some of the important services offered by the kernel of an operating system.
• It does not mean that a kernel contains no more than components/services explained
above.
• Depending on the type of the operating system, a kernel, may contain lesser number of
components/services or more number of components/services.
• In addition to the components/services listed above, many operating systems offer a
number of add-on system components/services to the kernel.
• Network communication, network management, user-interface graphics, timer services
(delays, timeouts, etc.), error handler, database management, etc. are examples for such
components/services.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Kernel exposes the interface to the variouskernel applications/services, hosted by

kernel, to the user applications through a set of standardApplication Programming
Interfaces (APIs).
• User applications can avail these API calls to access thevarious kernel
application/services.

Kernel Space and User Space

• The applications/services are Classified into two categories, namely: user applications
and keel applications.
• The program code corresponding to the kernel applications/services are kept in a
contiguous area (OS dependent) of primary (working) memory and is protected from
the un-authorised access by user programs/applications.
• The memory space at which the keel code is located is known as ‘Kernel Space’.
• Similarly, all user applications are loaded to a specific area of primary memory and this
memory area is referred as ‘User Space’.
• User space is the memory area where user applications are loaded and executed.
• The partitioning of memory into kernel. and user space is purely Operating System
dependent.
• Some OS implements this kind of partitioning and protection whereas some OS do not
segregate the kernel and user application code storage into two separate areas.
• In an operating system with virtual memory support, the user applications are loaded
into its corresponding virtual memory space with demand paging technique; Meaning,
the entire code for the user application need not be loaded to themain (primary) memory
at once; instead the user application code is split into different pages and these pages
are loaded into and out of the main memory area on a need basis.
• The act of loading the code into and out of the main memory is termed as ‘Swapping’.
• Swapping happens between the main (primary) memory and secondary storage
memory.
• Each process run in its own virtual memory space and are not allowed accessing the
memory space corresponding to another processes, unless explicitly requested by the
process.
• Each process will have certain privilege levels on accessing the memory of other
processesand based on the privilege settings, processes can request kernel-to map
another process’s memory to its own or share through some other mechanism.
• Most of the operating systems keep the kernel applicationcode in main memory and it
is not swapped out into the secondary memory.

Monolithic Kernel and Microkernel

• The kernel forms the heart of an operatingsystem.
• Different approaches are adopted for building an Operating System kernel.
• Based on thekernel design, kernels can be classified into ‘Monolithic’ and ‘Micro’
.
Monolithic Kernel

• In monolithic kernel architecture, all kernel services run in the kernel space.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Here all kernel modules run within the same memory space under a single kernel thread.
The tight internal integration of kernel modules in monolithic kernel architecture allows
the effective utilisation of thelow-level features of the underlying system.
• The major drawback of monolithic kernel is that any erroror failure in any one of the
kernel modules leads to the crashing of the entire kernel application.
• LINUX,SOLARIS, MS-DOS kernels are examples of monolithic kernel.
• The architecture representation of amonolithic kernel is given in Fig. 10.2.

Microkernel

• The microkernel design incorporates only the essential set of Operating System services
into the kernel.
• The rest of the Operating System services are implemented in programs known as
‘Servers’ which runs in user space.
• This provides a ‘highly modular design and OS-neutral abstraction to the kernel.
• Memory management, process management, timer systems and interrupt handlers are
the essential services, which forms the part of the microkernel.
• Mach, QNX, Minix 3 kernels are examples for microkernel.
• The architecture representation of a microkernel is shown in Fig. 10.3.
• Microkernel based design approach offers the following benefits

TYPES OF OPERATING SYSTEM

Operating Systems are classified into different types

General Purpose Operating System (GPOS)

MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The operating systems, which are deployed in general computing systems, are referred
as General Purpose Operating Systems (GPOS).
• The kernel of such an OS is more generalised and it contains all kinds of services
required for executing generic applications.
• General-purpose operating systems are often quite non-deterministic in behaviour.
Their services can inject random delays into application software and may cause slow
responsiveness of an application at unexpected times.
• GPOS are usually deployed in computing systems where deterministic behaviour is not
an important criterion.
• Personal Computer Desktop system is a typical example for a system where GPOSs are
deployed.
• Windows XP/MS-DOS TC etc. are examples for General Purpose Operating Systems.

Real-Time Operating System (RTOS)

• In a broad sense, ‘Real-Time’ implies deterministic timingbehaviour.

• Deterministic timing behaviour in RTOS context means the OS services consumes only
known and ap) expected amounts of time regardless the number of services.
• A Real-Time: Operating System or RTOS me implements policies’ and rules
concerning time-critical allocation of a system’s resources.
• The RTOS decides which applications should run in which order and how much time
needs to be allocated for each application.
• Windows CE, QNX, VxWorks MicroC/OS-II, etc. are examples of Real-Time
Operating Systems (RTOS).

The Real-Time Kernel

• The kernel of a Real-Time Operating System is referred as RealTime kernel.

• In complement to the conventional OS kernel, the Real-Time kernel is highly
specialised and it contains only the minimal set of services required for running the user
applications/tasks.

The basic functions of a Real-Time kernel are listed below:

➢ Task/Process management
➢ Task/Process scheduling
➢ Task/Process synchronisation
➢ Error/Exception handling
➢ Memory management
➢ Interrupt handling
➢ Time management

Task/Process management
• Deals with setting up the memory space for the tasks, loading the task’s code into the
memory space, allocating system resources, setting up a Task Control Block (TCB) for
the task and task/process termination/deletion.
• A Task Control Block (TCB) is used for holding the information correspondingto a
task.
• TCB usually contains the following set of information.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

➢ Task ID: Task Identification Number

➢ Task State: The current state of the task (e.g. State = ‘Ready’ for a task
which is ready to execute)
➢ Task Type: Task typeIndicates what is the type for this task. The task
can be a hard real time or soft real time or background task.
➢ Task Priority: Task priority (e.g. Task priority = 1 for task with priority
= 1)
➢ Task Context Pointer: Context pointer-Pointer for context saving
➢ Task Memory Pointers: Pointers to the code memory, data memory and
stack memory for the task
➢ Task System Resource Pointers: Pointers to system resources
(semaphores, mutex, etc.) used by the task
➢ Task Pointers: Pointers to other TCBs (TCBs for preceding, next and
waiting tasks)
Other Parameters Other relevant taskparameters
• The parameters and implementation of the TCB is kernel dependent.
• The TCB parameters vary across different kernels, based on the task management
implementation.
• Task management service utilises the TCB of a task in the following way
• Creates a TCB for a task on creating a task
• Delete/remove the TCB of a task when the task is terminated or deleted
• Reads the TCB to get the state of a task
• Update the TCB with updated parameters on need basis (e.g. on a context switch)
• Modify the TCB to change the priority of the task dynamically
Task/Process Scheduling
• Deals with sharing the PU among various tasks/processes.
• A kernel application called ‘Scheduler’ handles the task scheduling.
• Scheduler is nothing but an algorithm implementation, which performs the efficient and
optimal scheduling of tasks to provide a deterministic behaviour.
Task/Process Synchronisation
• Deals with synchronising the concurrent access of a resource, which is shared across
multiple tasks and the communication between various tasks.
Error/Exception Handling
• Deals with registering and handling the errors occurred/exceptions raised during the
execution of tasks.
• Insufficient memory, timeouts, deadlocks, deadline missing, bus error, divide by zero,
unknown instruction execution, etc. are examples of errors/exceptions.
Errors/Exceptions can happen at the kernel level services or at task level.
• Deadlock is an example for kernel level exception, whereas timeout is an example for
a task level exception.
• The OS kernel gives the information about the error in the form of a system call (API).
• GetLastError() API provided by Windows CE RTOS is an example for such a system
call.
• Watchdog timer is a mechanism for handling the timeouts for tasks.
• Certain tasks may involve the waiting of external events from devices.
• These tasks will wait infinitely when the external device is not responding and the task
will generate a hang-up behaviour.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• In order to avoid these types of scenarios, a proper timeout mechanism should be

implemented.
• A watch- dog is normally used in such situations.
• The watchdog will be loaded with the maximum expected wait time for the event and
if the event is not triggered within this wait time, the same is informed to the task and
the task is timed out.
• If the event happens before the timeout, the watchdog is resetted.
Memory Management
• Compared to the General Purpose Operating Systems, the memory management
function of an RTOS kernel is slightly different.
• In general, the memory allocation time increases depending on the size of the block of
memory needs to be allocated and the state of the allocated memory block
• Since predictable timing and deterministic behaviour are the primary focus of an RTOS,
RTOS achieves this by compromising the effectiveness of memory allocation.
• RTOS makes use of block’ based memory allocation technique, instead of the usual
dynamic memory allocation techniques used by the GPOS_RTOS kernel uses blocks
of fixed size of dynamic memory and the block is allocated for a task on a feed basis.
• The blocks are stored in a ‘Free Buffer Queue’.
• To achieve predictable timing and avoid the timing overheads, most of the RTOS
kernels allow tasks to access any of the memory blocks without any memory protection.
• RTOS kernels assume that the whole design is proven correct and protection is
unnecessary. Some commercial RTOS kernels allow memory protection as optional
and the kernel enters a fail-safe mode when an illegal memory access occurs.
Interrupt Handling
Deals with the handling of various types of interrupts. Interrupts provide Real- Time behaviour
to systems. Interrupts inform the processor that an external device or an associated task requires
immediate attention of the CPU. Interrupts can be either Synchronous or Asynchronous.
Interrupts which occurs in syne with the currently executing task is known as Synchronous
interrupts. Usually the software interrupts fall under the Synchronous Interrupt category.
Divide by zero, memory segmentation error, etc. are examples of synchronous interrupts. For
synchronous interrupts, the interrupt handler runs in the same context of the interrupting task
.Asynchronous. interrupts are interrupts, which occurs at any point of execution of any task,
and are not in sync with the currently executing task.
The interrupts generated by external devices (by asserting the interrupt line of the
processor/controller to which the interrupt line of the device is connected) connected to the
processor/controller, timer overflow interrupts, serial data reception/ transmission interrupts,
etc. are examples for asynchronous interrupts. For asynchronous interrupts, the interrupt
handler is usually written as separate task (Depends onOS kernel implementation) and it runs
in a different context. Hence, a context switch happens while handling the asynchronous
interrupts.
Priority levels can be assigned to the interrupts and each interrupts can be enabled or disabled
individually. Most of the RTOS kernel implements ‘Nested Interrupts’ architecture. Interrupt
nesting allows pre-emption (interruption) of an Interrupt Service Routine (ISR), servicing an
interrupt, by a high priority interrupt.
Time Management

Accurate time management is essential for providing precise time reference for all applications.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

The time reference to kernel is provided by a high-resolution Real-Time Clock (RTC) hardware
chip (hardware timer).

The hardware timer isprogrammed to interrupt the processorcontroller at a fixed rate.

This timer interrupt is referred as ‘Timer tick’.

The ‘Timer tick’ is taken as the timing reference by the kernel.

The ‘Timer tick’ interval may vary depending on the hardware timer.

Usually the ‘Timer tick’ varies in the microseconds range.

The time parameters for tasks are expressed as the multiples of the ‘Timer tick’.

The System time is updated based on the ‘Timer tick’.

If the System time register is 32 bits wide and the ‘Timer tick’ interval is 1 microsecond, the
System time register will reset in 232 * 10-8/ (24 * 60 * 60) = 49700 Days = ~ 0.0497 Days =
1.19 Hours If the ‘Timer tick’ interval is | millisecond, the system time register will reset in
232 * 10°3 / (24 * 60 * 60) = 497 Days = 49.7 Days = ~ 50 Days The ‘Timer tick’ interrupt is
handled by the “Timer Interrupt’ handler of kernel.
The ‘Timer tick’ interrupt can be utilised for implementing the following actions.

➢ Save the current context (Context of the currently executing task).

➢ Increment the System time register by one.
➢ Generate timing error and reset the System time register if the timer tick count is greater
than the maximum range available for System time register.
➢ Update the timers implemented in kernel (Increment or decrement the timer registers
for each timer depending on the count direction setting for each register.
➢ Increment registers with count direction setting = ‘count up’ and decrement registers
with count direction setting = ‘count down’).
➢ Activate the periodic tasks, which are in the idle state.
➢ Invoke the scheduler and schedule the tasks again based on the scheduling algorithm.
➢ Delete all the terminated tasks and their associated data structures(TCBs)
➢ Load the context for the first task in the ready queue.
➢ Due to rescheduling the ready task might be changed to a new one from the task which
was preemptedby the “Timer interrupt” task.

Hard Real-Time
• Real-Time Operating Systems that strictly adhere to the timing constraints for a task is
referred as ‘Hard Real-Time’ systems.
• A HardReal-Time system must meet the deadlines for a task without any slippage.
• Missing any deadline may produce catastrophic results for Hard Real-Time Systems,
including permanent data lose and irrecoverable damages to the system/users.
• A system can have several such tasks and the key to their correct operation lies in
scheduling them so that they meet their time constraints.
• Air bag control systems and Anti-lock Brake Systems (ABS) of vehicles are typical
examples for Hard Real-Time Systems.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The Air bag control system should be into action and deploy the air bags when the
vehicle meets a severe accident. Ideally speaking, the time for triggering the air bag
deployment task, when an accident is sensed by the Air bag control system, should be
zero and the air bags should be deployed exactly within the time frame, which is
predefined for the air bag deployment task.
Soft Real-Time
• Real-Time Operating System that does not guarantee meeting deadlines, but offer the
best effort to meet the deadline are referred as ‘Soft Real-Time’ systems.
• Missing deadlines for tasks are acceptable for a Soft Real-time system if the frequency
of deadline missing is within the compliance limit of the Quality of Service (QoS).
• Automatic Teller Machine (ATM) is a typical example for Soft- Real-Time System.
• If the ATM takes a few seconds more than the ideal operation time, nothing fatal
happens.
• An audio-video playback system is another example for Soft Real-Time system.
• No potential damage arises if a sample comes late by fraction of a second, for playback.

TASKS, PROCESS AND THREADS

The term ‘task’ refers to something that needs to be done. In our day-to-day life, we are bound
to the execution of a number of tasks. The task can be the one assigned by our managers or the
one assigned by our professors/teachers or the one related to our personal or family needs. In
addition, we will have an order of priority and schedule/timeline for executing these tasks.
In the operating system context, a task is defined as the program in execution and thé related
information maintained by the operating systemfor the program. Task is also known as ‘Job’
in the operating system context. A program or part of it in execution is also called a ‘Process’.
The terms ‘Task’, ‘Job’ and ‘Process’ refer to the same entity in the operating system context
and most often they are used interchangeably.
Process
• A ‘Process’ is a program, or part of it, in execution.
• Process’is also known as an instance of a program in execution.
• Multiple instances of the same program can execute simultaneously.
• A process requires various system resources like CPU for executing the process;
memory for storing the code corresponding to the process and associated variables, I/O
devices for information exchange, etc. A process is sequential in execution.
The Structure of a Process
• The concept of ‘Process’ leads to concurrent execution (pseudo parallelism) of tasks
and thereby the efficient utilisation of the CPU and other system resources.
• Concurrent execution is achieved through the sharing of CPU among the processes.
• A process mimics a processor in properties and holds a set of registers, process status,
a Program Counter (PC) to point to the next executable instruction of the process, a
stack for holding the local variables associated with the process and the code
corresponding to the process.
• This can be visualised as shown in Fig. 10.4.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

A process which inherits all-the properties of the CPU can be considered as a virtual processor,
awaiting its turn to have its properties switched into the physical processor. When the process
gets its turn, its registers arid the program counter register becomes mapped to the physical
registers of the CPU. From a memory perspective, the memory occupied by the process is
segregated into three regions, namely, Stack memory, Data memory and Code memory (Fig.
10.5).

The ‘Stack’ memory holds all temporary data such as variables local to the process. Data
memory holds all global data for the process. The code memory contains the program code
(instructions) corresponding to the process. On loading a process into the main memory, a
specific area of memory is allocated for the process. The stack memory usually starts (OS
Kermel implementation dependent) at the highest memory address from the memory area
allocated for the process. Say for example, the memory map of the memory area allocated for
the process is 2048 to 2100, the stack memory starts at address 2100 and grows downwards to
accommodate the variables local to the process.
Process States and State Transition
• The creation of a process to its termination is not a single step operation.
• The process traverses through a series of states during its transition from the newly
created state to the terminated state.
• The cycle through which a process changes its state from “newly created’ to ‘execution
completed’ is known as ‘Process Life Cycle’.
• The various states through which a process traverses through during a Process Life .
• Cycle indicates the current status of the process with respect to time and also provides
information on what it is allowed to do next.
• Figure 10.6 represents the various states associated with a process.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

The state at which a process is being created is referred as ‘Created State’. The Operating
System recognises a process in the ‘Created State’ but no resources are allocated to the process.
The state, where a process is incepted into the memory and awaiting the processor time for
execution, is known as ‘Ready State’. At this stage, the process is placed in the ‘Ready list?
queue maintained by the OS. The state where in the source code instructions corresponding to
the process is being executed is called ‘Running State’. Running state is the state at which the
process execution happens. ‘Blocked State/Wait State’ refers to a state where a running
process is temporarily suspended from execution and does not have immediate access to
resources. The blocked state might be invoked by various conditions like: the process enters a
wait state for an event to occur (e.g. Waiting for user inputs such as keyboard input) or waiting
for getting access to a shared resource A state where the process completes its execution is
known as ‘Completed State’. The transition of a process from one state to another is known
as ‘State transition’. When a process changes its state from Ready to running or from running
to blocked or terminated or from blocked to running, the CPU allocation for the process may
also change.

Process Management

Process management deals with the creation of a process, setting up the memory space for the
process, loading the process’s code into the memory space, allocating system resources, setting
up a Process Control Block (PCB) for the process and process termination/deletion.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

THREADS
• A thread is the primitive that can execute code.
• A thread is a single sequential flow of control within a process.
• ‘Thread’ is also known as light- weight process. A process can have many threads of
execution.
• Different threads, which are part of a process, share the same address space; meaning .
they share the data memory, code memory and heap memory area.
• Threads maintain their own thread status (CPU register values), Program Counter (PC)
and stack.

The Concept of Multithreading

• A process/task in embedded application may be a complex or lengthy one and it may

contain various suboperations like getting input from I/O devices connected tothe
processor, performing some internal calculations/operations, updating some I/O
devices etc.
• If all the subfunctions of a task are executed in sequence, the CPU utilisation may not
be efficient.
• For example, if the process is waiting for a user input, the CPU enters the wait state for
the event, and the process execution also enters a wait state.
• Instead of this single sequential execution of the whole process, if the task/process is
split into different threads carrying out the different subfunctionalities of the process,
the CPU can be effectively utilised and when the thread corresponding to the I/O
operation enters the wait state, another threads which do not require the I/O event for
their operation can be switched into execution.
• This leads to morespeedy ‘execution of the process and the efficient utilisation of the
processor timeand resources.
• The. multithreaded atchitecture of a process can be better visualised with the thread-
process diagram shown in Fig. 10, 8.)
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• If the process is split into multiple threads, which executes a portion of the process,
there will be a main thread and rest of the threads will be created within the main thread.
• Use of multiple threads to execute a process brings the following advantage.
➢ Better memory utilisation. Multiple threads of the same process share the
address space for data memory. This also reduces the complexity of inter thread
communication since variables can be shared across the threads.
➢ Since the process is split into different threads, when one thread enters a wait
state, the CPU can be utilised by other threads of the process that do not require
the event, which the other thread is waiting, for processing. This speeds up the
execution of the process. e
➢ Efficient CPU utilisation. The CPU is engaged all time.

Thread Standards

• Thread standards deal with the different standards available for thread creation and
management.
• These standards are utilised by the operating systems for thread creation and thread
management.
• It is a set of thread class libraries. The commonly available thread class libraries are
explained below

POSIX Threads: POSIX stands for Portable Operating System Interface.

The POSIX 4 standard deals with the Real-Time extensions and POSLX.4a standard deals with
thread extensions. The POSIX standard library for thread creation and management is
‘Pthreads’. ‘Pthreads’ library defines the set of POSIX thread creation and management
functions in ‘C’ language.

The primitive
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

creates a new thread. for running the function start_ function. Here pthread _t is the handle to
the newly created thread and pthread_attr_t is the data type for holding the thread attributes.
‘start_function’ is the function the thread is going to execute and arguments is the arguments
for ‘start_function’ (It is a void * in the above example). On successful creation of a Pthread,
pthread_create() associates the Thread Control Block (TCB) corresponding to the newly
created thread to the variable of type pthread_t (new_thread_ID in our example).

The primitive

blocks the current thread and waits until the completion of the thread pointed’ by it (in this
example new_thread ) All the POSIX ‘thread calls’ returns an integer. A return value of zero
indicates the success of the call. It is always good to check the return value of each call.
Forced termination can be achieved by the call pthread _cancel() or through the termination of
the main thread with exit or exec functions. pthread_cancel() call is used by a thread to
terminate another thread. pthread _exit() call is used by a thread to explicitly exit after it
completes its work and is no longer required to exist.

THREAD PRE-EMPTION
• Thread Pre-emption is the act of pre-empting the currently running thread.
• Thread Pre-emption ability is solely dependent on the Operating System.
• Thread Pre-emption is performed for sharing a CPU time among the threads.
• The execution switching among the threads is known as “Thread Context Switching”
User Level Thread
• User level threads do not have kernel/Operating System support and they exist solely
in the running process.
• Even if a process contains multiple user level threads, the OS treats it as single thread
and will not switch the execution among the different threads of it.
• It is the responsibility of the process to schedule each thread as and when required.
• In summary, user level threads of a process are non-preemptive at thread level from OS
perspective.
Kernel/System Level Thread
• Kernel level threads are individual units of execution, which the OS treats as separate
threads.
• The OS interrupts the execution of the currently running kernel thread and switches the
execution to another kernel thread based on the scheduling policies implemented by the
OS. Kernel level threads are pre-emptive.
• For user level threads, the execution switching (thread context switching) happens only
when the currently executing user level thread is voluntarily blocked.
• Hence, no OS intervention and system calls are involved in the context switching of
user level threads.
• This makes context switching of user level threads very fast.
• On the other hand, kernel level threads involve lots of kernel overhead and involve
system calls for context switching. However, kernel threads maintain a clear layer of
abstraction and allow threads to use system calls independently.
• There are many ways for binding user level threads with system/kernel level threads.
• The following section gives an overview of various thread binding models.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Many-to-One Model

• Many user level threads are mapped to a single kernel thread.

• In this model, the kernel treats all user level threads as single thread and the execution
switching among the user level threads happens when a currently executing user level
thread voluntarily blocks itself or relinquishes the CPU.
• Solaris Green threads and GNU Portable Threads are examples for this.
• The ‘PThread” example given under the POSIX thread library section is an illustrative
example for application with Many-to-One thread model.

One-to-One Model

• In One-to-One model, each user level thread is bonded to a kernel/system level thread.
Windows XP/NT/2000 and Linux threads are examples for One-to-One thread models.
• The modified ‘PThread’ example given under the ‘Thread Pre-emption’ section is an
illustrative example for application with One-to-One thread model.

Many-to-Many Model

• In this model many user level threads are allowed to be mapped-to many kernel threads.
• Windows NT/2000 with ThreadFibre package is an example for this.

Thread Vs Process

MULTIPROCESSING AND MULTITASKING

In the operating system context multiprocessing describes the ability to execute multiple
processes simultaneously. Systems which are capable of performing multiprocessing,
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

are.known as multiprocessorsystems. Multiprocessor systems possess multiple CPUs and can

execute multiple processes simultaneously. The ability of the operating system to have multiple
programs in memory, which are ready for execution, is referred as multiprogramming. In a
uniprocessor system, it is not possible to execute multiple processes simultaneously. However,
it is possible for a uniprocessor system to achieve some degree of pseudo parallelism in the
execution of multiple processés by switching the execution among different processes.
The ability of an operating system to hold multiple processes in memory and switch the
processor (CPU) from executing one process to another process is known as multitasking.
Multitasking creates the illusion of multiple tasks executing in parallel. Multitasking involves
the switching of CPU from executing one task to another. A ‘process’ is considered as a
‘Virtual processor’, awaiting its turn.to have its properties switched into the physical
processor. In a multitasking environment, when task/process switching happens, the virtual
processor (task/process) gets its properties converted into that of the physical processor. The
switching of the virtual processor to physical processor is controlled by the scheduler of the
OS kernel.
Whenever a CPU switching happens, the current context of execution should be saved to
retrieve it at a later point of time when the CPU executes the process, which is interrupted
currently due to execution switching.The context saving and retrieval is essential for resuming
a process exactly from the point where it was interrupted due to CPU switching. The act of
switching CPU among the processes or changing the current execution context is known as
‘Context switching’. The act of saving the current context which contains the context details
(Register details, memory details, system resource usage details, execution details, etc.) for the
currently running process at the time of CPU switching is known as ‘Context saving’. The
process of retrieving the saved context details for a process, which is going to be executed due
to CPU switching, is known as ‘Context retrieval’.
Multitasking involves ‘Context switching’ (Fig. 10.11), “Context saving’ and ‘Context
retrieval’.

TYPES OF MULTITASKING

Depending on how the switching act is implemented, multitasking can be classified into
different types. The following section describes the various types of multitasking existing in
the Operating System’s context.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Co-operative Multitasking
Co-operative multitasking is the most primitive form of multitasking in which a task/process
gets a chance to execute only when the currently executing task/ process voluntarily
relinquishes the CPU. In this method, any task/process can hold the CPU as much time as it
wants. Since this type of implementation involves the mercy of the tasks each other for getting
the CPU time for execution, it is known as co-operative multitasking. If the currently executing
task is non-cooperative, the other tasks may have to wait for a long time to get the CPU. ”
Preemptive Multitasking
Preemptive multitasking ensures that every task/process gets a chance to execute. When and
how much time a process gets is dependent on the implementation of the preemptive
scheduling. As the name indicates, in preemptive multitasking, the currently running task/
process is preempted to give a chance to other tasks/process to executé. The preemption of task
may be based on time slots or task/process priority.
Non-preemptiveMultitasking.
In non-preemptivemultitasking, the process/task, which is currently giventheCPU time, is
allowedto execute until itterminates (enters the ‘Completed’ state) or enters the ‘Blocked/Wait’
state, waiting foran I/O or system resource. The co-operative and non-preemptive multitasking
differs in their behaviour when they arein the ‘Blocked/Wait state. In co-operative
multitasking, the currently executing process/task need not relinquish the CPU when it enters
the ‘Blocked/Wait’ state

TASK COMMUNICATION

In a multitasking system, multiple tasks/processes run concurrently (in pseudo parallelism) and
each process may or may not interact between.
Based on the degree of interaction, the processes running on an OS are classified as
Co-operating Processes: In the co-operating interaction model one process requires the inputs
from other processes to complete its execution.
Competing Processes: The competing processes do not share anything among themselves but
they share the system resources. The competing processes compete for the system resources
such as file, display device, etc. Co-operating processes exchanges information and
communicate through the following methods.
Co-operation through Sharing: The co-operating process exchange data through some shared
resources.
Co-operation through Communication: No data is shared between the processes. But they
communicate for synchronisation. The mechanism through which processes/tasks
communicate each other is known as Inter Process/Task Communication (IPC). Inter
Process Communication is essential for process co-ordination. The various types of Inter
Process Communication (IPC) mechanisms adopted by process are kernel (Operating System)
dependent. Some of the important IPC mechanisms adopted by various kernels are explained
below.

Shared Memory

• Processes share some area of the memory to communicate among them (Fig. 10.16).
Information to be communicated by the process is written to the shared memory area.
• Other processes which require this information can read the same from the shared
memory area.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• It is same as the realworld example where ‘Notice Board’ is used by corporate to

publish the public information among the employees.
• The implementation of shared memory concept is kernel dependent.
• Different mechanisms are adopted by different kernels for implementing this. A few
among them are:

Pipes

• ‘Pipe’ is asection of the shared memory used by processes for communicating.

• Pipes follow the client-server architecture.
• A process which creates a pipe is known as a pipe server and a process which connects
to a pipe is known as pipe client.
• A pipe can be considered as a conduit for information flow and has two conceptual
ends.
• It can be unidirectional, allowing information flow in one direction or bidirectional
allowing bi-directional information flow.
• A unidirectional pipe allows the process connecting at one end of the pipe to write to
the pipe and the process connected at the other end of the pipe to read the data, whereas
a bi-directional pipe allows both reading and writing at one end.
• The unidirectional pipe can be visualised as

The implementation of ‘Pipes’ is also OS dependent. Microsoft® Windows Desktop Operating

Systems support two types of ‘Pipes’ for Inter Process Communication. They are:
Anonymous Pipes: The anonymous pipes-are unnamed, unidirectional pipes used for data
transfer between two processes.
Named Pipes: Named pipe is a named, unidirectional or bi-directional pipe for data exchange
between processes.

Like anonymous pipes, the process which creates the named pipe is known as pipe server. A
process which connects to the named pipe is known as pipe client. With named pipes, any
process can act as both client and server allowing point-to-point communication. Named pipes
can be used for communicating between processes running on the same machine or between
processes running on different machines connected to a network.
Memory Mapped Objects
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Memory mapped object is a shared memory technique adopted by certain Real-Time Operating
Systems for allocating a shared block of memory which can be accessed by multiple process
simultaneously. In this approach a mapping object is created and physical storage for it is
reserved and committed. A process can map the entire committed physical area or a block of it
to its virtual address space. All read and write operation to this virtual address space by a
process is directed to its committed physical area. Any process which wants to share data with
other processes can map the physical memory area of the mapped object to its virtual memory
space and use it for sharing the data.
The memory mapped object can be shared between the processes by either passing the handle
of the object or by passing its name. If the handle of the memory mapped object created by a
process is passed to another process for shared access, there is a possibility of closing the handle
by the process which created the handle while it is in use by another process.
This will throw OS level exceptions.
If the name of the memory object is passed for shared access among processes, processes can
use this name for creating a shared memory object which will open the shared memory object
already existing with the given name.

The OS will maintain ausage count for the named object and it is incremented each time when
a process creates/opens a memory mapped object with existing name. This will prevent the
destruction of a shared memory object by one process while it is being accessed by another
process.

Hence passing the name of the memory mapped object is strongly recommended for memory
mapped object based inter process communication.
Message Passing
• Message passing is an (a)synchronous information exchange mechanism used for Inter
Process/Thread Communication.
• The major difference between shared memory and messagelimited amount of info/data
is passed through message passing.
• Also message passing is relatively fast and free from the synchronisation overheads
compared to shared memory.
• Based on the message passing operation between the processes, message passing is
classified into
Message Queue
Usually the process which wants to talk to another process posts the message to a First-In-First-
Out (FIFO) queue called ‘Message queue’, which stores the messages temporarily in a system
defined memory object, to pass it to the desired process (Fig. 10.20). Messages are sent and
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

received through send (Name of the process to which the message is to bé sent-message) and
receive (Name of the process from which the message is to be received, message) méthods.
The messages are exchanged through a message queue. The implementation of the message
queue, send and receive methods are OS kernel dependent. The Windows XP OS kernel
maintains a single system message queue and one process/thread (Process and threads are used
interchangeably here, since thread is the basic unit of process in windows) specific message
queue.
A thread which wants to communicate with another thread posts the message to the system
message queue. The kernel picks up the message from the system message queue one at a time
and examines the message for finding the destination thread and then posts the message to the
message queue of the corresponding thread. For posting a message to a thread’s message queue,
the kernel fills a message structure MSG and copies it to the message queue of the thread. The
message structure MSG contains the handle of the process/thread for which the message is
intended, the message parameters, the time at which the message is posted, etc. A thread can
simply post a message to another thread and can continue its operation or it may wait for a
response from the thread to which the message is posted. The messaging mechanism is
classified into synchronous and asynchronous based on the behaviour of the message posting
thread. In asynchronous messaging, the message posting thread just posts the message to the
queue and it will not wait for an acceptance (return) from the thread to which the message is
posted, whereas in synchronous messaging, the thread which posts a message enters waiting
state and waits for the message result from the thread to which the message is posted. The
thread which invoked the send message becomes blocked and the scheduler will not pick it up
for scheduling.

Mailbox
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Mailbox is an alternate form of ‘Message queues’ and it is used in certain Real- Time
Operating Systems for IPC.
• Mailbox technique for IPC in RTOS is usually used for one way messaging.
• The task/thread which wants to send a message to other tasks/threads creates a mailbox
for posting the messages.
• The threads which are interested in receiving the messages posted to the mailbox by the
mailbox creator thread can subscribe to the mailbox.
• The thread which creates the mailbox is known as ‘mailbox server’ and the threads
which subscribe to the mailbox are known as ‘mailbox clients’.
• The mailbox server posts messages to the mailbox and notifies it to the clients which
are subscribed to the mailbox.
• The clients read the message from the mailbox on receiving the notification.
• The mailbox creation, subscription, message reading and writing are achieved through
OS kernel provided API calls, Mailbox and message queues are same in functionality.
• The only difference is in the number of messages supported by them.
• Both of them are used for passing data in the form of message(s) from a task to another
task(s). Mailbox is used for exchanging a single message between two tasks or between
an Interrupt Service Routine (ISR) and a task.
• Mailbox associates a pointer pointing to the mailbox and a wait list to hold the tasks
waiting for a message to appear in the mailbox.
• The implementation of mailbox is OS kernel dependent.
• The MicroC/OS-II implements mailbox as a mechanism for inter-task communication.
• Figure 10.21 given below illustrates the mailbox based IPC technique

Signalling

• Signalling is a primitive way of communication between processes/threads.

• Signals are used for asynchronous notifications where one process/thread fires a signal,
indicating the occurrence of a scenario which the other process(es)/thread(s) is waiting.
• Signals are not queued and they do not carry any data.
• The communication mechanisms used in RTX51 Tiny OS is an example for Signalling.
• The os_send_signal kernel call under RTX 51 sends a signal from one task to a specified
task. Similarly the os_wait kernel call waits for a specified signal.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The VxWorks RTOS kernel also implements “signals’ for inter process
communication. Whenever a specified signal occurs it is handled in a signal handler
associated with the signal.

Remote Procedure Call (RPC) and Sockets

• Remote Procedure Call or RPC (Fig. 10.22) is the Inter Process Communication (IPC)
mechanism used by a process to call a procedure of another process running on the
same CPU or on a different CPU which is interconnected in a network.
• In the object oriented language terminology RPC is also known as Remote Invocation
or Remote Method Invocation (RMI).
• RPC is mainly used for distributed applications like client-server applications.
• With RPC it is possible to communicate over a heterogeneous network (i.e. Network
where Client and server applications are running on different Operating systems), The
CPU/process containing the procedure which needs to be invoked remotely is known
as server.
• The CPU/process which initiates an RPC request is known as client.

• It is possible to implement RPC communication with different invocation interfaces.

• In order to make the RPC communication compatible across all platforms it should stick
on to certain standard formats.
• Interface Definition Language (IDL) defines the interfaces for RPC. Microsoft
Interface Definition Language (MIDL) is the IDL implementation from Microsoft for
all Microsoft platforms.
• The RPC communication can be either Synchronous (Blocking) or Asynchronous
(Non-blocking).
• In the Synchronous communication, the process which calls the remote procedure is
blocked until it receives a response back from the other process.
• In asynchronous RPC calls, the calling process continues its execution while the remote
process performs the execution of the procedure.
• The result from the remote procedure is returned back to the caller through mechanisms
like callback functions.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• On security front, RPC employs authentication mechanisms to protect the systems

against vulnerabilities.
• The client applications (processes) should authenticate themselves with the server for
getting access.
• Authentication mechanisms like IDs, public key cryptography (like DES, 3DES), etc.
are used by the client for authentication.
• Without authentication, any client can access the remote procedure.
• This may lead to potential security risks. Sockets are used for RPC communication.
• Socket is a logical endpoint in a two-way communication link between two applications
running on a network.
• A port number is associated with a socket so that the network layer of the
communication channel can deliver the data to the designated application.
• Sockets are of different types, namely, Internet sockets (INET), UNIX sockets, etc.
• The INET socket works on internet communication protocol.
• TCP/IP, UDP, etc. are the communication protocols used by INET sockets. INET
sockets are classified into:
1. Stream sockets
2. Datagram sockets
• Stream sockets are connection oriented and they use TCP to establish a reliable
connection. On the other hand, Datagram sockets rely on UDP for establishing a
connection.
• The UDP connection is unreliable when compared to TCP.
• The client-server communication model uses a socket at the client side and a socket at
the server side.
• A port number is assigned to both of these sockets.
• The client and server should be aware of the port number associated with the socket.
• In order to start the communication, the client needs to send a connection request to the
server at the specified port number.
• The client should be aware of the name of the server along with its port number.
• The server always listens to the specified port number on the network. Upon receiving
a connection request from the client, based on the success of authentication, the server
grants the connection request and a communication channel is established between the
client and server. The client uses the host name and port number of server for sending
re- quests and server uses the client’s name and port number for sending responses.

TASK SYNCHRONISATION

• In a multitasking environment, multiple processes run concurrently (in pseudo

parallelism) and share the system resources.
• Apart from this, each process has its own boundary wall and they communicate with
each other with different [PC mechanisms including shared memory and variables.
• Imagine a situation where two processes try to access display hardware connected to
the system or two processes try to access a shared memory area where one process tries
to write to a memory location when the other process is trying to read from this.
• The act of making processes aware of the access of the shared resources by each process
to avoid conflicts is known as Task/Process Synchronisation.

Task Communication/Synchronisation Issues

MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Racing

• The program statement counter++; looks like a single statement from a high level
programming language (‘C’ language) perspective.
• The low level implementation of this statement is dependent on the underlying
processor instruction set and the (cross) compiler in use.
• The low level implementation of the high level program statement counter++,; under
Windows XP op- erating system running on an Intel Centrino Duo processor is given
below. The code snippet is compiled with Microsoft Visual Studio 6.0 compiler.

• At the processor instruction level, the value of the variable counter is loaded to the
Accumulator register (EAX register).
• The memory variable counter is represented using a pointer.
• The base pointer register (EBP register) is used for pointing to the memory variable
counter. After loading the contents of the variable‘counter to the Accumulator, the
Accumulator content is incremented by one using the add instruction.
• Finally the content of Accumulator is loaded to the memory location which repre- sents
the variable counter.
• Both the processes Process A and Process B contain the program statement counter++;
Translating this into the machine instruction.

• Imagine a situation where a process switching (context switching) happens from

Process A to Process B when Process A is executing the counter++; statement.
• Process A accomplishes the counter+ +; statement through three different low level
instructions.
• Now imagine that the process switching happened at the point where Process A
executed the low level instruction, ‘mov eax,dwordptr [ebp-4]’ and is about to execute
the next instruction ‘add eax,1’.
• The scenario is illustrated in Fig. 10.23. Process B increments the shared variable
‘counter’ in the middle of the operation where Process A tries to increment it.
• When Process A gets the CPU time for execution, it starts from the point where it got
interrupted (If Process B is also using the same registers eax and ebp for executing
counter++;
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

instruction, the original content of these registers will be saved as part of the context saving
and it will be retrieved back as part of context retrieval, when process A gets the CPU for
execution.
• Hence the content of eax and ebp remains intact irrespective of context switching).
• Though the variable counter is incremented by Process B, Process A is unaware of it
and it increments the variable with the old value.
• This leads to the loss of one increment for the variable counter.
• This problem occurs due to non-atomict operation on variables.
• This issue wouldn’t have been occurred if the underlying actions corresponding to the
program statement counter++; is finished in a single CPU execution cycle.
• The best way to avoid this situation is make the access and modification of shared
variables mutually exclusive; meaning when one process accesses a shared variable,
prevent the other processes from accessing it.
To summarise, Racing or Race condition is the situation in which multiple processes compete
(race) each other to access and manipulate shared data concurrently. In a Race condition the
final value of the shared data depends on the process which acted on the data finally.
Deadlock
A race condition produces incorrect results whereas a deadlock condition creates a situation
where none of the processes are able to make any progress in their execution resulting in a set
of deadlock processes.
A situation similar to traffic jam issues is illustrated below
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

In its simplest form ‘deadlock’ is the condition in which a process is waiting for a resource
held by another process which is wait- ing for a resource held by the first process (Fig. 10.25).
To elaborate: Process A holds a resource x and it wants a resource y held by Process B. Process
B is currently holding resource y and it wants the resource x which is currently held by Process
A. Both hold the respective resources and they compete each other to get the resource held by
the respective processes. The result of the competition is ‘deadlock’.
None of the competing process will be able to access the resources held by other processes
since they are locked by the respective processes (If a mutual exclusion policy is implemented
for shared resource access, the resource is locked by the process which is currently accessing
it).
Mutual Exclusion: The criteria that only one process can hold a resource at a time. Meaning
processes should access shared resources with mutual exclusion. Typical example is the
accessing of display hardware in an embedded device.
Hold and Wait: The condition in which a process holds a shared resource by acquiring the
lock control- ling the shared access and waiting for additional resources held by other
processes.
No Resource Preemption: The criteria that operating system cannot take back a resource from
a process which is currently holding it and the resource can only be released voluntarily by the
process holding it.
Circular Wait:
A process is waiting for a resource which is currently held by another process which in turn is
waiting for a resource held by the first process.

Deadlock Handling
The OS may adopt any of the following techniques to detect and prevent deadlock conditions.
Ignore Deadlocks:
Always assume that the system design is deadlock free. This is acceptable for the reason the
cost of removing a deadlock is large compared to the chance of happening a deadlock.
UNIX: is an example for an OS following this principle.
A life critical system cannot pretend that it is deadlock free for any reason.
Detect and Recover:
This approach suggests the detection of a deadlock situation and recovery from it. This one is
similar to the deadlock condition that may arise at a traffic junction.
When the vehicles from different directions compete to cross the junction, deadlock (traffic
jam) condition is resulted.deadlock (traffic jam) is happened at the junction, the only solution
is to back up the vehicles from one direction and allow the vehicles from opposite direction to
cross the junction. If the traffic is too high, lots of vehicles may have to be backed up to resolve
the traffic jam. This technique is also known as ‘back up cars’ technique (Fig. 10.26).

Operating systems keep a resource graph in their memory. The resource graph is updated on
each resource request and release. A deadlock condition can be detected by analysing the
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

resource graph by graph analyser algorithms. Once a deadlock condition is detected, the system
can terminate a process or preempt the resource to break the deadlocking cycle.
Avoid Deadlocks: Deadlock is avoided by the careful resource allocation techniques by the
Operating System. It is similar to the traffic light mechanism at junctions to avoid the traffic
jams.
Prevent Deadlocks: Prevent the deadlock condition by negating one of the four conditions
favouring the deadlock situation.
Ensure that-a process does not hold any other resources when it requests a resource. This can
be achieved by implementing the following set of rules/guidelines in allocating resources to
pro- cesses.
1. A process must request all its required resource and the resources should be allocated
before the process begins its execution.
2. Grant resource allocation requests from processes only if the process does not hold a
resource currently.
Ensure that resource preemption (resource releasing) is possible at operating system level. This
can be achieved by implementing the following set of rules/guidelines in resources allocation
and releasing.
1. Release all the resources currently held by a process if a request made by the process
for a new resource is not able to fulfil immediately.
2. Add the resources which are preempted (released) to a resource list describing the
resources which the process requires to complete its execution.
3. Reschedule the process for execution only when the process gets its old resources
and the new resource which is requested by the process. Imposing these criterions may
introduce negative impacts like low resource utilisation and starvation of processes.
Livelock
• The Livelock condition is similar to the deadlock condition except that a process in
livelock condition changes its state with time.
• While in deadlock a process enters in wait state for a resource and continues in that
state forever without making any progress in the execution, in.alivelock condition a
process always does something but is unable’ to make any progress in the execution
completion.
• The livelock condition is better explained with the real world example, two people
attempting to cross each other in a narrow corridor.
• Both the persons move towards each side of the corridor to allow the opposite person
to cross. Since the corridor is narrow, none of them are able to cross each other. Here
both of the persons perform some action but still they are unable to achieve their target,
cross each other.
Starvation
• In the multitasking context, starvation is the condition in which a process does not get
the resources required to continue its execution for a long time.
• As time progresses the process starves on resource.
• Starvation may arise due to various conditions like byproduct of preventive measures
of deadlock, scheduling policies favouring high priority tasks and tasks with shortest
execution time, etc.

HOW TO CHOOSE AN RTOS

Functional Requirements
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Processor Support It is not necessary that all RTOS’s support all kinds of processor
architecture. It is essential to ensure the processor support by the RTOS.
Memory RequirementsThe OS requires ROM memory for holding the OS files and it is
normally stored in a non-volatile memory like FLASH.OS also requires working memory
RAM for loading the OS services. Since embedded systems are memory constrained, it is
essential to evaluate the minimal ROM and RAM requirements for the OS under consideration.
Real-time Capabilities It is not mandatory that the operating system for all embedded systems
need to be Real-time and all embedded Operating systemsare ‘Real-time’ inbehaviour. The
task/process scheduling policies plays an important role in the ‘Real-time’ behaviour of an
OS.Analyse the real-time capabilities of the OS under consideration and the standards met by
the operating system for real-time capabilities.
Kernel and Interrupt Latency The kernel of the OS may disable interrupts while executing
certain services and it may lead to interrupt latency. For an embedded system whose response
requirements are high, this latency should be minimal.
Inter Process Communication and Task Synchronisation The implementation of Inter
Process Communication and Synchronisation is OS kernel dependent. Certain kernels may
provide a bunch of options whereas others provide very limited options. Certain kernels
implement policies for avoiding priority inversion issues in resource sharing.
Modularisation Support Most of the operating systems provide a bunch of features. At times
it may not be necessary for an embedded product for its functioning. It is very useful if the OS
supports modularisation where in which the developer can choose the essential modules and
re-compile the OS image for functioning. Windows CE is an example for a highly modular
operating system.
Support for Networking and CommunicationThe OS kernel may provide stack
implementation and driver support for a bunch of communication interfaces and networking.
Ensure that the OS under consideration provides support for all the interfaces required by the
embedded product.
Development Language Support Certain operating systems include the run time libraries
required for running applications written in languages like Java and C#. A Java Virtual
Machine (JVM) customised for the Operating System is essential for running java applications.
Similarly the NET Compact Framework (.NETCF) is required for running Microsoft® NET
applications on top of the Operating System. The OS may include these components as built-
in component, if not, check the availability of the same from a thirdparty vendor for the OS
under consideration.
Non-functional Requirements
Custom Developed or Off the Shelf Depending on the OS requirement, it is possible to go for
the complete development of an operating system suiting the embedded system needs or use
an off the shelf, readily available operating system, which is either a commercial product or an
Open Source product, which is in close match with the system requirements. Sometimes it may
be possible to build the required features: by customising an Open source OS. The decision on
which to select is purely dependent on the development cost, licensing fees for the OS,
development time and availability of skilled resources.
Cost The total cost for developing or buying the OS and maintaining it in terms of commercial
product and custom build needs to be evaluated before taking a decision on the selection of
OS.
Development and Debugging Tools Availability The availability of development and
debugging tools is a critical decision making factor in the selection of an OS for embedded
design. Certain Operating Systems may be superior in performance, but the availability of tools
for supporting the development may be limited.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Ease of Use How easy it is to use a commercial RTOS is another important feature that needs
to be considered in the RTOS selection.

5.2 INTEGRATION OF HARDWARE AND FIRMWARE

• Integration of hardware and firmware deals with the embedding of firmware into the
target hardware board.
• It is the process of ‘Embedding Intelligence’ to the product.
• The embedded processors/controllers used in the target board may or may not have
built in code memory.
• For non-operating system based embedded products, if the processor/controller
contains internal memory and the total size of the firmware is fitting into the code
memory area, the code memory is downloaded into the target controller/processor.
• If the processor/controller does not support built in code memory or the size of the
firmware is exceeding the memory size supported by the target processor/controller, an
external dedicated EPROM/ FLASH memory chip is used for holding the firmware.
• This chip is interfaced to the processor/controller. (The type of firmware storage, either
processor storage or external storage is decided at the time of hardware design by taking
the firmware complexity into consideration).
• A variety of techniques are used for embedding the firmware into the target board.
• The commonly used firmware embedding techniques for a non-OS based embedded
system are explained below.
• The non-OS based embedded systems store the firmware either in the onchip
processor/controller memory or offchip memory (FLASH/NVRAM, etc.).

Out-of-Circuit Programming

• Out-of-circuit programming is performed outside the target board.

• The processor or memory chip into which the firmware needs to be embedded is taken
out of the target board and it is programmed with the help of a programming device
(Fig. 12.1).
• The programming device is a dedicated unit which contains the necessary hardware
circuit to generate the programming signals.
• Most of the programmer devices available in the market are capable of programming
different family of devices with different pin outs (Pin counts).
• The programmer contains a ZIF socket with locking pin to hold the device to be
programmed. The programming device will be under the Programmer: LabTool-
48UXP) control of a utility program running PC. Usually the programmer is interfaced
to the PC through RS-232C/USB/Parallel Port Interface.
• The commands to control the programmer are sent from the utility program to the
programmer through the interface.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

The sequence of operations for embedding the firmware with a programmer is listed below. 1.
Connect the programming device to the specified port of PC (USB/COM port/parallel port) 2.
Power up the device (Most of the programmers incorporate LED to indicate Device power up.
Ensure that the power indication LED is ON)
3. Execute the programming utility on the PC and ensure proper connectivity is established
between PC and programmer. In case of error, turn off device power and try connecting it again
4. Unlock the ZIF (Zero Insertion Force) socket by turning the lock pin
5. Insert the device to be programmed into the open socket as per the insert diagram shown on
the programmer
6. Lock the ZIF socket
7. Select the device name from the list of supported devices
8. Load the hex file which is to be embedded into the device
9. Program the device by ‘Program’ option of utility program
10.Wait till the completion of programming operation (Till busy LED of programmer is off)
11.Ensure that programming is successful by checking the status LED on the programmer
(Usually ‘Green’ for success and ‘Red’ for error condition) or by noticing the feedback from
the utility program
12. Unlock the ZIF socket and take the device out of programmer
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Now the firmware is successfully embedded into the device.

• Insert the device into the board, power up the board and test it for the required
functionalities. It is to be noted that the most of programmers support only Dual Inline
Package (DIP) chips, since its ZIF socket is designed to accommodate only DIP chips.
• Hence programming of chips with other packages is not possible with the current setup.
Adaptor sockets which convert a non-DIP package to DIP socket can be used for
programming such chips.
• One side of the Adaptor socket contains a DIP interface and the other side acts as a
holder for holding the chip with a non-DIP package (say VQFP).
• Option for setting firmware protection will be available on the programming utility.
• If wereally want the firmware to be protected against unwanted external access, and if
the device is supporting memory protection, enable the memory protection on the utility
before programming the device.
• The programmer usually erases the existing content of the chip before programming
the chip. Only EEPROM and FLASH memory chips are erasable by the programmer.
• Some old embedded systems may be built around UVEPROM chips and such chips
should be erased using a separate ‘UV Chip Eraser’ before programming.
• The major drawback of out-of-circuit programming is the high development time.
• Whenever the firmware is changed, the chip should be taken out of the development
board for re-programming.
• This is tedious and prone to chip damages due to frequent insertion and removal.
• Better use a socket on the board side to hold the chip till the firmware modifications are
over. The programmer facilitates programming of only one chip at a time and it is not
suitable for batch production.
• Using-a ‘Gang Programmer’ resolves this issue to certain extent.
• A gang programmer is similar to an ordinary programmer except that it contains
multiple ZIF sockets (4 to 8) and capable of programming multiple devices at a time.
• But it is bit expensive compared to an ordinary programmer.
• Another big drawback of this programming technique is that once the product is
deployed in the market in a production environment, it is very difficult to upgrade the
firmware.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

In System Programming (ISP)

In System Programming with SPI Protocol

Devices with SPI In System Programming support contains a built-in SPI interface and the on-
chip EEPROM or FLASH memory is programmed through this interface.
The primary I/O lines involved in SPI - In System Programming are listed below.

MOSI - Master Out Slave In

MISO - Master In Slave Out
SCK - System Clock
RST- Reset of Target Device
GND - Ground of Target Device
• PC acts as the master and target device acts as the slave in ISP.
• The program data is sent to the MOSI pin of target device and the device
acknowledgement is originated from the MISO pin of the device.
• SCK pin acts as the clock for data transfer.
• A utility program can be developed on the PC side to generate the above signal lines.
• Since the target device works under a supply voltage less than SV (TTL/CMOS), it is
better to connect these lines of the target device with the parallel port of the PC.
• Since Parallel port operations are also at 5V logic, no need for any other intermediate
hardware for signal conversion.
• The pins of parallel port to which the ISP pins of device needs to be connected are
dependent on the program, which is used for generating these signals, or you can fix
these lines first and then write the program according to the pin interconnection
assignments.
• Standard SPI-ISP utilities are freely available on the internet and there is no need for
going for writing own program. What you need to do is just connect the pins as
mentioned by the program requirement.
As mentioned earlier, for ISP operations, thetarget device needs to be powered up in a pre-
defined sequence. The power up sequence for In System Programming for Atmel’s AT89S
series microcontroller family is listed below.
1. Apply supply voltage between VCC and GND pins of target chip.
2. Set RST pin to “HIGH” state.
3. If a crystal is not connected across pins XTAL1 and XTAL2, apply a 3 MHz to 24
MHz clock to XTAL]I pin and wait for at least 10 milliseconds.
4. Enable serial programming by sending the Programming Enable serial instruction to
pin MOSI/ P1.5. The frequency of the shift clock supplied at pin SCK/P1.7 needs to be
less than the CPU clock at XTAL1 divided by 40.
5. The Code or Data array is programmed one byte at a time by supplying the address
and data together with the appropriate Write instruction. The selected memory location
is first erased before the new data is written. The write cycle is self-timed and typically
takes less than 2.5 ms at SV.
6. Any memory location can be verified by using the Read instruction, which returns
the content at the selected address at serial output MISO/P1.6.
7. After successfully programming the device, set RST pin low or turn off the chip
power supply and turn it ON to commence the normal operation.
• The key player behind ISP is a factory programmed memory (ROM) called ‘Boot
ROM’.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The Boot ROM normally resides at the top end of code memory space and it varies in
the order of a few Kilo Bytes (For a controller with 64K code memory space and 1K
Boot ROM, the Boot ROM resides at memory location FCOOH to FFFFH).
• It contains a set of Low-level Instruction APIs and these APIs allow the
‘arocessor/controller to perform the FLASH memory programming, erasing and
Reading operations.
• “The contents of the Boot ROM are provided by the chip manufacturer and the same is
masked into every ‘device.
• The Boot ROM for different family or series devices is different.
• By default the Reset vector starts the code memory execution at location 0000H.
• If the ISP mode is enabled through the special ISP Power up sequence, the execution
will start at the Boot ROM vector location.
• In System Programming technique is the best advised programming technique for
development work since the effort required to re-program the device in case of firmware
modification is very little.
• Firmware upgrades for products supporting ISP is quite simple.

In Application Programming (IAP)

• In Application Programming (JAP) is a technique used by the firmware running on the

target deyice for modifying a selected portion of the code memory.
• It is not a technique for first time embedding of user written firmware. It modifies the
program code memory under the control of the embedded application.
• Updating calibration data, look-up tables, etc., which are stored in code memory, are
typical examples of IAP.
• The Boot ROM resident API instructions which perform various functions such as
programming, erasing, and reading the Flash memory during ISP.mode, are made
available to the end-user written firmware for IAP.
• Thus it is possible for an end-user application to perform operations on the Flash
memory.
• A common entry point to these API routines is provided for interfacing them to the end-
user’s application.
• Functions are performed by setting up specific registers as required by a specific
operation and performing a call to the common entry point.
• Like any other subroutine call, after completion of the function, control will return to
the end-user’s code.
• The Boot ROM is shadowed with the user code memory in its address range.
• This shadowing is controlled by a status bit.
• When this status bit is set, accesses to the internal code memory
• In this address range will be from the Boot ROM.
• When cleared, accesses will be from the user’s code memory.
• Hence the user should set the status bit prior to calling the common entry point for IAP
operations
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

Firmware Loading for Operating System Based Devices

• The OS based embedded systems are programmed using the In System Programming
(ISP) technique.
• OS based embedded systems contain a special piece of code called ‘Boot loader’
program which takes control of the OS and application firmware embedding and
copying of the OS image to the RAM of the system for execution.
• The ‘Boot loader’ for such embedded systems comes as pre-loaded or it can be loaded
to the memory using the various interface supported like JTAG.
• The bootloader contains necessary driver initialisation implementation for initialising
the supported interfaces like UART, TCP/IP etc.
• Bootloader implements menu options for selecting the source for OS image to load
• In case of the network based loading, the bootloader broadcasts the target’s presence
over the network and the host machine on which the OS image resides can identify the
target device by capturing this message.
• Once a communication link is established between the host and target machine, the OS
image can be directly downloaded to the FLASH memory of the target device.

BOARD POWER UP.

• Now the firmware is embedded into the target board using one of the programming
techniques
• Sometimes the first power up may end up in a messy explosion leaving the smell of
burned components behind.
• It may happen due to various reasons, like Proper care was not taken in applying the
power and power applied in reverse polarity (+ve of supply connected to -ve of the
target board and vice versa), components were not placed in the correct polarity order

THE EMBEDDED SYSTEM DEVELOPMENT AND ENVIRONMENT

The development environment consists of a Development Computer (PC) or Host, which acts
as the heart of the development environment, Integrated Development Environment (IDE) Tool
for embedded firmware development and debugging, Electronic Design Automation (EDA)
Tool for Embedded Hardware design, An emulator hardware for debugging the target board,
Signal sources (like Function generator) for simulating the inputs to the target board, Target
hardwaredebugging tools (Digital CRO, Multimeter, Logic Analyser, etc.) and the target
hardware.
The Integrated Development Environment (IDE) and Electronic Design Automation (EDA)
tools are selected based on the target hardware development requirement and they are supplied
as Installable files in CDs by vendors. These tools need to be installed on the host PC used for
development activities. These tools can be either freeware or licensed copy or evaluation
versions. Licensed versions of the tools are fully featured and fully functional whereas trial
versions fall into two categories, tools with limited features, and full featured copies with
limited period of usage.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

DISASSEMBLER/DECOMPILER

• Disassembler is a utility program which converts machine codes into target processor
specific Assembly codes/instructions.
• The process of converting machine codes into Assembly code is known as
‘Disassembling’.
• In operation, disassembling is complementary to assembling/cross-assembling.
• Decompiler is the utility program for translating machine codes into corresponding high
level language instructions.
• Decompiler performs the reverse operation of compiler/cross-compiler.
• The disassemblers/decompilers for different family of processors/controllers are
different. Disassemblers/Decompilers are deployed in reverse engineering.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Reverse engineering is the process of revealing the technology behind the working of a
product. Disassemblers/decompilers help the reverse engineering process by translating
the embedded firmware into Assembly/high level language instructions.
• Disassemblers/Decompilers are powerful tools for analysing the presence of malicious
codes (virus information) in an executable image.
• Disassemblers/Decompilers are available as either freeware tools readily available for
free download from internet or as commercial tools.
• It is not possible for a disassembler/decompiler to generate an exact replica of the
original assembly code/high level source code in terms of the symbolic constants and
comments used. However disassemblers/decompilers generate a source code which is
somewhat matching to the original source code from which the binary code is
generated.
•
SIMULATORS, EMULATORS AND DEBUGGING

• Simulator is a software tool used for simulating the various conditions for checking the
functionality of the application firmware.
• The Integrated Development Environment (IDE) itself will be providing simulator
support and they help in debugging the firmware for checking its required functionality.
• In certain scenarios, simulator refers to a soft model (GUI model) of the embedded
product. For example, if the product under development is a handheld device, to test
the functionalities of the various menu and user interfaces, a soft form model of the
product with all UI as given in the end product can be developed in software.
• Soft phone is an example for such a simulator.
• Emulator is hardware device which emulates the functionalities of the target device and
allows real time debugging of the embedded firmware in a hardware environment.

Simulators
Simulators simulate the target hardware and the firmware execution can be inspected using
simulators.
The features of simulator based debugging are listed below.
1. Purely software based
2. Doesn’t require a real target system
3. Very primitive (Lack of featured I/O support. Everything is a simulated one)
4. Lack of Real-time behaviour
Advantages of Simulator Based Debugging
Simulator based debugging techniques are simple and straightforward. The major advantages
of simulator based firmware debugging techniques are explained below.
No Need for Original Target Board
• Simulator based debugging technique is purely software oriented.
• IDE’s software support simulates the CPU of the target board.
• User only needs to know about the memory map of various devices within the target
board and the firmware should be written on the basis of it.
• Since the real hardware is not required, firmware development can start well in advance
immediately after the device interface and memory maps are finalised.
• This saves development time.

Simulate I/O Peripherals

• Simulator provides the option to simulate various I/O peripherals.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Using simulator’s I/O support you can edit the values for I/O registers and can be used
as the input/output value in the firmware execution.
• Hence it eliminates the need for connecting I/O devices for debugging the firmware.

Simulates Abnormal Conditions

• With simulator’s simulation support you can input any desired value for any parameter
during debugging the firmware and can observe the control flow of firmware.
• It really helps the developer in simulating abnormal operational environment for
firmware and helps the firmware developer to study the behaviour of the firmware
under abnormal input conditions.

Limitations of Simulator based Debugging

• Though simulation based firmware debugging technique is very helpful in embedded

applications, they possess certain limitations and we cannot fully rely upon the
simulator-based firmware debugging.
• Some of the limitations of simulator- based debugging are explained below.

Deviation from Real Behaviour

• Simulation-based firmware debugging is always carried out in a development

environment where the developer may not be able to debug the firmware under all
possible combinations of input.
• Under certain operating conditions we may get some particular result and it need not
be the same when the: firmware runs in a production environment.

Lack of real timeliness

• The major limitation of simulatorbased debugging is that it is not real-time in

behaviour.
• The debugging is developer driven and it is no way capable of creating a real time
behaviour. Moreover in a real application the I/O condition may be varying or
unpredictable.
• Simulation goes for simulating those conditions for known values.

Emulators and Debuggers

Debugging in embedded application is the process of diagnosing the firmware execution,
monitoring the target processor’s registers and memory while the firmware is running and
checking the signals from various buses of the embedded hardware. Debugging process in
embedded application is broadly classified into two, namely; hardware debugging and
firmware debugging. Hardware debugging deals with the monitoring of various bus signals and
checking the status lines of the target hardware.Firmware debugging deals with examining the
firmware execution, execution flow, changes to various CPU registers and status registers on
execution of the firmware to ensure that the firmware is running as per the design.

Incremental EEPROM Burning Technique

• This is the most primitive type of firmware debugging technique where the code is
separated into different functional code units.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Instead of burning the entire code into the EEPROM chip at once, the code is burned in
incremental order, where the code corresponding to all functionalities are separately
coded, cross-compiled and burned into the chip one by one.
• The code will incorporate some indication support like lighting up an “LED (every
embedded product contains at least one LED).
• If not, you should include provision for at least one LED in the target board at the
hardware design time such that it can be used for debugging purpose)” or activate a
“BUZZER (In a system with BUZZER support)” if the code is functioning in the
expected way.
• If the first functionality is found working perfectly on the target board with the
corresponding code burned into the EEPROM, go for burning the code corresponding
to the next functionality and check whether it is working.
• Repeat this process till all functionalities are covered.
• Please ensure that before entering into one level up, the previous level has delivered a
correct result.
• If the code corresponding to any functionality is found not giving the expected result,
fix it by modifying the code and then only go for ‘adding the next functionality for
burning into the EEPROM.
• After you found all functionalities working properly, combine the entire source for all
functionalities together, re-compile and burn the code for thetotal system functioning.
Obviously it is a time-consuming process.
• It is a onetime process and once you test the firmware in an incremental model you can
go for mass production.
• In incremental firmware burning technique we are not doing any debugging but
observing the statusof firmware execution as a debug method.
• The very common mistake committed by firmware developers in developing non-
operating system-based embedded application is burning the entire code altogether and
fed up with debugging the code.
• Incremental firmware burning technique is widely adopted in small, simple system
developments and in product development where time is not a big constraint (e.g. R&D
projects).
• It is also very useful in product development environments where no other debug tools
are available.

Inline BreakpointBased Firmware Debugging

• Inline breakpoint based debugging is another primitive method of firmware debugging.
• Within the firmware where you want to ensure that firmware execution is reaching up
to a specified point, insert an inline debug code immediately after the point.
• The debug code is a printf() function whichprintsa string given as per the firmware.
• You can insert debug codes (printf{()) commands at each point where you want to
ensure the firmware execution is covering that point.
• Cross-compile the source code with the debug codes embedded within it.
• Burn the corresponding hex file into the EEPROM.
• You can view the print{() generated data on the ‘Hyper- Terminal—A communication
facility available with the Windows OS coming under the Communications section of
Start Menu’ of the Development PC.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Configure the serial communication settings of the ‘HyperTerminal’ connection to the

same as that of the serial communication settings configured in the firmware (Say
Baudrate = 9600; Parity = None; Stop Bit = 1; Flow Control = None);
• Connect the target board’s serial port (COM) to the development PC’s COM Port using
an RS232 Cable.
• Power up the target board.
• Depending on the execution flow of firmware and the inline debug codes inserted in
the firmware, you can view the debug information on the ‘HyperTerminal’.
• Typical usage of inline debug codes and the debug info retrieved on the HyperTerminal
is illustrated below.
• If the firmware is error free and the execution occurs properly, you will get all the debug
messages on the HyperTerminal.
• Based on this debug info you can check the firmware for errors
Monitor Program Based Firmware Debugging

• Monitor program based firmware debugging is the first adopted invasive method for
firmware debugging (Fig. 13.39).
• In this approach a monitor program which acts as a supervisor 1s developed.
• The monitor program controls the downloading of user code into the code memory,
inspects and modifies register/memory locations; allows single stepping of source code,
etc.
• The monitor program implements the debug functions as per a pre-defined command
set from the debug application interface.
• The monitor program always listens to the serial port of the target device and according
to the command received/from the serial interface it performs command specific actions
like firmware downloading, memory inspection/modification, firmware single "stepping
and sends the debug information (various register and memory contents) back to the main
debug program running on the development PC, etc.
• The first step in any monitor program development is determining a set of commands
for performing various operations like firmware downloading, memory/ register
inspection/modification, single stepping, etc.
• Once the commands for each operation is fixed, write the code forperforming the
actions corresponding to these commands.
• As mentioned earlier, the commands may be received through any of the external
interface of the target processor (e.g. RS-232C serial interface/parallel interface/USB,
etc.).
• Themonitor program should query this interface to get commands or should handle the
command reception if the data reception.is implemented through interrupts.
• On receiving a command, examine it and perform the action corresponding to it.
• The entire code stuff handling the command reception and corresponding action
implementation is known as the “monitor program”.
• The most common type of interface used between target board and debug application
is RS-232C Serial interface.
• After the successful completion of the ‘monitor program’ development, it is compiled and
burned into the FLASH memory or ROM of the target board.
• The-code memory containing the monitor program is known as the ‘Monitor ROM’.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

The monitor program contains the following set of minimal features.

1. Command set interface to establish communication with the debugging application

2. Firmware download option to code memory
3. Examine and modify processor registers and working memory (RAM)
4. Single step program execution
5. Set breakpoints in firmware execution
6. Send debug information to debug application running on host machine

• The monitor program usually resides at the reset vector (code memory 0000H) of the
target processor.
• The monitor program is commonly employed in development boards and the
development board supplier provides the monitor program, in the form of a ROM chip.
• The actual code memory is downloaded intoa RAM chip which is interfaced to the
processor in the Von-Neumann architecture model.
• The Von-Neumann architecture model is achieved by ANDing the PSEN\ and RD\
signals of the target processor (In case of 805/) and connecting the output of AND Gate
to the Output Enable (RD\) pin of RAM chip.
• WR\ signal of the target processor is interfaced to The WR\ signal of the Von Neumann
RAM. Monitor ROM size varies in the range of a few kilo bytes (Usually 4K). An
address decoder circuit maps the address range allocated to the monitor ROM and
activates the Chip Select (CS\) of the ROMif theaddress is within the range specified
for the Monitor ROM.
• A user program is normally leaded at locations 0x4000 or 0x8000.
• Theaddress decoder circuit ensures the enabling of the RAMchip.(CS\) when
theaddress range is outside that allocated to the ROM monitor.
• Though there are two memory chips (Monitor ROM Chip and Von-Neumann RAM),
the total memory map available for both of them will be 64K for a processor/controller
with 16bit address space aidthe memory decoder units take care of avoiding conflicts
in accessing both. While developing user program for monitor ROM based systems,
special care should be taken to offset the user codeand handling the interrupt vectors.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• The target development IDE will help in resolving this. During firmware execution and
single stepping, the user code may have to-be altered and hence the firmware is always
downloaded into a Von-Neumann RAM in monitor ROM-based debugging systems.
• Monitor ROM-based debugging is suitable only for development work and it is not a
good choice for mass produced systems.
The major drawbacks of monitorbased debugging system are
1. The entire memory map is converted into a Von-Neumann model and it is shared
between the monitor ROM, monitor program data memory, monitor-program trace
buffer, user written firmware and external user memory.
2. The communication link between the debug application running on Development PC
and monitor program residing in the target system is achieved through a serial link and
usually the controller’s On-chip UART is used for establishing this link.

In Circuit Emulator (ICE) Based Firmware

‘Simulator’ is a software application that precisely duplicates (mimics) the target CPU and
simulates the various features and instructions supported by the target CPU, whereas an
‘Emulator’ is a self-contained hardware device which emulates the target CPU.
The emulator hardware contains necessary emulation logic and it is hooked to the debugging
application running on the development PC on one end and connects to the target board through
some interface on the other end. In summary, the simulator ‘simulates’ the target board CPU
and the emulator ‘emulates’ the target board CPU.
The emulators for different families of processors/controllers are different.
Figure 13.40 illustrates the different subsystems and interfaces of an ‘Emulator’ device.

The Emulator POD forms the heart of any emulator system and it contains the following
functional units.

Emulation Device

• Emulation device is a replica of the target CPU which receives various signals from the
target board through a device adaptor connected to the target board and performs the
execution of firmware under the control of debug commands from the debug
application.
• The emulation device can be either a standard chip same as the target processor (e.g.
AT89C51) or a Programmable Logic Device (PLD) configured to function as the target
CPU.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Ifa standard chip is used as the emulation device, the emulation will provide real-time
execution behaviour.
• At the same time the emulator becomes dedicated to that particular device and cannot
be re-used for the derivatives of the same chip.
• PLD-based. emulators can easily be re-configured to use with derivatives of the target
CPU under consideration.
• By simply loading the configuration file of the derivative processor/controller, the PLD
gets re-configured and it functions as the derivative device.
• A major drawback of PLD-based emulator is the accuracy of replication of target CPU
functionalities. PLD-based emulator logic is easy to implement for simple target CPUs
but for complex target CPUs it is quite difficult.
Emulation Memory
• It is the Random Access Memory (RAM) incorporated in the Emulator device.
• It acts as a replacement to the target board’s EEPROM where the code is supposed to
be downloaded after each firmware modification.
• Hence the original EEPROM memory is emulated by the RAM of emulator.
• This is known as ‘ROM Emulation’.
• ROM emulation eliminates the hassles of ROM burning and it offers the benefit of
infinite number of reprogrammings (Most of the EEPROM chips available in the
market supports only 100 to 1000 re-program cycles).
• Emulation memory also acts as a trace buffer in debugging.
• Trace buffer is a memory pool holding the instructions executed/registers
modified/related data by the processor while debugging.
• The trace buffer size is emulator dependent and the trace buffer holds the recent trace
information when the buffer overflows.
The common features of trace buffer memory and trace buffer data viewing are listed below:
➢ Trace buffer records each bus cycle in frames
➢ Trace data can be viewed in the debugger application as Assembly/Source code
➢ Trace buffering can be-done on the basis of a Trace trigger (Event)
➢ Trace buffer can also record signals from target board other than CPU signals (Emulator
dependent)
➢ Trace data is avery useful information in firmware debugging
Emulator Control Logic
• Emulator control logic is the logic circuits used for implementing complex hardware
breakpoints, trace buffer trigger detection, trace buffer control, etc.
• Emulator control logic circuits are also used for implementing logic analyser functions
in advanced emulator devices.
• The ‘Emulator POD’ is connected to the target board through a ‘Device adaptor’ and
signal cable.
Device Adaptors

• Device adaptors act as an interface between the target board and emulator POD.
• Device adaptors are normally pin-to-pin compatible sockets which can be
inserted/plugged into the target board for routing the various signals from the pins
assigned for the target processor. The device adaptor is usually connected to the
emulator POD using ribbon cables.
• The adaptor type varies depending on the target processor’s chip package. DIP, PLCC,
etc. are some commonly used adaptors.
On Chip Firmware Debugging (OCD)
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Though OCD adds silicon complexity and cost factor, from a developer perspective it
is.a very good feature supporting fast and efficient firmware debugging.
• The On Chip Debug facilities integrated to the processor/controller are chip vendor
dependent and most of them are proprietary technologies like Background Debug Mode
(BDM), OnCE, etc.
• Some vendors add ‘on chip software debug support’ through JTAG (Joint Test Action
Group) port.
• Processors/controllers with OCD support incorporate a dedicated debug module to the
existing architecture.
• Usually the on-chip debugger provides the means to set simple breakpoints, query the
internal state of the chip and single.step through code.
• OCD module implements dedicated registers for controlling debugging.
• An On Chip Debugger can be enabled by setting the OCD enable bit (The bit name and
register holding the bit varies across vendors).
• Debug related registers are used for debugger control (Enable/disable single stepping,
Freeze execution, etc.) and breakpoint address setting.
• BDM and JTAG are the two commonly used interfaces to communicate between the
Debug application running on Development PC and OCD module of target CPU.
• Some interface logic in the form of hardware will be implemented between the CPU
OCD interface and the host PC to capture the debug information from the target CPU
and sending it to the debugger application running on the host PC.
• The interface between the hardware and PC may be Serial/Parallel/USB.
• The following section will give you a brief introduction about Background Debug
Mode (BDM) and JTAG interface used in On Chip Debugging.
• Background Debug Mode (BDM) interface is a proprietary On Chip Debug solution
from Motorola. BDM defines the communication interface between the chip resident
debug core and host PC where the BDM compatible remote debugger is running.
• BDM makes use of 10 or 26 pin connector to connect to the target board.
• Serial data in (DSI, Serial data out (DSO) and Serial clock (DSCLK) are the three major
signal lines used in BDM.
• DSI sends debug commands serially to the target processor from the remote debugger
application and DSO sends the debug response to the debugger from the processor.
Synchronisation of serial transmission is done by the serial clock DSCLK generated by
the debugger application.
• Debugging is controlled by BDM specific debug. commands.
• The debug commands are usu- ally 17-bit wide. 16 bits are used for representing the
command and 1 bit for status/control.
• Chips with JTAG debug interface contain a built-in JTAG port for communicating with
the remote debugger application.
• JITAG is the acronym for Joint, Test Action Group. JTAG is the alternate narye for
IEEE 1149.1 standard.
• Like BDM, JTAG is also a serial interface:

The signal lines of JTAG protocol are explained below.

➢ Test Data In (TDI): It is used for sending debug commands serially from remote
debugger to the target processor.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

➢ Test Data Out (TDO): Transmit debug response to the remote debugger from target
CPU.
➢ Test Clock (TCK): Synchronises the serial data transfer.
➢ Test Mode Select (TMS): Sets the mode of testing.
➢ Test Reset (TRST): It is an optional signal line used for resetting the target CPU. The
serial data transfer rate for JIAG debugging is chip dependent. It is usually within the
range of 10 to 1000 MHz.

TARGET HARDWARE DEBUGGING

• Hardware debugging involves the monitoring of various signals of the target board
(address/data lines, port pins, etc.), checking the interconnection among various
components, circuit continuity checking, etc.
• The various hardware debugging tools used in Embedded Product Development are
explained below.
Magnifying Glass (Lens)
• A magnifying glass is a powerful visual inspection tool.
• With a magnifying glass (lens), the surface of the target board can be examined
thoroughly for dry soldering of components, missing components, improper placement
of components, improper soldering, track (PCB connection) damage, short of tracks,
etc.
• Nowadays high quality magnifying stations are available for visual inspection.
• The magnifying station incorporates magnifying glasses attached to a stand with CFL
tubes for providing proper illumination for inspection.
• The station usually incorporates multiple magnifying lenses. The main lens acts as a
visual inspection: tool for the entire hardware board whereas the other small lens within
the station is used for magnifying a relatively small area of the board which requires
thorough inspection.
Multimeter
• A multimeter is used for measuring various electrical quantities like voltage (Both AC
and DC), current (DC as well-as AC), resistance, capacitance, continuity checking,
transistor checking, cathode and anode identification of diode, etc.
• Any multimeter will work over a specific range for each measurement.
• A multimeter is the most valuable tool in the toolkit of an-embedded hardware
developer.
• It is the primary debugging tool for physical contact based hardware debugging and
almost all developers start debugging the hardware with it.
• In embedded hardware debugging it is mainly used for checking the circuit continuity
between different points on the board, measuring the supply voltage, checking the
signal value, polarity, etc.
• Both analog and digital versions of a multimeter are available.
• The digital version is preferred over analog the one for various reasons like readability,
accuracy, etc.
• Fluke, Rishab, Philips, etc. are the manufacturers of commonly available high quality
digital multimeters.

Digital CRO
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

• Cathode Ray Oscilloscope (CRO) is a little more sophisticated tool compared to a

multimeter. CRO is used for waveform capturing and analysis, measurement of signal
strength, etc.
• By connecting,the point under observation on the target board to the. Channels of the
Oscilloscope, the waveforms can be captured and analysed for expected behaviour.
• CRO is a very good tool in analysing interference noise in the power supply line and
other signal lines.
• Monitoring the crystal oscillator signal from the target board is a typical example of the
usage of CRO for waveform capturing and analysis in target board debugging. CROs
are available in both analog and digital versions.
• Though Digital CROs are costly, featurewise they are best suited for target board
debugging applications.
• Digital CROs are available for high frequency support and they also incorporate
modern techniques for recording waveform over a period of time, capturing waves on
the basis of a configurable event (trigger) from the target board (e.g. High to low
transition of a port pin of the target processor).
• Most of the modern digital CROs contain more than one channel and it is easy to capture
and analyse various signals from the target board using multiple channels
simultaneously.
• Various measurements like phase, amplitude, etc. is also possible with CROs.
• Tektronix, Agilent, Philips, etc. are the manufacturers of high precision good quality
digital CROs.
Logic Analyser
• A logic analyser is the big brother of digital CRO.
• Logic analyser is used for capturing digital data (logic 1 and 0) from a digital circuitry
whereas CRO is employed in capturing all kinds of waves including logic signals.
• Another major limitation of CRO is that the total number of logic signals/waveforms
that can be captured with a CRO is limited to the number of channels.
• A logic analyser contains special connectors and clips which can be attached to the
target board for capturing digital data.
• In target board debugging applications, a logic analyser captures the states of various
port pins, address bus and data bus of the target processor/controller, etc.
• Logic analysers give an exact reflection of what happens when a particular line of
firmware is running.
• This is achieved by capturing the address line logic and data line logic of target
hardware.
• Most modern logic analysers contain provisions for storing captured data, selecting a
desired region of the captured waveform, zooming selected region of the captured
waveform, etc. Tektronix, Agilent, etc. are the giants in the logic analyser market.
Function Generator
• Function generator is not a debugging tool.
• It is an input signal simulator tool.
• A function generator is capable of producing various periodic waveforms like sine
wave, square wave, saw-tooth wave, etc. with different frequencies and amplitude.
• Sometimes the target board may require some kind of periodic waveform with a
particular frequency as input to some part of the board.
• Thus, in a debugging environment, the function generator serves the purpose of
generating and supplying required signals.
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

BOUNDARY SCAN
As the complexity of the hardware increase, the number of chips present in the board and the
interconnection among them may also increase. The device packages used in the PCB become
miniature to reduce the total board space occupied by them and multiple layers may be required
to route the inter- connections among the chips. With miniature device packages and multiple
layers for the PCB it will be very difficult to debug the hardware using magnifying glass,
multimeter, etc. to check the interconnection among the various chips.
Boundary scan is a technique used for testing the interconnection among the various chips,
which support JTAG interface, present in the board. Chips which support boundary scan
associate a boundary scan cell with each pin of the device.
A JTAG port which contains the five signal lines namely TDI, TDO, TCK, TRST and TMS
form the Test Access Port (TAP) for a JTAG sup- ported chip. Each device will have its own
TAP. The PCB also contains a TAP for connecting the JTAG signal lines to the external world.
A boundary scan path is formed inside the board by interconnecting the devices through JTAG
signal lines. The TDI pin of the TAP of the PCB is connected to the TDI pin of the first device.
The TDO pin of the first device is connected to the TDI pin of the second device.
In this way all devices are interconnected and the TDO pin of the last JTAG device is connected
to the TDO pin of the TAP of the PCB. The clock line TCK and the Test Mode Select (TMS)
line of the devices areconnected to the clock line and Test mode select line of the Test Access
Port of the PCB respectively. This forms a boundary scan path.

The boundary scan cell isa multipurpose memory cell. The boundary scan cell associated with
the input pins of an IC is known as ‘input cells’ and the boundary scan cells associated with
the output pins of an IC is known as ‘output cells’.
The boundary scan cells can be used for capturing the input pin signal state and passing it to
the internal circuitry, capturing the signals from the internal circuitry and passing it to the
output pin, and shifting the data received from the Test Data In pin of the TAP. The boundary
MICROCONTROLLER AND EMBEDDED SYSTEMS MODULE 5

scan cells associated with the pins are interconnected and they form a chain from the TDI pin
of the device to its TDO pin.
The boundary scan cells can be operated in Normal, Capture, Update and Shift modes. In the
Normal mode, the input of the boundary scan cell appears directly at its output. In the Capture
mode, the boundary scan cell associated with each input pin of the chip captures the signal
from the respective pins to the cell and the boundary scan cell associated with each output pin
of the chip captures the signal from the internal circuitry. In the Update mode, the boundary
scan cell associated with each input pin.of the chip passes the already captured data to the
internal circuitry and the boundary scan cell associated with each output pin of the chip passes
the already captured data to the respective output pin. In the shift mode, data is shifted from
TDI pin to TDO pin of the device through the boundary scan cells.
ICs supporting boundary scan contain additional boundary scan related registers for facilitating
the boundary scan operation. Instruction Register, Bypass Register, Identification Register, etc.
are examples of boundary scan related registers. The Instruction Register is used for holding
and processing the instruction received over the TAP. The bypass register is used for bypassing
the boundary scan path of the device and directly interconnecting the, TDI pin of the device to
its TDO. It disconnects a device from the bound- ary scan path.