Oleg Sergeev wrote:
-------------------------------
Yeah, you know, you know!

Yeah, I do know, I do know. :-)

I've seen it all before, but thanks for bringing it to our attention, just in case it wasn't "intuitively obvious to the casual observer" ;-)

That technique is not my first choice because of it's limitations. My preference is to always first choose a solution for the general case that has no limitations, then later on if optimizations are required, I'll go for saving a few cycles here and there (but still, maybe not there). You know, "make it work first, then make it fast".

Plus I'd still be in trouble disabling interrupts for as long as I may need. "Why the h*ll would you want do disable interrupts for any extended period", you ask? Well, I write lots of firmware for RF transmitters and receivers for folks. So, for example, in an RF transmitter, I have to disable interrupts while I blast out a long string-O-bits with precise timing. You see, often times, the choice of 8051 derivative is not mine to make, so I may not have the luxury of using one with timer subsystem assist for that precise timing requirement, and have to bit-bang the bitstream (yep, managing equal instruction cycle counts through every code path -- ugh!). The "reload only THn" technique means that I have to examine the current timer value to see if I can disable interrupts and transmit without risk of "losing" 256 or 512 (or more) ticks. That's about as much work as simply performing a reload that works for the general case, although admittedly, the work is performed in the non-ISR thread, which is good.

I can envision occasions when one would be tempted to use the "reload-only-THn" method, but for me, no thanks, I'll go for the limitation-free general solution first (but I do reserve the right to change it later). :-)