> -----Original Message-----
> From: K=FCbek Tony [SMTP:tony.kubek@FLINTAB.COM]
> Sent: Monday, February 04, 2002 1:34 PM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      Re: [PIC]: hardware and software design question
>=20
> Hi,
>=20
> 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 =3D 1;
> >}
> >and the same for the serial i/o...  is this good coding style for =
PIC's?
> <snip>
>=20
> 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 ).
>=20
> 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.
>=20
I think this question is of great relevance to the 14 bit core PIC's =
that
generaly speaking can't use re-entrancy (at least not with a lots of
software overhead).  This means that whilst the PIC is executing code =
within
the ISR, all other interrupts are blocked.  If you have a lower =
priority
interrupt that takes a long time to handle you should ALWAYS put it in =
the
main code loop and use a flag to start it's execution from within the =
ISR.
This way, the lower priority code is able to be interrupted by other =
higher
priority sources.

Regards

Mike

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