AVR-Chat

"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.