Mike Karas,

Thanks for the design input; in fact, I already have just that approach in place, as a modification to the more classical approach of having a main loop invoke a set of 'module driver' functions so as to provide them with occasional execution bandwidth; the extent of base-ISR queuing varies from project to project. Indeed, I had extended the scheme you spoke of by having a service function in the Idle module that ISRs could invoke to signify that the module's driver function should invoke (via returning to) the main loop instead of return to sleep, and had arranged for my periodic timer ISR to occasionally invoke that, so as to warrant a minimum execution frequency for the main loop.

The thing is, many of my peripherals are SPI based, and so I/O with them is intrinsically asynchronous; also, some of them require latencies between I/O operations, at the bus level, device level, and/or the operational level (for certain ops). Thus, the client of the I/O has to poll for completion. This unfortunately ripples upwards: that client's client must poll for _its_ completion, etc. While the classic main loop certainly addresses this, it does incorporate some amount of latency, and, more to the point here, more time out of Idle mode. And, the calculation of what constitutes an acceptible main loop minimum execution frequency becomes much more involved; further, the more conservative I am with that calculation, the higher the frequency goes, thus yet more time out of Idle. So, I thought that this time I would bite the bullet and go whole hog with the event driven approach.

Donald,

I am indeed worried about the case you describe, i.e. the possibility that, between SETB EA and MOV PCON,#1, the processor will take an interrupt, and the instruction following the ISR's RETI will be the MOV PCON,#1, and that base level processing will thus suspend until yet another interrupt occurs. Given as I have a periodic timer interrupt, it's not like things will grind to a total halt, but it can induce an unexpected delay in realtime processing; don't know yet if that'll have nasty consequences for my application, but there are certainly those that could have a really bad hair day...

David