AVR-Chat

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"

In my application, I have 2 displays.  The main display gets updates 
as fast as the data comes in and the processor is available.  It 
gets updated via a waiting for user input function.  Works great.

There are external interrupts that occur about 100hz.  These are 
seviced really fast.

I have an internal real time clock that triggers every millisecond, 
and this is fast to service.

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, I created a software triggered interrupt in INT7.  This occurs 
at 1hz based on the realtime clock and is triggered by the clock 
interrupt, but is I made INT7 interruptable ("interrupt" instead 
of "signal").

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.

A hundred milliseconds is probably tolerable to the user, but 200 
probably is not.

I have not fully implemented the 1hz interrupt, but so far it is not 
detectable despite a moderate amount of heavy floating point 
operations.  The un-implemented stuff will display data to the 
display with 4 bit parallel interface.  No more than 32 characters 
total and maybe as many cursor control characters.

So, depending on your needs, and the relative frequency of various 
interrupts, certain interrupt-driven lengthy functions may be 
possible.  BUT re-entrancy must be considered and prevented if it is 
a close call.

-Tony





--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> At 12:13 AM 7/5/2005, aswinefy2003 wrote:
> >I am using iccavr compiler for atmega 32
> >
> >i want to use nested interrupt
> >inside  uart rxc isr .How can i implement it
> 
> First, take your brain out of your skull, and bash it with a 
mallet...
> 
> Nested interrupts are a very bad idea.
> If you think you need to do this, you almost certainly are trying 
to 
> run WAY too much code in the ISR.
> 
> ISRs should react to the event, and exit.
> Let the foreground code pick up the data and decide what to do 
with it.
> 
> Drop your char in a buffer, check buffer status for asserting 
> handshake, and bail out.