AVR-Chat

Well, no it was more the way I had said it.  The 1 hz interrupt 
currently does more than just set flags.  And it gives me angst.

The idea is, as stated before, is cooperative multitasking.  THere 
is no absolute reason why interrupt code can not be pretty long and 
complex, just so it completes before it needs to execute again.  As 
long as the ISR in question does not lock-out other vital interrupt 
processes while it is active (GCC "interrupt" vs "signal"), then 
only "conventional wisdom" indicates that the ISR is too lengthy.

In my case, as the project has evolved, I have a better and more 
complex "waiting-for-input" function where it services flags set in 
interrupts.

So, I think I will be able to offload the heavy duty stuff from the 
ISR.  Just because "conventional wisdom" prefers it that way.

My point in this thread was to point out WHY conventional wisdom 
says that ISRs should be SHORT, SHORTER or SHORTEST. but that the 
real limit is re-entrancy, and any length code is possible within 
the overall limits of the rest of the application andits demands.



-Tony

--- In AVR-Chat@yahoogroups.com, "stevech" <stevech@s...> wrote:
> But- the idea of interrupts is to do the minimum, set a flag, 
increment a
> counter, or some such and *immediately* dismiss the interrupt 
without
> lingering. Perhaps that's what you are doing, rather than how you 
said it,
> below.
> 
> 
> -----Original Message-----
> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] 
On Behalf
> Of arhodes19044
> Sent: Wednesday, July 06, 2005 7:57 PM
> To: AVR-Chat@yahoogroups.com
> Subject: [AVR-Chat] Re: nested interrupts doubt
> 
> "why not set a flag....?"  Well, If I did it right, I probably 
> could.  I can have the 1 second interrupt do the math, and store 
> some global variables.  Then have the waiting-for-input foreground 
> task fire the data to the display.
> 
> As soon as I wire up the second parallel display to another port 
on 
> the 128, I will be able to see what works best.
> 
> "cooperative multitasking"  Yeah, that is the word for it!
> 
> -Tony
> 
> --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> 
wrote:
> > At 11:33 AM 7/5/2005, arhodes19044 wrote:
> > >I agree with brain bashing.  BUT.....
> > >
> > >It feels like I bashed my brain as I tried to follow these 
rules,
> > >and I eventually decided that I MUST have ONE item in one of my
> > >applications that I MUST do from within an "interrupt"
> > >
> > >But there is another display which does not need updating very
> > >often, but it MUST be updated every so often (I am using one
> > >second).  It will take a "long" time (for an interrupt), but 
much
> > >less than a second.  So, re-entrancy is not an issue.  Other
> > >critical interrupts will occur and must be processed in the 
> interim,
> > >but the foreground task can probably wait.
> > 
> > So why not set a flag, saying that it is time to update the 
second 
> > display, and let a foreground routine do that, while the other 
> ints happen?
> > If it's really huge, you might need to break it up into 
sections, 
> so 
> > that other foreground tasks can complete.
> > Avoid like the plague, any "sit and spin" delays.
> > 
> > 
> > >I do this to create pseudo multitasking, but without time-
slicing.
> > >For this to work, the interrupt needs to complete fast enough to
> > >avoid re-entrancy (i.e. less than a second), but more 
importantly,
> > >it needs to be fast enough to avoid being too obvious to the 
user 
> of
> > >the foreground task.
> > 
> > Cooperative multitasking, I use it all the time.
> 
> 
> 
> 
>  
> Yahoo! Groups Links