AVR-Chat

I am using iccavr compiler for atmega 32

i want to use nested interrupt
inside  uart rxc isr .How can i implement it
.Should i have to do anything with the stack 
size.Plase suggest some c code.

Enabling interrupts from within an ISR, on humble microprocessors, is a very
bad idea. Can't you just process the UART RXC char (store in a buffer) and
quickly dismiss the interrupt - process the newly arrived char later in the
non-ISR code? This is the conventional way to do this. 

Otherwise, if you read the char and store it, then enable interrupts, you'll
be OK >IF< you exit this ISR before another uart interrupt happens. That's
hard to assure, since some other ISR may take the  CPU for some
indeterminate time.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of aswinefy2003
Sent: Monday, July 04, 2005 10:14 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] nested interrupts doubt

I am using iccavr compiler for atmega 32

i want to use nested interrupt
inside  uart rxc isr .How can i implement it
.Should i have to do anything with the stack 
size.Plase suggest some c code.




 
Yahoo! Groups Links

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.

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


perhaps you may not know my problem.I have a int1  routine which 
should be seved instantly for some critical issue .SO even if the 
controller is executing other isr,s or code ,it should respond 
instantly to int1 interrupt.That is it should have the top most 
priority. 
Perhaps you may not 
> handshake, and bail out.

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.

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.

Six hours to go on a critical delivery, and suddenly my Jtag is 
telling me that everything in the processor is $CD.
It claims to be able to set the fuses, and on readback they look 
fine, and it claims to be able to program and verify the device, but 
debugging is totally hosed.

Any ideas?

Dave VanHorn wrote:

>
> Six hours to go on a critical delivery, and suddenly my Jtag is
> telling me that everything in the processor is $CD.
> It claims to be able to set the fuses, and on readback they look
> fine, and it claims to be able to program and verify the device, but
> debugging is totally hosed.
>
> Any ideas?
>
DON'T PANIC !!

Take a 15 minute break.

Save everything.

Take it slow. Restart or even reboot the host PC.

Verify things through other means like AVR ISP.

and above all else don't panic

Mike

At 01:28 PM 7/5/2005, Mike Perks wrote:
>Dave VanHorn wrote:
>
> >
> > Six hours to go on a critical delivery, and suddenly my Jtag is
> > telling me that everything in the processor is $CD.
> > It claims to be able to set the fuses, and on readback they look
> > fine, and it claims to be able to program and verify the device, but
> > debugging is totally hosed.
> >
> > Any ideas?
> >
>DON'T PANIC !!
>
>Take a 15 minute break.

Looks like a bad processor. Different reboots gave me different 
values, but all internal SRAM, registers, etc would read the same value.
Program memory did read and write ok. I looked at the hex to verify.

Unfortunately, the cpu is an M128 in MLF package.

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

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

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

At 03:23 PM 7/7/2005, arhodes19044 wrote:
>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.

True, but you're pushing in the wrong direction.

>   As long as the ISR in question does not lock-out other vital interrupt
>processes while it is active

There's the key. Re-entrant interrupts are expensive to code, and god 
forbid you get into a deadly embrace with ISR2 waiting on something 
that almost happened in ISR 1 before it got interrupted by ISR2.


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

Long and hard experience behind that.

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

Sure. As long as you can assure that this is ALWAYS true.