Suppose you have a microprocessor or microcontroller that needs to perform an action when it notices that a button is pressed.
The first approach is for the program to enter a cycle that does nothing except to see if the button has changed and by performing the required action.
In some cases, a second approach would be to program the hardware to trigger an interrupt when a button is pressed, assuming the button is connected to an input that is connected, so it can cause an interrupt.
The third approach is to set the timer to interrupt the processor at a certain speed (say, 1000x / second) and the handler for this interrupt checks the state of the button and affects it.
The first approach uses wait-wait. It can provide a very good response time to one particular stimulus by fully customizing everything else. The second approach uses an interrupt caused by events. It often offers a slightly slower response time than wait, but allows the processor to do other things while waiting for I / O. It can also allow the processor to go into low power mode until the button is pressed. The third approach will offer a response time that is much inferior to the other two, but will be used even if the hardware does not allow you to initiate an interrupt by pressing a button.
In cases where a fast response is required, it is often necessary to use an interrupt caused by events or a wait. In many cases, however, the survey approach may be the most practical. The hardware may not exist to support all the events that may be of interest, or the number of events that interest you may well exceed the number of available interrupts. In addition, it may be desirable for certain conditions to generate a delayed response. For example, suppose everyone wants to count the number of times the switch fires, provided that the following criteria are met:
- Each legitimate switching event will consist of an interval from 0 to 900us (microseconds), during which the switch can be arbitrarily closed and reopened, followed by an interval of at least 1.1 ms, during which the switch remains closed, followed by an interval of 0 to 900US, during which the switch can randomly open and close, followed by an interval of at least 1.1 ms, during which the switch will be open.
- The software should ignore the switch state for the 950us after any unoccupied opening or closing of the switch.
- The software is allowed to arbitrarily count or ignore switch events that occur outside of the above blanking interval, but which are less than 1.1 ms.
- The report calculated by the program must be valid for 1.99 ms when the switch is stable "closed".
The easiest way to ensure that this requirement is met is to monitor the status of the switch 1,000x / second; if it is “closed” when the previous state is “open”, increase the counter. Very simple and easy; even if the switch opens and closes in all sorts of strange ways, during the 900us preceding and following a real event, the software does not care.
One could use a switching interrupt with an input signal together with a timer to respond more quickly to the switch input, fulfilling the required blanking requirement. Initially, the input would be armed to start the next time the switch closes. Once the interrupt has been started, the software will disable it, but set a timer to trigger the interrupt after 950us. Once this timer has expired, it will trigger an interrupt, which would cause the interrupt to light up the next time the switch is "open". This interrupt, in turn, will disable the interrupt of the switch and set the timer for the 950us again, so interrupting the timer will again enable the interrupt of the switch. Sometimes this approach can be useful, but the software is much more complicated than the simple surveyed approach. When a timer-based approach is sufficient, it is often preferable.
On systems that use a multi-tasking OS rather than direct interrupt, many of the same principles apply. Periodic polling of I / O will spend some CPU time compared to code that the OS will not work until certain events occur, but in many cases both the response time of the event and the amount of time wasted when it does not no event would be acceptable when using a periodic survey. Indeed, in some buffered I / O situations, periodic polling can be quite effective. For example, suppose one receives a large amount of data from a remote machine through a serial port, no more than 11,520 bytes will arrive per second, the device will send up to 2K of data before the last confirmed packet, and the serial port will receive a 4K input buffer. While it is possible to process data using the “received data”, it can be just as efficient to simply check the 100x / second port and process all received packets to this point. Such a survey would be a waste of time when the remote device did not send data, but if the expected data was expected, it might be more efficient to process it in chunks of about 1.15 K than to process every small piece of incoming data as soon as it arrives.