Page 188 - Embedded Microprocessor Systems Real World Design

Remember, though, that interrupts make debugging more difficult. When you
set a breakpoint using a monitor program or emulator, interrupt inputs keep
coming. You cannot always single-step code when using interrupts because con-
tinuous interrupts keep the processor hung up in an ISR. And when something
goes wrong because a high-priority interrupt did not get the priority it needed, the
source of the problem can be very hard to find.
The polling loop is sometimes called the background loop because it is the lowest-
priority task-everything else can interrupt it. The background is executed when
no interrupts are being serviced. Designers sometimes assume that the polling loop
therefore is the worst place to put anything that needs priority attention. However,
keep in mind that a low-priority interrupt may be just as bad as the polling loop.
If servicing a device such as a UART in the polling loop means that the worstcase
stackup of interrupt service times will prevent the device from being serviced in
time, making the device a low-priority interrupt may be no better. Look carefully
in a case like this to see whether there is a basic throughput problem when inter-
rupts stack up.
In some cases, a device such as a UART may have a momentary problem with
interrupt service time stackup, but you know that this is a temporary and infre-
quent condition. In those cases, you may be able to solve the problem by using a
buffer such as a FIFO buffer. Our example UART, with either an internal or exter-
nal FIFO buffer, may receive several bytes before the polling loop gets to it. If you
really (really, really) know that the problem is a temporary one, the polling loop
should be able to process the data before the FIFO buffer fills up. However, remem-
ber that when the software gets to the UART, it will take longer to process the data
since there are more bytes. Make sure the throughput problem really is temporary
and that the polling loop will get through with its delayed processing before the
next crunch occurs.

lnterrupts and the Real World

Chapter 4 briefly mentioned switch debouncing. The algorithm for that was as
follows:

Switch closure detected
Wait 30ms.
Check switch again. If open, it was bounce on opening. If still closed, it was a
valid switch closure.

Someone who is new to embedded systems and who needs to debounce a switch
might be tempted to just put a 30ms delay into the code. This would produce an
unacceptable delay in most real-time systems. A more appropriate way to do this,
now that we have looked at interrupts, is as follows:

Interrupts in Embedded Systems 169