Download ST7 USER GUIDE

5 - Peripherals
The interrupt service routine is supposed to take the appropriate actions that will vary according to the interrupt source. For example, if an Input bit has changed its state, the service
routine may change the state of an output bit; if the interrupt was generated by the timer, this
may produce the transmission of a byte by the SPI, etc. depending on the structure of the application as defined by the programmer.
Some interrupt vectors are common to several interrupt sources (e.g. the timers that have five
sources). In this case, the first task of the service routine must be to check which source has
requested the interrupt, before taking the appropriate action. This is done by testing the state
of the various bits in the peripheral’s Status Register.
Eventually, the service routine is finished. Then the core may return to the main program by
ecuting the IRET instruction.
5.2.5.3 Restoring the interrupted program state: The IRET instruction
As described above, an interrupt service routine looks a little bit like a subroutine. Like in a
subroutine, the return address is stored in the stack, and the execution of the RET instruction
returns to the calling program.
Here, more things are to be done before returning to the interrupted program. All the core registers have been pushed on granting the interrupt request (except the Y register). They must
now be restored, so that the execution of the service routine will not leave any trace in the
core. This is the role of the IRET instruction.
The IRET instruction proceeds with popping off the stack all the data that had been pushed
previously, namely the Condition Code (then the I bit is also restored), the Accumulator, the X
register and the Program Counter.
From this time on, execution of the interrupted program resumes.
5.2.6 Nesting the interrupt services
Some interrupts may require the quickest service possible, for example if they signal the availability of some data that it volatile, that is, will not remain for a long time. In such a case, the
fact that an interrupt service routine is not interruptible by default may be a problem, if the time
to service this interrupt is longer than the allowable latency for the interrupt requiring a quick
service. For so, it is possible to clear the global interrupt mask within an interrupt service routine.
At that time, one would probably like to restrain the interrupt request sources that may actually
interrupt the service routine in progress. Some prioritizing, here also, is needed. But this is not
the same priority mechanism as that mentioned above.
This priority mentioned about the interrupt sources is only taken into account when the core
has to decide between two concurrent requests. It does not apply when interrupts are re-ena-
92/315