|
Execution of a program happens serially.
Commands are executed one by one; processors can handle a single
task at a time. On the rising edge of the clock a new operation
is carried out. I know, you may be addicted to visual basic, java
and object oriented programming and you have a different perception
of things. Nevertheless, realize that high level languages are just
abstractions of the real thing. Useful undoubtedly but, not for
our wonderful microcontroller world.
From the microcontroller's perspective,
it gets a little boring. If a microcontroller could foresee its
future it would find it very deterministic, all commands are known
in advance. Loops and conditional jumps certainly provide some joy
but again the microcontroller's course of action is predefined.
This is why we introduce interrupts!
Interrupts are internal or external events asynchronous with the
main program flow that when they trigger, they get the microcontroller's
attention. We do not know in advance when they will occur, we just
define how they are going to be serviced.
When an interrupt signal occurs, the interrupt service
routine (ISR) is executed asynchronously with the main flow and then normal
execution carries on.
The thing is, a microcontroller communicating
with its surroundings has to wait for external events to happen
before it takes an action. Say for example, we have a button and a LED
connected to our microcontroller and the task is the LED to switch
on when we press the button. What our micro will do? It will
keep polling the button in a loop to check if it is pressed or not
and if it is, it will take action. Well, this means that our micro
will remain in a busy-wait state which is awfull if it has other
things to do as well.
With interrupts polling is not needed,
the button when pressed will generate a hardware signal, an external
interrupt for our microcontroller which will respond promptly by
leaving what it is doing to enter the ISR and servise the request.
No wait state for this scheme.
Now, there are many different sources
of interrupts and each one has a corresponding ISR. The micro to
know which event triggers which ISR needs a table, the vector table.
This is due to the Program Counter (PC), the pointer that indicates
the next instruction that is to be executed, has to see where in
program memory the ISR resides, to jump there.
Looking at the program memory of a
microcontroller, we see what the PC does when an interrupt hits.
It looks at the vector table, it jumps to the indicated ISR, it
executes it and then returns back to the main program flow.
You may go through the datasheet of ATMega8 to find
the available interrupt sources, the interrupt vector table and the
associated registers.
|
