Hi,

James Fitzsimons wrote:
<snip>
>I understand it is good practice to keep interrupt service routines short,
and use flags which are
>polled in themain loop. I am thinking about using this method for the
timer, and the serial port.
>The code would look something like:
>
>main()
>{
>    while (1)
>    {
>    if (timer_flag)
>        do something
>    }
>}
>
>interrupt void isr()
>{
>    if interrupt cause by timer
>        set timer_flag = 1;
>}
>and the same for the serial i/o...  is this good coding style for PIC's?
<snip>

Well, I beg to differ, the things is that no matter how you accomplish this
or that
there only are x amount of programming cycles available.
Yes true that ISR *normally* is time critical,
they also are intermittent in nature ( one never know exactely when an rx
irq fires for example ).

The really important thing to concider is:
What happens if ?
Let's say you do all irq handling inside the isr, for arguments sake lets
assume
we have one very timeconsuming isr handler, an ad reading triggers an FFT
calculation
and one fairly small trivial timer based counter.
The question I would ask myself is, 'What happens if the ad irq fires just
prior to
the timer ?' Analysing this and understanding your software will make it
clear that
although small and fast isr routines are normally preferred, there are no
such thing
as a free lunch. Even if you place the timeconsuming bit's outside the isr,
still there
must be enough of cycles to handle the data.
To have this clear divide that isr handlers always should be short is not
only wrong,
it could be misleading.

One recent project basiclly had everything inside the isr handlers, an
18C452 at 3.6864 Mhz
(+pll) running two uarts at 38400 baud with tx/rx buffers ( one was Maxim
3100 s/w SPI based )
an 24 bit ad ( FIR+IIR inside isr ), 80 segment LCD ( i2c-isr based ) etc
etc .
I had to make sure that worst case would not affect the operation, in this
case
the 24 bit ad( s/w spi ) FIR and IIR filtering was clearly most
timconsuming, however
quite infrequent ( 114 hz ), anyway in this case the entry+service+exit was
well below
one byte time on the internal communincation port ( no fifo ).

So, to answer your question, I think you will hear arguments for 'both
sides',
my personal advice would be, think through your s/w, understand it, what
makes it tick,
ask yourself 'what if?'. Then you'll find that although small isr are
perhaps preferred,
they normally take part in bigger schemes, data streams in, data is
processed, data streams out,
no matter where you place some the code the processing still has to place.
So in some cases
long timeconsuming isr can be prefered. ( dividing execution, by flags or
other mechanisms
could sometimes obfuscate the code ).

Anyway, just my personal opinion,

/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body