Haphazard? Not at all. I think you might be assuming that all systems need to do I/O concurrently with other processes. That's not always the case. The choice between polled and interrupt-driven I/O is a matter of designing to meet requirements. If your requirements dictate that I/O and other processes run concurrently, you pretty much have no choice but to commit some RAM for transmit and/or receive buffers for interrupt-driven I/O. On the other hand if your requirements allow for more of a single-threaded approach, you can allocate those buffers temporarily, if at all. By "if at all", I mean that some systems are entirely state-driven and don't buffer anything; they examine a received byte and transition to the next state defined by that byte's value (receive errors or timeouts would cause a different transition).

Are you using ad hoc free-flowing (so to speak) communications, or are you using some kind of packet protocol? Interrupt-driven might be better for the former, whereas if your system is designed around the packets in the latter, it may have nothing at all to do until packets are exchanged, in which case interrupt-driven doesn't buy you anything.


Yep, if some kind of concurrency is necessary.

Don't get me wrong, I'm not saying not to use interrupts. What I am saying is that using polling is just as legitimate a design choice as using interrupts. Interrupt-driven I/O is not always the best way to go and neither is polling.

When I/O speeds reach a certain threshold, the sheer overhead of servicing interrupts introduces too many cycles to be able to keep up. A couple of months ago, I did a packet-based comms design with the data rate at 13Mbps -- not a heck of a lot of time to do much else but try to keep up, and not enough headroom for ISRs, so I did it by polling. And by the way, the system had absolutely nothing else to do until it received a packet.