Module 3

[Link] monolithic and micro kernels with suitable examples for each.-2 times

Answer:

Monolithic Kernel

• In monolithic kernel architecture, all kernel services run in the kernel space.
• 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 e ective utilisation of the low-level features of the underlying system.
• The major drawback of monolithic kernel is that any error or 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.

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 abstract 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.
[Link] the term tasks, processes and threads./ Explain task, process and threads in
ARM processor.

Answer:

Tasks, Process and Threads

Task:

• In the operating system context, a task is defined as the program in execution and the
related information maintained by the operating system for 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.
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.
 Di erent 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 memory model for a process and its associated threads are given in the figure.
For more info page no 11-16

3. Three processes with IDs P1,P2 and P3 with estimated completion time 10,5,7 ms
respectively enter the ready queue together in order P1,P2,P3. Calculate waiting time and
turn around time for each process and average waiting time and TAT. (Assume there is no
I/O waiting for the processes).

Answer:
[Link] a note on IAP (in application programming) and In system programming.

Answer: 3. In Application Programming

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

target device 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 enduser'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.

2. In System Programming (ISP)

• Here, the programming is done 'within the system', meaning the firmware is embedded
into the target device without removing it from the target board.
• It is the most flexible and easy way of firmware embedding.
• The only pre-requisite is that the target device must have an ISP support.
• Apart from the target board, PC, ISP cable and ISP utility, no other additional hardware
is required for ISP.
• The target board can be interfaced to the utility program running on PC through Serial
Port/Parallel Port/USB.
• The communication between the target device and ISP utility will be in a serial format.
• The serial protocols used for ISP may be 'Joint Test Action Group (JTAG)' or
'Serial Peripheral
• The primary I/O lines Interface (SPI)' or any other proprietary protocol.
In order to perform ISP operations, the target device should be powered up in a special ‘ISP
mode’. ISP mode allows the device to communicate with an external host, such as a PC or
terminal, through a serial interface. The device receives commands and data from the host,
erases and reprograms code memory according to the received command. Once the ISP
operations are completed, the device is re-configured so that it will operate normally by
applying a reset or a re-power up.
Devices with SPI - In System Programming support contains a built- in SPI interface (Serial
Peripheral Interface) and the on-chip EEPROM or FLASH memory is programmed through
this interface.
involved in SPI - In System Programming are:
• 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.
• Since the target device works under a supply voltage less than 5V (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. Standard SPI-ISP utilities are feely available on the
internet and there is no need for going for writing own program.

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 XTAL1 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 5V.
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 o the chip power
supply and turn it ON to commence the normal operation.

5. Demonstrate a block schematic of IDE environment for embedded system design and
explain their function in brief/ Explain IDE environment for embedded system design with a
neat block diagram.-2 times

Answer:

In embedded system development context, Integrated Development Environment ( IDE) stands

for an integrated environment for developing and debugging the target processor specific
embedded firmware. IDE is a software package which bundles a ‘Text Editor (Source Code
Editor)’, ‘Cross-compiler (for cross platform development and compiler for same platform
development)’, ‘Linker’ and a ‘Debugger’. Some IDEs may provide interface to target board
emulators, Target processor’s/controller’s Flash memory programmer, etc. and incorporate
other software development utilities like ‘Version Control Tool’, ‘Help File for the Development
Language’, etc. IDEs can be either command line based or GUI based. Command line based
IDEs may include little or less GUI support. The old version of TURBO C IDE for developing
applications in C/C++ for x86 processor on Windows platform is an example for a

generic IDE with command line interface. GUI based IDEs provide a Visual Development
Environment with user interactions through touch/mouse click interface. Such IDEs are
generally known as Visual IDEs. Visual IDEs are very helpful in firmware development. A typical
example for a Visual IDE is Microsoft® Visual Studio for developing Visual C++ and Visual Basic
programs. Other examples are NetBeans and Eclipse.

IDEs used in embedded firmware development are slightly di erent from the generic IDEs used
for high level language based development for desktop applications. In Embedded Applications,
the IDE is either supplied by the target processor/controller manufacturer or by third party
vendors or as Open Source. MPLAB is an IDE tool supplied by microchip for developing
embedded firmware using their PIC family of microcontrollers. Keil μVision5 (spelt as micro
vision five) from ARMKeil is an example for a third party IDE, which is used for developing
embedded firmware for 8051/ARM family microcontrollers. CodeWarrior Development Studio is
an IDE for ARM family of processors/MCUs and DSP chips from Freescale. It should be noted
that in embedded firmware development applications each IDE is designed for a specific family
of controllers/processors and it may not be possible to develop firmware for all family of
controllers/processors using a single IDE (as of now there is no known IDE with support for all
family of processors/controllers).

However there is a rapid move happening towards the open source IDE, Eclipse for embedded
development. Most of the processor/control manufacturers and third party IDE providers are
trying to build the IDE around the popular Eclipse open source IDE. This may lead to a single IDE
based on Eclipse for embedded system development in the near future. Since this book is
primarily focusing on 8051 based embedded firmware development, the IDE chosen for
demonstration is Keil μVision5. A demo version of the tool for Microsoft Windows OS based
development is available for free download from

6. Illustrate the concept of ‘deadlock’ with a neat diagram. Mention the di erent conditions
which favours a deadlock situation/ Explain di erent conditions that favour deadlock.-2
times

Answer:

Deadlock
Deadlock Handling

A smart OS may foresee the deadlock condition and will act proactively to avoid such a
situation.
If a deadlock occurs, the reaction to it by OS is nonuniform.
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 that 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 is similar to the deadlock condition that may arise at a tra ic junction.
 When the vehicles from di erent directions compete to cross the junction, deadlock
(tra ic jam) condition is resulted.
 Once a deadlock (tra ic jam) has 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 tra ic is too high, lots of vehicles may have to be backed up to resolve the tra ic
jam.
 This technique is also known as 'back up cars' technique.
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 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 tra ic light mechanism at junctions to avoid the tra ic 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.
A process must request all its required resource and the resources should be allocated before
the process begins its execution.
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.
Release all the resources currently held by a process if a request made by the process for anew
resource is not able to fulfil immediately. Add the resources which are preempted (released) to
a resource list describing the resources which the process requires to complete its execution.
Reschedule the process for execution only when the process gets its old resources and the new
resource which is requested by the process.

7. Briefly explain the function of operating system with diagram.

Answer:

An operating system (OS) is the software that manages computer hardware and acts as an
interface between users and the physical components. It ensures that programs run e iciently
without conflicting with one another.

Core Functions of an Operating System

 Processor Management: Allocates the CPU's time to di erent tasks (processes) using
scheduling algorithms like Round Robin or First-Come-First-Served.
 Memory Management: Keeps track of every memory location (RAM) and decides which
process gets how much memory and when to free it.
 File Management: Organizes data into a hierarchical structure of files and folders,
managing their creation, deletion, and access permissions.
  Device Management: Coordinates communication with peripheral hardware (like
printers, keyboards, and mice) through specific software called device drivers.
 Security & Protection: Prevents unauthorized access to data and programs using
passwords and access control mechanisms.
 User Interface : Provides a platform for users to interact with the machine, typically via
a Graphical User Interface (GUI) like Windows or a Command Line Interface (CLI).

8. Explain pre-emptive SJF scheduling and illustrate with examples

Answer:

Preemptive Scheduling
 In preemptive scheduling, the scheduler can preempt (stop temporarily) the currently
executing task/process and select another task from the 'Ready' queue for execution.
When to pre-empt a task and which task is to be picked up from the 'Ready' queue for
execution after preempting the current task is purely dependent on the scheduling
algorithm. A task which is preempted by the scheduler is moved to the 'Ready' queue.
The act of moving a 'Running' process/task into the 'Ready' queue by the scheduler,
without the processes requesting for it is known as ‘Preemption’
Preemptive scheduling can be implemented in di erent approaches.
 Time-based preemption
 Priority-based preemption
The various types of preemptive scheduling adopted in task/process scheduling are:
 Preemptive Shortest Job First (SJF)/Shortest Remaining Time (SRT) Scheduling
 Round Robin (RR) Scheduling
 Priority Based Scheduling
Preemptive Shortest Job First (SJF)/Shortest Remaining Time (SRT) Scheduling
 In SJF, the process with the shortest estimated run time is scheduled first, followed by
the next shortest process, and so on. The preemptive SJF scheduling algorithm sorts the
'Ready' queue when a new process enters the 'Ready' queue and checks whether the
execution time of the new process is shorter than the remaining of the total estimated
time for the currently executing process. If the execution time of the new process is
less, the currently executing process is preempted and the new process is scheduled for
execution. Thus preemptive SJF scheduling always compares the execution completion
time (It is same as the remaining time for the new process) of a new process entered the
'Ready' queue with the remaining time for completion of the currently executing process
and schedules the process with shortest remaining time for execution. Preemptive SJF
scheduling is also known as Shortest Remaining Time (SRT) scheduling .
9. Write a note on racing and deadlock in task synchronization.

Answer: Page no 27 to 32

10. With a diagram mention function of the components in an embedded system

development environment.( note:search better answer)
An embedded system is a computer system specifically designed to perform dedicated
functions. It is typically integrated into other devices or systems to provide control or specific
functionality. Embedded systems are generally compact, e icient, and low-power, capable of
operating in resource-constrained environments and responding to external events in real time.

Common Applications

Embedded systems are used across many fields, including consumer electronics (such as
smartphones and digital cameras), home appliances (for example, washing machines and
microwave ovens), automotive electronics, aerospace, and medical devices. Typical tasks
include data acquisition, signal processing, control, and network communication.

Development Considerations

Developing embedded systems requires integrated hardware and software design, using
specialized development tools and programming languages. Common development platforms
include ARM, Arduino, and Raspberry Pi. Key design concerns include reliability, security, real-
time behavior, and power consumption.

Typical Components of an Embedded System

 Processor (CPU): The main computing unit responsible for executing programs and
controlling system operations.
 Memory: Includes flash memory, RAM, ROM, and EEPROM for storing programs, data,
and configuration information.
 Input devices: Sensors, keyboards, touchscreens, and other interfaces used to receive
external inputs.
 Output devices: Displays, LEDs, audio outputs, and other interfaces used to provide
information to users or other systems.
 Communication interfaces: Ethernet, Wi?Fi, Bluetooth, serial ports, and other interfaces
for communicating with external devices or networks.
  Real-time clock: Used for tracking time and events, typically for timestamps and
scheduling.
 Power management: Modules that manage power supply and consumption, which may
include battery management and energy-saving features.
 Bus architecture: Connects components, such as data buses, address buses, and
control buses.

11. Describe pre-entire SIF scheduling and calculate all the performance factors.

Answer:
12. With a neat diagram explain the concept of counting semaphore with an example.

Answer: The ‘Counting Semaphore’ limits the access of resources by a fixed number of
processes/threads. ‘Counting Semaphore’ maintains a count between zero and a maximum
value. It limits the usage of the resource to the maximum value of the count supported by it. The
state of the counting semaphore object is set to ‘signalled’ when the count of the object is
greater than zero. The count associated with a ‘Semaphore object’ is decremented by one when
a process/thread acquires it and the count is incremented by one when a process/thread
releases the ‘Semaphore object’. The state of the ‘Semaphore object’ is set to non-signalled
when the semaphore is acquired by the maximum number of processes/threads that the
semaphore can support (i.e. when the count associated with the ‘Semaphore object’ becomes
zero). A real world example for the counting semaphore concept is the dormitory system for
accommodation. A dormitory contains a fixed number of beds (say 5) and at any point of time it
can be shared by the maximum number of users supported by the dormitory. If a person wants
to avail the dormitory facility, he/she can contact the dormitory caretaker for checking the
availability. If beds are available in the dorm the caretaker will hand over the keys to the user. If
beds are not available currently, the user can register his/her name to get notifications when a
slot is available. Those who are availing the dormitory shares the dorm facilities like TV,
telephone, toilet, etc. When a dorm user vacates, he/she gives the keys back to the caretaker.
The caretaker informs the users, who booked in advance, about the dorm availability.

The creation and usage of ‘counting semaphore object’ is OS kernel dependent.