Modes of Transfer Video Lecture | Computer Architecture & Organisation (CAO) - Computer Science Engineering (CSE)

hello students and welcome to the
lecture on modes of data transfer and
serial communication after this lecture
we will be able to learn the following
objectives explain the introduction of
modes of data transfer explain serial
communication to find asynchronous and
synchronous communication explain
programmed i/o define interrupt
initiated IO and direct memory access
let's start with the introduction of
modes of data transfer and serial
communication
there are basically two formats of data
transfer parallel and serial in parallel
mode data bits are transferred parallel
over the communication lines referred to
as buses thus all the bits of a byte are
transferred simultaneously within the
time frame allotted for the transmission
in serial data transfer each data bit is
sent sequentially over a single data bus
line in order to implement serial data
transmission the sender and receiver
must divide the time frame allotted for
the transmission of a byte into sub
intervals during which each bit is sent
and received serial communication is a
popular means of transmitting data
between a computer and a peripheral
device such as a programmable instrument
or even another computer serial
communication uses a transmitter to send
data one bit at a time over a single
communication line to a receiver let's
now discuss the modes of data transfer
modes of data transfer refer to the
various modes by which the data residing
in the memory is transferred to the CPU
or back to the memory the data
originates from the input units the
originated data is then transferred to
the memory for storage this binary data
received from any external device is in
general stored in memory for later
processing so first one needs a transfer
of data then for processing the data
residing in memory is read by the
computer brain the CPU for carrying out
various operations and transforming it
to make it useful information the CPU
temporarily stores data just for the
time being of executing the operation
data to and from the peripherals are
handled in one of the four possible
modes programmed input/output interrupt
initiated input/output
interrupt-driven IO direct memory access
programmed input-output programs
input/output operations are the results
of i/o instructions written in the
computer program for transferring of
data each data item transfer is
initiated by an instruction written or
specified in the program usually the
transfer is from the CPU register and
peripherals like input and output
devices other instructions are needed to
transfer the data to and from the CPU
and memory of the computer not the
peripherals once the process is
initiated the CPU is required to monitor
the interface of the peripherals so that
it can sense when the data can be
transferred it is up to the programmed
instruction executed in the CPU to keep
close tabs on the things that are
carrying out in the interface and the
i/o devices interrupt initiated
input/output in the programmed i/o
method the CPU stays in a program loop
until the i/o unit indicates for data
transfer which sometimes makes the CPU
busy needlessly this can be avoided by
using an interrupt facility in special
commands interrupt driven IO interrupt
driven i/o is defined as in this method
the program issues the i/o command and
then continues to execute until it is
interrupted by the i/o hardware to
signal the end of Io operation here the
program enters a wait loop in which it
repeatedly checks the device status
during this process the processor is not
performing any useful computation
programmed i/o in the programmed i/o
method the i/o device does not have
direct access to memory a transfer from
an i/o device to memory requires the
execution of several instructions by the
CPU including an input instruction to
transfer the data from the device to the
CPU and a store instruction to transfer
the data from the CPU to memory other
instructions may be needed to verify
that the data are available from the
device and to count the numbers of words
transferred an example of data transfer
from an i/o device through an interface
into the CPU is when a device transfers
bytes of data one at a time as they are
available when a byte of data is
available the device places it in the
i/o bus and enables its data valid line
the interface accepts the bite into its
data register and enables the data
accepted line the interface sets a bit
in the status register that one will
refer to as an F or flag fit the device
can now disable the data valid line but
it will not transfer another byte until
the data accepted line is disabled by
the interface a program is written for
the computer to check the flag in the
status register to determine if a byte
has been placed in the data register by
the i/o device this is done by reading
the status register into a CPU register
and checking the value of the flag bit
if the flag is equal to one the CPU
reads the data from the data register
interrupt initiated IO and direct memory
access an alternative to the CPU
constantly monitoring the flag is to let
the interface inform the computer when
it's ready to transfer data
this mode of transfer uses the interrupt
facility while the CPU is running a
program it does not check the flag
however when the flag is set the
computer is momentarily interrupted from
proceeding with the current program and
is informed of the fact that the flag
has been set the CPU deviates from what
it's doing to take care of the input or
output transfer after the transfer is
completed the computer returns to the
program to continue what it was doing
before the interrupt the CPU responds to
the interrupt signal by storing the
return address from the program counter
into a memory stack and then control
branches to a service routine that
processes the required IO transfer the
way that the processor chooses the
branch address of the service routine
varies from one unit to another in
principle there are two methods for
accomplishing this one is called
vectored interrupts and the other non
vectored interrupts in a non vectored
interrupt the branch address is assigned
to a fixed location in memory in a
vectored interrupt the source that
interrupts supplies the branch
information to the computer this
information is called the interrupt
vector in some computers the interrupt
vector is the first address of the i/o
service routine in other computers the
interrupt vector is an address that
points to a location in memory where the
beginning address of the i/o service
routine is stored the transfer of data
between a fast storage device such as
magnetic disk and memory is often
limited by the speed of the CPU removing
the CPU from the path and letting the
peripheral device manage the memory
buses directly would improve the speed
of transfer this transfer technique is
called direct memory access or DMA
during DMA transfer the CPU is idle and
has no control of the memory buses a DMA
controller takes over the buses to
manage the transfer directly between the
i/o device and memory programmed i/o or
Pio
refers to data transfers initiated by a
CPU under driver software control to
access registers or memory on a device
the CPU issues a command then waits for
i/o operations to be complete as the CPU
is faster than the i/o module the
problem with programmed i/o is that the
CPU has to wait a long time for the i/o
module of concern to be ready for either
reception or transmission of data the
CPU while waiting must repeatedly check
the status of the i/o module and this
process is known as polling interrupt
the CPU issues commands to the i/o
module then proceeds with its normal
work until interrupted by an i/o device
on completion of its work for input the
device interrupts the CPU when new data
has arrived and is ready to be retrieved
by the system processor the actual
actions to perform depend on whether the
device uses IO ports or memory mapping
for output the device delivers an
interrupt either when it is ready to
accept new data or to acknowledge a
successful data transfer memory mapped
and DMA capable devices usually generate
interrupts to tell the system they are
done with the buffer when hardware
devices on a computer produce events we
need some way of being able to handle
those events within the operating system
and deliver them to applications and
hardware devices are going to produce
events at times and end patterns that we
don't know about in advance for example
we don't know which keys the user is
going to press on the keyboard until the
user actually presses those keys if a
cat walks across the keyboard we're
going to see a completely different
pattern of key presses
from which we would expect to see with
the human user similarly if we have
incoming network packets if we're
running a server application or even
just a workstation and we have messages
coming in from the network we don't know
the order and timing of those messages
we also don't know when the mouse is
going to be moved or when any other of a
whole bunch of hardware events is going
to occur so how can we get the
information generated by these events
and make it available to our
applications for use well we have two
options first option is that we can poll
each device we can ask each device if it
has any new information and retrieve
that information or we can let the
devices send a signal whenever they have
information and have the operating
system stop whatever it's doing and pick
up that information this is called an
interrupt the polling model of input
involves the OS periodically polling
each device for information so every so
often the CPU is going to send a message
to each hardware device in the system
and say hey you have any data for me and
most of the time the device is going to
send back no don't really have any data
for you
other times the device is going to send
back some data it's a really simple
design extremely simple to implement but
there are a number of problems with
polling first problem is is that most of
the time when you're polling the devices
are not going to have an input data
deliver thus polling is going to waste a
whole lot of CPU time the second issue
that occurs is high latency if I press a
key on the keyboard that keystroke is
not going to get transmitted to the
computer until the next time the CPU
pulls the keyboard to ask which keys
have been pressed if that time is set to
be really short I'll have good
responsiveness but the CPU is not going
to get any useful work done on the other
hand if we set that time length to be
long enough for the CPU to get some work
done there's going to be a noticeable
lag between the time I
press the key and the time a character
appears on the screen since the device
must wait for a polling interval because
it can translate input we're going to
have a high latency situation and again
shortening that polling interval to try
to reduce the latency simply wastes a
whole lot of CPU time checking devices
that have no input so a better mechanism
is to use a system called interrupts and
with interrupts the hardware devices
actually signal the operating system
whenever events occur or more precisely
they signal the CPU and then it's up to
the operating system to receive and
handle that signal what the operating
system will do is it will preempt any
running process in other words it will
switch what we call context away from
that running process to handle the event
basically it will move the program
counter of the CPU to the code to handle
that particular interrupt this allows
for a more responsive system than we
could ever achieve through polling
without having to waste a whole bunch of
time asking idle devices for data
however this does require a more complex
implementation and that implementation
complexity begins at the hardware level
specifically within the CPU we need to
have a mechanism for checking and
responding to interrupts and this
mechanism is implemented as part of the
CPUs fetch execute cycle in the process
of fetch execute the CPU is going to
fetch an instruction from memory
increment the program counter execute
that instruction but instead of simply
going back to the next fetch the CPU
actually has to have additional hardware
to check to see if an interrupt event is
pending
if there is an interrupt pending then
the CPU has to be switched to kernel
mode if it's running in user mode so the
privilege level needs to be escalated
save the program counter by pushing it
onto the stack and load a program
counter from a fixed memory location and
that fixed memory location is called the
vector table or IV T so we load the
program counter from the IV T and then
the CPU goes and executes that new
instruction the next time the fetch
execute cycle resumes so the CPU
actually moves from executing program
code to executing code from the
interrupt handler for the particular
event if no interrupt is pending at the
end of and executes then we simply go
back to the next instruction fetch the
interrupt vector table consists of an
array of addresses of handlers each
element in this array essentially gives
the program counter location for the
handler for a particular interrupt this
handler is going to be in a sub system
of the kernel from on elliptic kernel or
this handler might invoke a call to an
external server for a microkernel in any
case however the first handler by
convention element 0 of the array is
always the handler for the clock then
handlers for different devices are in
the array after the clock Handler so the
interrupt vector is always mapped into
the user part of memory it's always
available at all times so that the
kernel can go and look up interrupt
information whenever is necessary an
interrupt is processed by branching the
program counter to the interrupt handler
executing interrupt handling code and
then at the end of the interrupt
handling code there will be an
instruction to return from the interrupt
in the intel assembly line