there are no other interrupts which may delay the call to the ISR) is generally stated in the manual. Of course, a minimum latency is unavoidable since at least the PC must be saved, but saving registers on the stack may prolong the latency unnecessarily, so a comparison of different controllers may be useful. If the latency is an issue, look for controllers which can be clocked fast (high oscillator frequency), have fast instructions (only one or few oscillator cycles), and do not save registers on the stack. After all, the application programmer can save the necessary registers in the ISR anyway, without spending time on saving unused registers.

2.5.3Interrupt Service Routine

The interrupt service routine contains the code necessary to react to the interrupt. This could include clearing the interrupt flag if it has not already been cleared, or disabling the interrupt if it is not required anymore. The ISR may also contain the code that reacts to the event that has triggered the interrupt. However, the decision what to do in the ISR and what to do in the main program is often not easy and depends on the situation, so a good design requires a lot of thought and experience. Of course, we cannot instill either of these things in you, but we can at least help you get on your way by pointing out a few things you should consider.

In the following examples, we will sometimes mention concepts that are explained in later sections. So if you do not understand something, just skip over it, and read it again after you have worked through the rest of the material.

Interrupt or Polling

First of all, you face the decision of whether you should poll or whether you should use an interrupt. This decision is influenced by several factors. Is this a large program, or just a small one? Are there other things to do in the main loop which are not related to the event you want to service? How fast do you have to react? Are you interested in the state or in the state change?

As an example, consider a button that is actuated by a human operator. As long as the button is pressed, a dc motor should be active. At a first glance, this looks like a polling solution, because we are interested in the state. However, if we initially check the state, we can then infer the current state from its state changes, so this is not a valid argument. In fact, the choice mainly depends on what else is going on in your application. If you have nothing else to do, you might consider using interrupts and putting the controller into a sleep mode in main. Bouncing of the button is not really a problem here, the user will not notice if the dc motor is turned off once or twice in the first few ms of its operation. If the main program has things to do, but not too many of them, then polling is better because of its simplicity. There is no need to worry about the inaccuracy of your solution. After all, both the human and the dc motor are not very precise instruments, so the timing is not critical. Checking every couple of milliseconds will easily be enough, and you can fit a lot of other code into a period of 1-10 ms.

Now consider a button, again operated by a human, that should advance a stepper motor by one step whenever it is pressed. This time you are interested in the state change (from unpressed to pressed). Although this looks like interrupt territory, polling may still be a good choice here: The human will certainly press the button for at least 10 ms, probably for a lot longer, and will not notice if the stepper motor reaction is delayed by a couple of ms. Plus, if you poll with a period of a couple of ms, you will not encounter bouncing effects, which would have to be filtered out in the interrupt solution. On the downside, since you should not react twice, you have to store the last read state of the button and should only advance the stepper motor if the state has changed from unpressed to pressed.

Finally, assume that the impulses to advance the stepper motor come from a machine and are short. Here, interrupts are definitely the best solution, first because there is no bouncing involved, and mainly because polling may miss the short impulse, especially if there is other code that has to be executed as well.

To summarize, indications for using interrupts are

•event occurs infrequently

•long intervals between two events

•the state change is important

•short impulses, polling might miss them

•event is generated by HW, no bouncing effects or spikes

•nothing else to do in main, could enter sleep mode

whereas polling may be the better choice if

•the operator is human

•no precise timing is necessary

•the state is important

•impulses are long

•the signal is noisy

•there is something else to do in main anyway, but not too much

Reaction in ISR or in Task

The next decision you have to face is where to react to the event, in the ISR or in a task. The obvious choice would be the ISR, since it is called in response to the event, but this may not always be a wise decision: After all, the ISR interrupts the tasks, so if the ISR is long, this means that the tasks will get delayed for that time. Although tasks tend to do the routine stuff and can suffer short interruptions, it is nevertheless generally not a good idea to let them starve for a longer period. So you should think about the effect a delay will have on your tasks.

If your program has to react to several interrupt conditions, you should also consider the effect of a delay on them. Note that the fact that an interrupt occurs seldomly does not imply that the timing is not important. For example, if you have to multiplex a numeric display, which means that you sequentially turn on one digit at a time, you will probably use a timer for the period and its ISR will be called every few ms, which is quite a long time. Nevertheless, an additional delay, especially if it occurs irregularly, may well be unacceptable, it can make the display flicker or let random digits appear brighter than others. Although the effect is interesting and may sometimes even look cool, it is undesirable.

Before you decide to transfer the reaction to a task, however, there are a few things to consider as well. The first is how to notify the task that the event has occured. Within an operating system, you will most likely send an event, or put data in a queue, or something similar. Without an operating system, you are reduced to using flag variables, which you set in the ISR and check (and clear) in the main program. Note that this does not necessarily imply that you have to poll the flag variable – after all, you probably have not chosen interrupts just to basically poll the IF in main anyway. The good news is that you do not have to, as long as the controller provides a sleep mode that will be terminated by the interrupt in question. In this case, you can enter this sleep mode in main in the