Scornful? Really? Really????If you believe this, then I can understand why you're a bit scornful.
Just here talkin' man. No emotional involvement whatsoever.
Then I made the serious error in assuming that your main program might actually have to do something as a result of that interrupt! I apologize!But it's not true at all. The main() routine and its subroutines can be doing whatever they need to do when the one and only interrupt fires. Why wouldn't they?
My gosh, it's worse than I thought! You're concerned about the impact of interrupt overhead (I assume in terms of the branch/return and context save/restore), yet you poll multiple devices in an interrupt whether service is needed or not!Perhaps you haven't fully understood that the one and only interrupt checks flags to see if the other peripherals (which with other software schemes would get their own interrupts) are needing service. Of course this can't happen at the main() level. The two caveats are that the peripheral flags must be checked often enough to do whatever they need, and the "jackpot condition", when every peripheral wants service, mustn't take longer than one clock interval.
So, let's get this straight:
Say you've got a SPI EEPROM, to which you want to read/write 1024 bytes in a reasonable amount of time, so you set you SPI clock to say, 500khz, for a total data transfer time of 16ms (ignore write time, please).
The tx buffer will empty every 16 microseconds, or 80 instruction cycles at 20Mhz.
For your scheme to work, your 1 interrupt will need to occur, on average, every 16 microseconds, whether your SPI is operating or not.
Subsequently, all your polling and servicing must be complete within 80 instruction cycles, or your data rate will drop (during SPI read/write), first to 50%, then to 33%, and so on.
The timing issues compound rapidly when you have multiple things going on at once. Typically, I'll have a main system clock, a EUSART, a SPI or IIC (with multiple devices), keypad, a direct drive LCD (whose timing simply will not wait for you to get around to it) or a multiplexed LED display, one or more periodic signal to synchronously drive the analog components, multiple channels of A/D synchronized with the aforementioned driving signal, a sound generator driving multiple tones to a speaker, multiple PWMs, etc.
Trying to tie this all together on 1 interrupt source, and making it work reliably and predictably is my idea of physical and mental torture!
And don't tell me to operate my EEPROM in the main loop! I refuse to halt my code for anything for 16ms + cumulative write times!
OK, I get it. I spend my time writing code, you spend yours arranging it.However you arrange things, that's always going to be the worst case. But as I said, I claim my method is most efficient there, because the cost of entering and leaving the interrupt only has to be paid once.
I do this all the time, and usually more than one device. The magic is in the hardware. As I mentioned somewhere previously, lots of the PIC hardware is double buffered, the the SPI, EUSART, PWM, CCPs, etc. If I need an accurate output signal, where no jitter is tolerable, I will use a built-in hardware solution, such as the special event trigger, also tied to an interrupt. It is difficult (actually, kludgey), but not impossible, to create a jitter free signal in any other way (without using additional hardware).How about considering the situation MrChips brought up, where there's some device that needs service at an exactly regular interval but there are other devices that also have to be dealt with? If it's possible to solve that problem with a single interrupt, shouldn't it be possible to use the same technique always?
I do not deny that what you do works. You wouldn't be here debating this if it didn't. My point is that you will never get close to 100% utilization of any particular silicon you use. Maybe you don't need to. I often do.