I would like to comment to the above reply posting to Dan.

There are many many examples of programs that all have various types of considerations. There are of course some types of "serial processing only" programs wherein the use of polled I/O may be the simplest to implement. On the otherhand there could very well be some types of programs of this type where use of interrupts would be essential. Take for example a program that continuoulsy receives UART input by polled I/O but once in a short while the processing time for the previous bytes extends just beyond the next character window and UART over-run can occur. Here a UART interrupt can help solve this problem, particularly if circular holding buffers are used to buffer the data.

I would like to comment that almost all embedded things I have worked on, that had any degree of complexity involved in the functions and algorithms, were most successful when I/O functions were coded in interrupt handlers using buffers and/or queues. Then through the use of a timer interrupt, to step a program through states, everything else is designed as time tick and/or I/O event driven state machines.

The net effect of this approach is that active task time of the processor is leveled out and averaged across the available bandwidth. This of course comes at a cost but I have found that cost to not normally be over say about 8->10% of processor bandwidth for a well designed system.

Many programmers that I have known over the years, that see the value of this type of design, will generally thus make all of their designs in this manner making full use of time sliced state machines and I/O interrupts. They do it because it is easier to predict the required performance level at the onset of design, easier to code, and easier to maintain. If some application gets underway and it turns out that the available bandwidth is not high enough it is also very easy to see how a higher processor frequency can help solve the throughput problem.

On the contrary, programs that are designed with the I/O acquisition tightly coupled to the program structure, tend to have spots in the execution flow where bandwidth is 100% utilized and then at other points where bandwidth utilization approaches just a few percent. These designs are invaribly harder to code and maintain......AND it is harder to port modular parts of the code to other programs. Higher or lower performance of processor power is also harder to determine if it can be utilized to solve bandwidth problems or lower power levels.

Michael Karas