interrupts vs function calls

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am new to embedded systems. I have few questions

a)Can key board clicks be considered as hardware interrupts or software
interrupts?


b) How are interrupts different from function calls or subroutines?
   In both cases current state of execution is saved (in stack) and the
Interrupt service routine or called function is executed and after
finishing it, normal execution is resumed.


      
                    
---------------------------------------        
Posted through http://www.EmbeddedRelated.com

Re: interrupts vs function calls
Quoted text here. Click to load it

This depends on the keyboard and the system it is connected to.

In a PC, there is one processor in the keyboard itself. The
processor continually scans the keys and sends changes of
the key states via a special serial communication line.

The serial data is fed into another auxiliary processor
which converts it back to parallel form and notifies the
main processor via a hardware interrupt.

Quoted text here. Click to load it

An interrupt comes as a surprise to the execution of the
baseline code, so the interrupt handler has to be more
careful with the processor state (registers, status) than
a subroutine which is voluntarily started by the mainline
code.

Quoted text here. Click to load it

--

-Tauno Voipio

Re: interrupts vs function calls
Quoted text here. Click to load it

Software interrupts happen from inside of software, when an instruction
is called.  This doesn't happen in response to outside events -- so a
key board click will, eventually, trace back to a hardware interrupt.
(In a complex OS like Windows or Linux the ISR will be built in to the
OS, and it'll be many layers deep so that the machine can react the same
way to keyboard input coming through a variety of different media).

Quoted text here. Click to load it

Function calls are very predictable in what resources they use, and what
resources they are free to consume.  So a calling function need only
save the context that the called function is allowed to use without
saving.  Furthermore, function calls happen at known times, so data
integrity is preserved -- an interrupt, on the other hand, may happen
right after half of a long data word has been written to memory, but
before the other half has been.

Interrupts can happen at any time, so an ISR can't count on _anything_
being saved, beyond whatever context the processor saves in the
interrupt process.  The amount of context saved varies widely, too --
some processors will save everything except the kitchen sink, some
processors will save everything _including_ the kitchen sink, some
processors will save the absolute bare minimum of information and leave
it to the ISR to save more, etc.

In general a processor will be designed so that when an ISR happens you
can save the entire context of the processor, go do something
interesting, then restore the context.  But I've worked on at least one
(the ADSP 21xx DSP chip) that wouldn't allow a complete context save,
meaning that (a) there were things that you couldn't do in an ISR no
matter what, and (b) if you had a multi-tasking system you could only do
certain operations within one task.

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: interrupts vs function calls
On Wed, 04 May 2011 13:14:14 -0500, "kadanamalli@gmai"

Quoted text here. Click to load it

That is completely dependeng on the design of the system.  For a
simple keyboard interfaced via discrete I/O lines, it may be be
neither.  The software may simply poll the keyboard (to figure out if
anything is pressed) at a certain rate.

So, "polled" is also a possibility.

However, in a PC, as someone else mentioned, the keyboard has its own
processor that communicates serially to the motherboard.  What is on
the motherboard ... I have no idea.

Quoted text here. Click to load it

A hardware interrupt is a function call that is "forced" by the
hardware in reaction to external events.  The interrupt may occur at
any time, i.e. between any two instructions.

I don't want to get into this unless it is necessary, but there is a
saying that in small systems 80% of intermittent bugs are due in one
way or another to hardware interrupts.  There are very good reasons
for that.

DFC

Site Timeline