Term paper

CAP-212
Term-paper-synopsis
TOPIC: Types of interrupts which can arise in
microwave oven and how its microprocessor handles
those interrupts.
SUBMITTED BY: -
SUBMITTEDTO:- MR.SANDEEP SIR
VIKAS KUMAR

R
E3801B51

REG:10811324
 CONTENTS

• Introduction
• Voluntary events within processes:

• Events occurring on peripherals devices:

• Involuntary events within the processes:

• Action by operators:

• Timer interrupts:

• SOFTWARE INTERRUPTS:

• HARDWARE INTERRUPTS:

• HARDWARE SUPPORT:

• Edge or Level sensitive Interrupts

• Maskable Interrupts
• Non-Maskable Interrupts
• Multiple Interrupts
• Advantages of Interrupts
• Interrupt Latency
• Interrupt Response Time
• Microprocessor handles interrupts.

• The Operation of an Interrupt sequence on the 8086 Microprocessor:

• Hardware Identification (Vectored Interrupts)
• Priority Interrupt Management Controller
• Interrupts and Interrupt Handling
• Programmable Interrupt Controllers
• Refrences
 INTRODUCTION

An interrupt is an unexpected hardware initiated subroutine call or jump that temporarily

suspends the running of the current program.

Interrupts occur when a peripheral device asserts an interrupt input pin of the micro-processor.
Provided the interrupt is permitted, it will be acknowledged by the processor at the end of the
current memory cycle. The processor then services the interrupt by branching to a special service
routine written to handle that particular interrupt. Upon servicing the device, the processor is then
instructed to continue with what is was doing previously (by use of a special "return from
interrupt" instruction).

Interrupts fall into two major categories, maskable and non-maskable. An interrupt may be either
EDGE or LEVEL sensitive.

Edge level interrupts are recognised on the falling or rising edge of the input signal. They are
generally used for high priority interrupts and are latched internally inside the processor. If this
latching was not done, the processor could easily miss the falling edge (due to its short duration)
and thus not respond to the interrupt request.

Level sensitive interrupts overcome the problem of latching, in that the requesting device holds
the interrupt line at a specified logic state (normally logic zero) till the processor acknowledges
the interrupt. This type of interrupt can be shared by other devices in a wired or configuration,
thus is commonly used to support daisy chaining and other techniques.

Events occurring on peripherals devices:

A processor having initiated a control on a peripheral device on behalf of one process may start
some other process. When the transfer terminates, the peripheral device will cause an interrupt.

Voluntary events within processes:

A process wishing to use the services of operating system may use a specific type
of interrupt, a supervisor call (SVC) as a means of notifying the supervisor.
Involuntary events within the processes:
A process that attempts an undefined or prohibited action will cause an interrupts
that will notify the supervisor.

Action by operators:
An operation wishing to communicate with the supervisor may cause an interrupt.

Timer interrupts:
Many systems incorporate a timer that causes a fixed interval of time as a means
of guaranteeing that the supervisor will be entered periodically.

SOFTWARE INTERRUPTS:
The basic input/output system (BIOS) communicates directly with the hardware of
the computer. It consists of set of programs, which interface with device such as
keyboards, display, printer, serial port, Without BIOS the computer system will
simply of bundle of wires and electronic device. There are two parts of BIOS the first
part is permanently stored in non volatile memory called read only memory.
(ROM)This parts starts the computer bootstrap. The second is loaded when the
operating system is started.

An operating system allows the user to access the hardware in an easy to use
manner. It accepts command from the keyboard and displays them to the monitor.
The Disk operating system gained its name by from its original purpose of providing
a controller for the computer to access its disk drive. The language of DOS consists
of a set of command, which are entered directly by user and interpreted to perform
file management task.

HARDWARE INTERRUPTS:
Computer systems either use poling or interrupt driven software to service external
equipment. With poling the system continually monitors a status line and wait for it
to become archive. An interrupt driven device sends an interrupt request to the
computer, which is then serviced by Internet service routine

HARDWARE SUPPORT:
A process runs until it invokes an operating system service or until it is interrupted.
Here our attempt is to explain how to disabling interrupts. While one process is busy
updating shared memory in its critical region, no other process will enter it critical
region and cause trouble.The simplest solution is to have each process disable all
interrupts just after entering its critical region and re-enable them just before
leaving it. With interrupts disenable, no clock interrupt can occur. The central
processing unit is only switched from process to process as a result of clock or other
interrupt. After all and with interrupt turned off, the CPU will not be switched to
another process. Thus one process has disabled interrupts, it can then examine and
update the shared memory before without fear that any other process will
intervene. This approach is generally unattractive because it is unwise to give user
processes the power to turn off interrupts. Also, if the computer has two or more
CPUs disabling interrupts affect only the CPU that executed the disable instruction.
The other ones will continue running and will continue running and access the
shared memory.

Edge or Level sensitive Interrupts

Edge level interrupts are recognised on the falling or rising edge of the input signal. They are
generally used for high priority interrupts and are latched internally inside the processor. If this
latching was not done, the processor could easily miss the falling edge (due to its short duration)
and thus not respond to the interrupt request.

Level sensitive interrupts overcome the problem of latching, in that the requesting device holds
the interrupt line at a specified logic state (normally logic zero) till the processor acknowledges
the interrupt. This type of interrupt can be shared by other devices in a wired 'OR' configuration,
which is commonly used to support daisy chaining and other techniques.

Maskable Interrupts
The processor can inhibit certain types of interrupts by use of a special interrupt mask bit. This
mask bit is part of the flags/condition code register, or a special interrupt register. In the 8086
microprocessor if this bit is clear, and an interrupt request occurs on the Interrupt Request input,
it is ignored.

Non-Maskable Interrupts

There are some interrupts which cannot be masked out or ignored by the processor. These are
associated with high priority tasks which cannot be ignored (like memory parity or bus faults). In
general, most processors support the Non-Maskable Interrupt (NMI). This interrupt has absolute
priority, and when it occurs, the processor will finish the current memory cycle, then branch to a
special routine written to handle the interrupt request.

Multiple Interrupts

If more than one device is connected to the interrupt line, the processor needs to know to which
device service routine it should branch to. The identification of the device requesting service can
be done in either hardware or software, or a combination of both. The three main methods are:

• Software Polling,
• Hardware Polling, (Daisy Chain),
• Hardware Identification (Vectored Interrupts).

Advantages of Interrupts

Interrupts are used to ensure adequate service response times by the processing. Sometimes, with
software polling routines, service times by the processor cannot be guaranteed, and data may be
lost. The use of interrupts guarantees that the processor will service the request within a specified
time period, reducing the likelihood of lost data.

Interrupt Latency

The time interval from when the interrupt is first asserted to the time the CPU recognises it. This
will depend much upon whether interrupts are disabled, prioritized and what the processor is
currently executing. At times, a processor might ignore requests whilst executing some
indivisible instruction stream (read-write-modify cycle). The figure that matters most is the
longest possible interrupt latency time.

Interrupt Response Time

The time interval between the CPU recognising the interrupt to the time when the first instruction
of the interrupt service routine is executed. This is determined by the processor architecture and
clock speed.

Microprocessor handles interrupts.

Microcontrollers must provide real time (predictable, though not necessarily fast)
response to events in the embedded system they are controlling. When certain
events occur, an interrupt system can signal the processor to suspend processing
the current instruction sequence and to begin an interrupt service routine (ISR, or
"interrupt handler"). The ISR will perform any processing required based on the
source of the interrupt before returning to the original instruction sequence.
Possible interrupt sources are device dependent, and often include events such as
an internal timer overflow, completing an analog to digital conversion, a logic level
change on an input such as from a button being pressed, and data received on a
communication link. Where power consumption is important as in battery operated
devices, interrupts may also wake a microcontroller from a low power sleep state
where the processor is halted until required to do something by a peripheral event

The Operation of an Interrupt sequence on the 8086 Microprocessor:

• External interface sends an interrupt signal, to the Interrupt Request (INTR) pin, or an
internal interrupt occurs.
• The CPU finishes the present instruction (for a hardware interrupt) and sends Interrupt
Acknowledge (INTA) to hardware interface.
 • The interrupt type N is sent to the Central Processor Unit (CPU) via the Data bus from the
hardware interface.
• The contents of the flag registers are pushed onto the stack.
• Both the interrupt (IF) and (TF) flags are cleared. This disables the INTR pin and the trap
or single-step feature.
• The contents of the code segment register (CS) are pushed onto the Stack.
• The contents of the instruction pointer (IP) are pushed onto the Stack.
• The interrupt vector contents are fetched, from (4 x N) and then placed into the IP and
from (4 x N +2) into the CS so that the next instruction executes at the interrupt service
procedure addressed by the interrupt vector.
• While returning from the interrupt-service routine by the Interrupt Return (IRET)
instruction, the IP, CS and Flag registers are popped from the Stack and return to their
state prior to the interrupt.

Hardware Identification (Vectored Interrupts)

This is the fastest system. The onus is placed on the requesting device to request the interrupt,
and identify itself. The identity could be a branching address for the desired interrupt-handling
routine.

If the device just supplies an identification number, this can be used in conjunction with a lookup
table to determine the address of the required service routine. Response time is best when the
device requesting service also supplies a branching address.
 Priority Interrupt Management Controller

Priority Interrupt Controller Chips (PIC's) are hardware chips designed to make the task of a
device presenting its own address to the CPU simple. The PIC also assesses the priority of the
devices connected to it. Modern PIC's can also be programmed to prevent the generation of
interrupts which are lower than a desired level.

The decoded location is connected to the output of a priority encoder. The input of the priority
encoder is connected to each device. When a device requests service, the priority encoder
presents a special code combination (unique for each device) to the decoded memory location.
The port thus holds the value or address associated with the highest device requesting service.
The priority encoder arranges all devices in a list, devices given a lower priority are serviced
when no other higher priority devices need servicing. This simplifies the software required to
determine the device, resulting in an increase in speed.

Interrupts and Interrupt Handling

This chapter looks at how interrupts are handled by the Linux kernel. Whilst the kernel has
generic mechanisms and interfaces for handling interrupts, most of the interrupt handling details
are architecture specific.

A Logical Diagram of Interrupt Routing

Linux uses a lot of different pieces of hardware to perform many different tasks. The video
device drives the monitor, the IDE device drives the disks and so on. You could drive these
devices synchronously, that is you could send a request for some operation (say writing a block
of memory out to disk) and then wait for the operation to complete. That method, although it
would work, is very inefficient and the operating system would spend a lot of time ``busy doing
nothing'' as it waited for each operation to complete. A better, more efficient, way is to make the
request and then do other, more useful work and later be interrupted by the device when it has
finished the request. With this scheme, there may be many outstanding requests to the devices in
the system all happening at the same time.
There has to be some hardware support for the devices to interrupt whatever the CPU is doing.
Most, if not all, general purpose processors such as the Alpha AXP use a similar method. Some
of the physical pins of the CPU are wired such that changing the voltage (for example changing it
from +5v to -5v) causes the CPU to stop what it is doing and to start executing special code to
handle the interruption; the interrupt handling code. One of these pins might be connected to an
interval timer and receive an interrupt every 1000th of a second, others may be connected to the
other devices in the system, such as the SCSI controller.

Systems often use an interrupt controller to group the device interrupts together before passing
on the signal to a single interrupt pin on the CPU. This saves interrupt pins on the CPU and also
gives flexibility when designing systems. The interrupt controller has mask and status registers
that control the interrupts. Setting the bits in the mask register enables and disables interrupts and
the status register returns the currently active interrupts in the system.

Some of the interrupts in the system may be hard-wired, for example, the real time clock's
interval timer may be permanently connected to pin 3 on the interrupt controller. However, what
some of the pins are connected to may be determined by what controller card is plugged into a
particular ISA or PCI slot. For example, pin 4 on the interrupt controller may be connected to
PCI slot number 0 which might one day have an ethernet card in it but the next have a SCSI
controller in it. The bottom line is that each system has its own interrupt routing mechanisms and
the operating system must be flexible enough to cope.

Most modern general purpose microprocessors handle the interrupts the same way. When a
hardware interrupt occurs the CPU stops executing the instructions that it was executing and
jumps to a location in memory that either contains the interrupt handling code or an instruction
branching to the interrupt handling code. This code usually operates in a special mode for the
CPU, interrupt mode, and, normally, no other interrupts can happen in this mode. There are
exceptions though; some CPUs rank the interrupts in priority and higher level interrupts may
happen. This means that the first level interrupt handling code must be very carefully written and
it often has its own stack, which it uses to store the CPU's execution state (all of the CPU's
normal registers and context) before it goes off and handles the interrupt. Some CPUs have a
special set of registers that only exist in interrupt mode, and the interrupt code can use these
registers to do most of the context saving it needs to do.

When the interrupt has been handled, the CPU's state is restored and the interrupt is dismissed.
The CPU will then continue to doing whatever it was doing before being interrupted. It is
important that the interrupt processing code is as efficient as possible and that the operating
system does not block interrupts too often or for too long.

Programmable Interrupt Controllers

Systems designers are free to use whatever interrupt architecture they wish but IBM PCs use the
Intel 82C59A-2 CMOS Programmable Interrupt Controller or its derivatives. This controller has
been around since the dawn of the PC and it is programmable with its registers being at well
known locations in the ISA address space. Even very modern support logic chip sets keep
equivalent registers in the same place in ISA memory. Non-Intel based systems such as Alpha
AXP based PCs are free from these architectural constraints and so often use different interrupt
controllers.

there are two 8 bit controllers chained together; each having a mask and an interrupt status
register, PIC1 and PIC2. The mask registers are at addresses 0x21 and 0xA1 and the status
registers are at 0x20 and 0xA0 Writing a one to a particular bit of the mask register enables an
interrupt, writing a zero disables it. So, writing one to bit 3 would enable interrupt 3, writing zero
would disable it. Unfortunately (and irritatingly), the interrupt mask registers are write only, you
cannot read back the value that you wrote. This means that Linux must keep a local copy of what
it has set the mask registers to. It modifies these saved masks in the interrupt enable and disable
routines and writes the full masks to the registers every time.

When an interrupt is signalled, the interrupt handling code reads the two interrupt status registers
(ISRs). It treats the ISR at 0x20 as the bottom eight bits of a sixteen bit interrupt register and the
ISR at 0xA0 as the top eight bits. So, an interrupt on bit 1 of the ISR at 0xA0 would be treated as
system interrupt 9. Bit 2 of PIC1 is not available as this is used to chain interrupts from PIC2,
any interrupt on PIC2 results in bit 2 of PIC1 being set.

Interrupt Handling

One of the principal tasks of Linux's interrupt handling subsystem is to route the interrupts to the
right pieces of interrupt handling code. This code must understand the interrupt topology of the
system. If, for example, the floppy controller interrupts on pin 6 1 of the interrupt controller then
it must recognize the interrupt as from the floppy and route it to the floppy device driver's
interrupt handling code. Linux uses a set of pointers to data structures containing the addresses of
the routines that handle the system's interrupts. These routines belong to the device drivers for
the devices in the system and it is the responsibility of each device driver to request the interrupt
that it wants when the driver is initialized. Sa vector of pointers to the irqaction data structure.
Each irqaction data structure contains information about the handler for this interrupt, including
the address of the interrupt handling routine. As the number of interrupts and how they are
handled varies between architectures and, sometimes, between systems, the Linux interrupt
handling code is architecture specific. This means that the size of the irq_action vector vector
varies depending on the number of interrupt sources that there are.

When the interrupt happens, Linux must first determine its source by reading the interrupt status
register of the system's programmable interrupt controllers. It then translates that source into an
offset into the irq_action vector vector. So, for example, an interrupt on pin 6 of the interrupt
controller from the floppy controller would be translated into the seventh pointer in the vector of
interrupt handlers. If there is not an interrupt handler for the interrupt that occurred then the
Linux kernel will log an error, otherwise it will call into the interrupt handling routines for all of
the irqaction data structures for this interrupt source.

When the device driver's interrupt handling routine is called by the Linux kernel it must
efficiently work out why it was interrupted and respond. To find the cause of the interrupt the
device driver would read the status register of the device that interrupted. The device may be
reporting an error or that a requested operation has completed. For example the floppy controller
may be reporting that it has completed the positioning of the floppy's read head over the correct
sector on the floppy disk. Once the reason for the interrupt has been determined, the device
driver may need to do more work. If it does, the Linux kernel has mechanisms that allow it to
postpone that work until later. This avoids the CPU spending too much time in interrupt mode

REFRENCES: I am complete this term on micro processor book and following site:
www.google.com

www.wikipedia.com

www.answer .com

THANKS SIR