Herb,

Good example! - as without question Microsoft makes the
world's worst software, too.
 
Here's why I think this way:

1. Significant problems can occur when the INSIDE INT code
runs longer than the routine timer event. For example, if you
interrupt every 1ms, and your interrupt code exceeds that
frequently, the  attempt to "catch up" can be a problem.

2. Detecting interrupt overruns can be difficult to do. It is much
safer to set flags and execute the needed code in the main loop.

3. INT adds a lot of overhead. If all you need to do is set a few flags
in global registers, there is no need to save W, status, FSR, or PClath
if all you need to do is set a few flags.

--Bob

Herbert Graf wrote:

>On Tue, 2005-02-01 at 12:26 -0700, Bob Axtell wrote:
>  
>
>>General note, my thoughts:
>>
>>I agree with Olin's view: do as little as possible during the interrupt 
>>itself. Except
>>for serial characters being received (I stuff those immediately), just 
>>set up flags
>>so that they can be serviced in the main code in a prioritized manner.
>>    
>>
>
>Really it depends on the app, how the programmer thinks, and what feels
>most "natural".
>
>There are cases where doing "heavy stuff" in the interrupt MIGHT be a
>good idea. Heck I've had cases where doing EVERYTHING in the ISR and
>having the main program consist of just "goto start" all the time made
>sense.
>
>A good example outside of the embedded world is windows programs, most
>are pretty much completely "interrupt" driven.
>
>However, in general, an ISR is meant to be a "quick" thing, something
>that needs to be done at a certain time quickly so that it doesn't
>interfere with the "main" program. But I see NO reason that if you
>understand the implications doing heavy stuff in the ISR is "wrong".
>TTYL
>
>
>-----------------------------
>Herbert's PIC Stuff:
>http://repatch.dyndns.org:8383/pic_stuff/
>
>  
>


-- 
Note: To protect our network,
attachments must be sent to
attach@engineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist