Файл: The quintessential PIC microcontroller (S. Katzen, 2000).pdf

184 The Quintessential PIC Microcontroller

This process of saving and restoring the state of internal registers (this internal state is called the context) on entry and exit is known as context switching. Of course care must be taken that the ISR does not use these locations in Data memory for any other purpose.

Core function

The interrupt flag, INTF in INTCON, is cleared to ensure that on return to the background program another interrupt request is not immediately auctioned…indefinitely. In situations where there is more than one source of interrupts, the various interrupt flags would be polled at this stage of the program – see page 179. There would then be several core routines, each of which would commence by clearing the appropriate interrupt flag.

The functional sector of the core function simply increments the datum EVENT. This is then checked against decimal 23. If it is higher then EVENT is zeroed. The background program looks for this zero as a sign that 24 cans have passed.

Restoring the context

The exit process first restored the original state of the Status register by swapping out of memory into W. This cancels the original swapf which was used to save the Status register on entry to the ISR. It is then copied from W into STATUS.

Finally, the Working register has to be restored from Data memory. This process must not alter the newly restored STATUS flag settings. Thus swapf is used twice; the first to twist the nybbles out in memory and the second to copy the datum into W and to untwist in the process. The final exit instruction retfie does not alter the flag state.

Although our example showed a context change involving STATUS and W, other SPRs can be saved in the same way. For example, if the File Select Register is used by both background and foreground routines then it should be saved and retrieved at the beginning and end of the ISR – see Example 7.4. In general, if the ISR alters any SPR then its original state should be restored on exit. In all cases W needs to be saved first, as it is used as an intermediary for the other transfers, and similarly restored last.

In common with all interrupt-driven systems, special care has to be taken where multiple sources of interrupt are being handled. As an example, consider a certain system receiving interrupt requests from the Timer at, say, 1000 times per second and externally through the INT pin at an irregular rate. If the INT handler takes, say, 4 ms to execute, then on return three Timer requests will have been lost! Some MCUs have interrupt priority logic so that a higher-priority request (the Timer here) will interrupt a lower-priority process (the INT handler). Here the only solu-

186 The Quintessential PIC Microcontroller

•Where multiple-byte data objects are being processed by an ISR consideration should be given to disabling the interrupt system during any background access.

Examples

Example 7.1

In a food processing factory, cans of baked beans on a conveyer belt continually pass through a tunnel oven, as shown top of Fig. 7.5, where the contents are sterilized. Photocell detectors are used to sense cans, both entering and leaving the oven. The output of the sensors are logic 1 when the beam is broken.

You are asked to design an interrupt-driven interface for this system, combining the two signals to activate the PIC’s one INT input. A buzzer connected to Port B’s bit RB0 is to be sounded if the number of tins in the oven exceeds four, indicating that a jam has occurred.

Solution

The hardware aspect of this example presents two problems. The first of these involves distinguishing which cell, IN or OUT, generates a request. In Fig. 7.5 each cell clocks an associated D flip flop when the beam is broken. As the D input is permanently tied to logic 1, the clocked flip flop output goes to logic 1. NORing both of these interrupt flags together generates a falling edge at the INT pin if any beam is broken.

Both the IN and OUT external flags can be read at Port A pins RA0 and RA1, and this allows the ISR software to distinguish between the two events (can-in and can-out). The appropriate flag can then be reset by toggling the appropriate flip flop reset using two further port lines RA2 and RA3 for Cancel_in and Cancel_out respectively.

One problems remains: If one event follows another before the ISR software has time to reset the appropriate external flip flop, that second event will be missed, as the OR gate will hold INT low. In this situation no further edge can occur and the interrupt system will be permanently disabled! This can be circumvented in software by polling both external flags before exiting the ISR and taking the appropriate action if both bits are not clear.

The interrupt service routine for this hardware configuration is given in Program 7.3. As described on page 181 the context is saved on entry and restored on exit.

The meat of the code simply resets the internal INTF flag and checks each of the external flip flops in turn. Depending on the state of these flip flops, one of three paths through the code is followed:

; *************************************************************

;*************************************************************

;The exit point

;*************************************************************

;The ISR core

1.If pin RA0 is high then a can has broken the IN beam and one is added to the event counter kept in a General-Purpose Register (GPR) in the File store. The external IN flip flop is reset. If the total is greater than four, the buzzer is turned on by bringing RB0 low, otherwise it is turned o . Repeat.

2.If pin RA1 is high then a can has broken the OUT beam and one is taken away from the event counter. This time the external OUT flip flop is reset. Again the total is checked against the boundary of four and the buzzer set to its appropriate state. Repeat.

3.If neither flip flop is set then the ISR exits after restoring the context.

7. Interrupt Handling 189

Example 7.2

Sensitive routines in the background software, eg. see page 185, may be protected by clearing the GIE (General Interrupt Enable) mask and reenabling it at the conclusion. However, if an interrupt occurs in the middle of the actual instruction clearing GIE (eg. bcf INTCON,GIE) then the interrupt will still be recognized at the instruction’s completion and the ISR entered! What e ect would this have on the following protected routine and how could this problem be countered?

Solution

On return from the ISR the retfie instruction will automatically reenable the interrupt system by setting GIE, so the supposedly protected routine will be left vulnerable to a further interrupt. Any error will be extremely rare as it depends on the conjunction of the following events:

•An interrupt request occurring coincidentally with the clearing of GIE.

•Another interrupt request happening during execution of the protected code.

•The interrupt service routine causing an error in the protected background process.

Such a rare combination would be di cult to reproduce and thus would be virtually impossible to debug.

To avoid this remote possibility of error, the instruction clearing GIE should be followed with a check that it really is clear. For example:

..... .....

Example 7.3

Interrupt handling anomalies can occur in PICs which do not shadow their general-purpose files registers between banks. We see from Fig. 4.6 on page 92 that all GPRs in the PIC16F84’s Bank 0 are shadowed in Bank 1; for instance File 20h and File A0h are the same. As an opposite example, the PIC16C74 has GPRs between File 20h…File 7Fh in Bank 0 and between File A0h…File FFh in Bank 1; a total of 192 bytes – as shown in Appendix B. These register files are bank specific; for instance File 20h is not the same

as File A0h.

The problem arises because the context at the beginning of the ISR will copy W and STATUS into memory in Bank 0 to Bank 3 depending on which bank the processor is in when the background code is interrupted.

190 The Quintessential PIC Microcontroller

If the core of the ISR subsequently switches Bank and then goes back to Bank 0 then an error may occur when restoring the context at the end of the ISR if the bank at this point is not that which the processor was in on entry. For example, if the background program was in Bank 1 at the time of interrupt and then moves to Bank 0, then the restoration at the termination of the ISR will retrieve the incorrect data from Bank 0. Discuss how this problem can be circumvented.

Solution

Microchip suggest two approaches to the context switching problem for cases where the ISR has to change banks and GPRs are bank specific. The first is to keep the background program in Bank 0 at any point of the code where the interrupt is enabled. Access to another bank can of course be made indirectly using the INDF file register – see page 109.

The alternative approach is to save the Working register in whatever bank the interrupt occurs, but the Status register always in Bank 0. When STATUS is retrieved at the end of the ISR, the entry bank state (that is RP1:0 in STATUS – see Fig. 5.1 on page 109) will be restored and the Working (and any other saved) register can then be pulled in from the bank they were actually saved in.

Program 7.4 uses this approach with context change entry and exit routines making no assumptions concerning the entry bank and which enters the core of the ISR code always in Bank 0. Here on entry the state of the Working register is copied into memory in the usual way ignoring the bank in which the processor enters. Although we have defined _work in the assembler as File 20h, if the PIC is in Bank 1 on entry the copy will actually be made at File A0h.

The next step is the more complex and depends on the entry bank state.

Bank 0

If the PIC is in Bank 0, as determined by the state of the Status register’s RP0 bit, then STATUS is copied into memory at file register _status in the normal way using the two instructions at IN_BANK0.

Bank 1

If the PIC is in Bank 1 (i.e. RP0 is logic 1) then RP0 is cleared thus moving the processor to bank 0. STATUS is then copied in Data memory at File 21h, that is _status. Before entering the core code, bit 5 of File 21h is then set to logic 1, restoring the copied version of the original state of RP0 out in memory. This means that on exit when STATUS is restored the PIC will move back into Bank 1.

The core code is always entered with the PIC in Bank 0. At the end of this code the programmer must ensure that the processor is back in Bank 0. In this situation restoring the context is done in the normal way, with STATUS being brought back from _status in Bank 0. With this done,

7. Interrupt Handling 193

Program 7.5 Coding the real-time clock ISR.

;The core code ******************************************************

;Task1

; Retrieve the context ***********************************************