interrupts vs function calls

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

formatting link

Reply to
kadanamalli
Loading thread data ...

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.

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.

--

-Tauno Voipio
Reply to
Tauno Voipio

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).

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
 Click to see the full signature
Reply to
Tim Wescott

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.

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

Reply to
Datesfat Chicks

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.