"Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message 
news:1166118135.807907.291650@j72g2000cwa.googlegroups.com...
>
> Rufus V. Smith wrote:
>
>> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message
>> news:1166104313.478604.162220@f1g2000cwa.googlegroups.com...
>> >
>> > karthikbg wrote:
>> >
>> >> Hi,
>> >>
>> >> 1)  I have 200 interrupts and the corresponding Interrupt service
>> >> routines for those.
>> >>
>> >> ISR ()
>> >> {
>> >>    If (INTERRUPT_FLAG == 1)
>> >>         DO_ISR_ACTIVITY
>> >>    INTERRUPT_FLAG = 0;
>> >> }
>> >>
>> >> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
>> >> interrupt gets fired, but not handled as it is at the end of ISR. How
>> >> to avoid this.
>> >> But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
>> >>
>> >> So, one of the 200 interrupts does not get executed sometimes.
>> >> How to avoid the above problem ?
>> >>
>> >> 2)   Further, i do suspect that an interrupt can come in the middle of
>> >> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
>> >> interrupt being left un-attended.
>> >> If this is the case, how to check this as there are 200 interrupts ?
>> >
>> > How about something like this:
>> >
>> > ISR()
>> > {
>> >   if( interrupt_flag )
>> >   {
>> >      interrupt_flag = 0;
>> >      do_isr_activity();
>> >   }
>> > }
>> >
>> > That way, when a new interrupt comes in while you're processing the old
>> > one, the interrupt flag will be set again. This assumes
>> > 'do_isr_activity()' can handle the case where multiple interrupts have
>> > been received.
>> >
>>
>> This will handle receiving multiple interrupts
>> during interrupt processing.
>>
>> ISR()
>> {
>>    static int unhandled = 0;
>>
>>    if (unhandled)
>>    {
>>         unhandled++;  // buffering interrupt counts
>>         interrupt_flag = 0;
>>    }
>>    else
>>    {
>>         unhandled++;  // first interrupt
>>         interrupt_flag = 0;
>>         while (unhandled) // handle interrupt, and others that may come 
>> in
>>         {
>>            do_isr_activity();
>>            unhandled--;
>>         }
>>     }
>> }
>>
>> Rufus
>
> Usually, the ISR isn't reentrant, as it disables any further
> interrupts, so this wouldn't do anything.
>
> I was referring to a situation where there are many h/w interrupts, but
> where it was okay to occasionally miss one, for instance if the
> peripheral has a FIFO.
>
> If every interrupt is important, the OP needs to make sure the ISR is
> finished before the next interrupt is received.
>

Oh,  I thought

    interrupt_flag = 0;

effectively would re-enable that interrupt, so the routine could
possibly be re-entered at that point, just counting and re-enabling.

Rufus

"FreeRTOS.org" <non.given@hotmail.con> wrote in message 
news:hxfgh.16138$k74.5542@text.news.blueyonder.co.uk...
>
> "Rufus V. Smith" <nospam@nospam.com> wrote in message 
> news:45817976$0$20219$88260bb3@news.teranews.com...
>>
>> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message 
>> news:1166104313.478604.162220@f1g2000cwa.googlegroups.com...
>>>
>>> karthikbg wrote:
>>>
>>>> Hi,
>>>>
>>>> 1)  I have 200 interrupts and the corresponding Interrupt service
>>>> routines for those.
>>>>
>>>> ISR ()
>>>> {
>>>>    If (INTERRUPT_FLAG == 1)
>>>>         DO_ISR_ACTIVITY
>>>>    INTERRUPT_FLAG = 0;
>>>> }
>>>>
>>>> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
>>>> interrupt gets fired, but not handled as it is at the end of ISR. How
>>>> to avoid this.
>>>> But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
>>>>
>>>> So, one of the 200 interrupts does not get executed sometimes.
>>>> How to avoid the above problem ?
>>>>
>>>> 2)   Further, i do suspect that an interrupt can come in the middle of
>>>> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
>>>> interrupt being left un-attended.
>>>> If this is the case, how to check this as there are 200 interrupts ?
>>>
>>> How about something like this:
>>>
>>> ISR()
>>> {
>>>   if( interrupt_flag )
>>>   {
>>>      interrupt_flag = 0;
>>>      do_isr_activity();
>>>   }
>>> }
>>>
>>> That way, when a new interrupt comes in while you're processing the old
>>> one, the interrupt flag will be set again. This assumes
>>> 'do_isr_activity()' can handle the case where multiple interrupts have
>>> been received.
>>>
>>
>> This will handle receiving multiple interrupts
>> during interrupt processing.
>>
>> ISR()
>> {
>>   static int unhandled = 0;
>>
>>   if (unhandled)
>>   {
>>        unhandled++;  // buffering interrupt counts
>>        interrupt_flag = 0;
>>   }
>>   else
>>   {
>>        unhandled++;  // first interrupt
>>        interrupt_flag = 0;
>>        while (unhandled) // handle interrupt, and others that may come in
>>        {
>>           do_isr_activity();
>>           unhandled--;
>>        }
>>    }
>> }
>>
>> Rufus
>>
>
>
> Reading and writing unhandled in a nested interrupt?  Is write access 
> atomic?
>

I make the assumption here that increments/decrements/tests of int's are 
atomic.
Perhaps a comment to that effect should be added to alert a developer for 
whom this is not the case.

cbarn24050@aol.com wrote:
> karthikbg wrote:
>
> > Hi,
> >
> > 1)  I have 200 interrupts and the corresponding Interrupt service
> > routines for those.
> >
> > ISR ()
> > {
> >    If (INTERRUPT_FLAG == 1)
> >         DO_ISR_ACTIVITY
> >    INTERRUPT_FLAG = 0;
> > }
> >
> > When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
> > interrupt gets fired, but not handled as it is at the end of ISR. How
> > to avoid this.
> > But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
> >
> > So, one of the 200 interrupts does not get executed sometimes.
> > How to avoid the above problem ?
> >
> > 2)   Further, i do suspect that an interrupt can come in the middle of
> > 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
> > interrupt being left un-attended.
> > If this is the case, how to check this as there are 200 interrupts ?
> >
> > Tonnes of Thx in advans,
> > Karthik Balaguru
>
> Without hardware information its impossible to answer. On most
> processors the isr is entered because the interrupt flag has been set
> so there is no requirement to check it again. If you clear the flag at
> the start of the isr then you wont miss an interrupt that occurs during
> the isr, the hardware will just rerun the isr. You would miss then if
> there were 2 or more occuring. Correctly prioritising will solve most
> problems. Later in this thread you mention software interrupts, you
> cannot get this sort of problem with those as their code generated.


I am using Vxworks with PowerPC.
I Need to handle interrupts that may occur when the other interrupt is
being handled.(Nested Interrupts).
I find that sometimes , one of the interrupt gets lost and the
corresponding alarm gets
generated as that interrupt got skipped off. 

Regards,
Karthik Balaguru

karthikbg wrote:

> Hi,
>
> 1)  I have 200 interrupts and the corresponding Interrupt service
> routines for those.
>
> ISR ()
> {
>    If (INTERRUPT_FLAG == 1)
>         DO_ISR_ACTIVITY
>    INTERRUPT_FLAG = 0;
> }
>
> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
> interrupt gets fired, but not handled as it is at the end of ISR. How
> to avoid this.
> But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
>
> So, one of the 200 interrupts does not get executed sometimes.
> How to avoid the above problem ?
>
> 2)   Further, i do suspect that an interrupt can come in the middle of
> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
> interrupt being left un-attended.
> If this is the case, how to check this as there are 200 interrupts ?
>
> Tonnes of Thx in advans,
> Karthik Balaguru

Without hardware information its impossible to answer. On most
processors the isr is entered because the interrupt flag has been set
so there is no requirement to check it again. If you clear the flag at
the start of the isr then you wont miss an interrupt that occurs during
the isr, the hardware will just rerun the isr. You would miss then if
there were 2 or more occuring. Correctly prioritising will solve most
problems. Later in this thread you mention software interrupts, you
cannot get this sort of problem with those as their code generated.

karthikbg wrote:

> Hi,
> 
> 1)  I have 200 interrupts and the corresponding Interrupt service
> routines for those.
> 
> ISR ()
> {
>    If (INTERRUPT_FLAG == 1)
>         DO_ISR_ACTIVITY
>    INTERRUPT_FLAG = 0;
> }
> 
> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
> interrupt gets fired, but not handled as it is at the end of ISR. How
> to avoid this.
> But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
> 
> So, one of the 200 interrupts does not get executed sometimes.
> How to avoid the above problem ?

This is the classic shared data problem. The solution is to ensure the
INTERRUPT_FLAG = 0; operation is atomic i.e cannot be interrupted once
started. There are two ways to do this. The first is to use an atomic
microprocessor instruction rather than a C statement which might consist of
several microprocessor instructions. The second is to disable interrupts
just before clearing the flag and enable them immediately after. The first
method is preferable IMV.


> 
> 2)   Further, i do suspect that an interrupt can come in the middle of
> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
> interrupt being left un-attended.
> If this is the case, how to check this as there are 200 interrupts ?
> 

Depends on the micro. Some will store the fact the interrupt occurred and
service it next time interrupts are enabled. Others will just ignore and
lose it. This is why the first rule of real time is keep interrupt routines
as short as possible.Think about moving some of the functionality of the
ISR out into the background.

Ian

"Michael N. Moran" <mike@mnmoran.org> wrote in message 
news:SZvgh.1109$Cv1.169@bignews6.bellsouth.net...
>
> Just nit-picking but ... deep buffering only helps absorb
> bursty activity, allowing the processing of data bursts to
> be deferred. However, the overall "average" data rate cannot
> exceed the ability of the system to process the data without
> the data buffer overflowing.
>
> Just stating the obvious ;-)

I agree 100%, of course.  I did try to mention this separately.  I wrote:

> Additonally, the ISR typically has to "consume" at a faster rate than the 
> interrupt source can "produce".

Believe it or not, I've had colleagues earlier in my career who failed to 
get the point that you made above. 

David T. Ashley wrote:

> What this means in practice is that it is fairly rare to have a system where 
> repeating the ISR body more than once or twice has an effect on performance. 
> If the system meets its real-time constraints to begin with (specifically, 
> interrupt latency), then when the ISR begins to run, there can't be more 
> than one or two characters queued up (in the case of a UART).  If such a 
> scenario were possible, it contradicts a prudent real-time design.
> 
> There are exceptions, of course.  A _deeply_ buffered peripheral violates 
> this rule of thumb.  This allows for a large interrupt latency.

Just nit-picking but ... deep buffering only helps absorb
bursty activity, allowing the processing of data bursts to
be deferred. However, the overall "average" data rate cannot
exceed the ability of the system to process the data without
the data buffer overflowing.

Just stating the obvious ;-)

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

On 14 Dec 2006 19:01:53 -0800, "karthikbg"
<karthik.balaguru@lntinfotech.com> wrote:

>
>I use nested interrupts, so it is not possible to disable the
>interrupts at the start of the ISR
>and restoring at the end of the ISR.
>Even though, we make the 'do_isr_activity()' short and simple, how to
>protect it when an interrupt arrives in that short span of time of
>execution of 'do_isr_activity()'.

The need for nested interrupts is a sign of too long interrupt service
routines. How long are your ISRs ? 10, 50 200 or 1000 machine
instructions ?

What kind of hardware is used ? Is the interrupt requests inputs edge
sensitive or level sensitive ? If level sensitive, is the interrupt
request pulse shorter than the worst case ISR latency, i.e. the
interrupt request may be removed before being handled. Are there any
hardware to prioritise the 200 interrupt requests or are they all ORed
into a single interrupt request pin, and if so, how du you know which
interrupt source is active ? 

Avoiding nested interrupt by disabling interrupts during an ISR is not
a bad idea, provided that the ISR is _short_ (say 10-20 instructions)
and that the hardware retains the interrupt request from an other
source, when an other interrupt source is being serviced. When the
first ISR returns and restores the stack, it is again interrupted by
the other interrupt source, which had issued the request during the
service of the first ISR. A hardware prioritised interrupt request
system will ensure that the _next_ ISR executed after the current
active ISR is the one with the highest priority (and provide the
proper interrupt vector), even if the request was the last request
activated during the execution of the current ISR.

With such a huge number of interrupt request sources, the hardware
_must_ be designed to properly manage the large number of requests.
Without proper hardware, no software tricks are going to make the
system reliable. It may work in most cases, but it does not work in
_all_ situations.

Paul
 

karthikbg wrote:

> Arlet wrote:
> > Rufus V. Smith wrote:
> >
> > > "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message
> > > news:1166104313.478604.162220@f1g2000cwa.googlegroups.com...
> > > >
> > > > karthikbg wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> 1)  I have 200 interrupts and the corresponding Interrupt service
> > > >> routines for those.
> > > >>
> > > >> ISR ()
> > > >> {
> > > >>    If (INTERRUPT_FLAG == 1)
> > > >>         DO_ISR_ACTIVITY
> > > >>    INTERRUPT_FLAG = 0;
> > > >> }
> > > >>
> > > >> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the
> > > >> interrupt gets fired, but not handled as it is at the end of ISR. How
> > > >> to avoid this.
> > > >> But, the clearing of the 'INTERRUPT_FLAG = 0' is required.
> > > >>
> > > >> So, one of the 200 interrupts does not get executed sometimes.
> > > >> How to avoid the above problem ?
> > > >>
> > > >> 2)   Further, i do suspect that an interrupt can come in the middle of
> > > >> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that
> > > >> interrupt being left un-attended.
> > > >> If this is the case, how to check this as there are 200 interrupts ?
> > > >
> > > > How about something like this:
> > > >
> > > > ISR()
> > > > {
> > > >   if( interrupt_flag )
> > > >   {
> > > >      interrupt_flag = 0;
> > > >      do_isr_activity();
> > > >   }
> > > > }
> > > >
> > > > That way, when a new interrupt comes in while you're processing the old
> > > > one, the interrupt flag will be set again. This assumes
> > > > 'do_isr_activity()' can handle the case where multiple interrupts have
> > > > been received.
> > > >
> > >
> > > This will handle receiving multiple interrupts
> > > during interrupt processing.
> > >
> > > ISR()
> > > {
> > >    static int unhandled = 0;
> > >
> > >    if (unhandled)
> > >    {
> > >         unhandled++;  // buffering interrupt counts
> > >         interrupt_flag = 0;
> > >    }
> > >    else
> > >    {
> > >         unhandled++;  // first interrupt
> > >         interrupt_flag = 0;
> > >         while (unhandled) // handle interrupt, and others that may come in
> > >         {
> > >            do_isr_activity();
> > >            unhandled--;
> > >         }
> > >     }
> > > }
> > >
> > > Rufus
> >
> > Usually, the ISR isn't reentrant, as it disables any further
> > interrupts, so this wouldn't do anything.
> >
> > I was referring to a situation where there are many h/w interrupts, but
> > where it was okay to occasionally miss one, for instance if the
> > peripheral has a FIFO.
> >
> > If every interrupt is important, the OP needs to make sure the ISR is
> > finished before the next interrupt is received.
>
>
>
> Thx for all your replies which have given some enough ideas.
> I do agree on this method/idea of coding change for nested hardware
> interrupts .
>
> ISR()
>  {
>    if( interrupt_flag )
>    {
>       interrupt_flag = 0;
>       do_isr_activity();
>    }
> }
>
> How do you say that there is a possibility of missing an interrupt
> ocassionaly.
> I do not find flaw in the above idea ? Do i miss anything ?

It is possible to miss an interrupt, if the hardware generates them
faster than you can handle them in software.

> I would like to clarify that i am talking about nested interrupts .
>
> But, Is the above method very suitable for handling some 121 software
> interrupts ?
> (Nested interrupts)

Can you tell more about what you're doing ? Are you talking about 121
different interrupt sources ? Or perhaps a few sources, but 121
different actions ? Either way, that seems like an awful lot.

"karthikbg" <karthik.balaguru@lntinfotech.com> wrote in message 
news:1166155013.748187.161490@16g2000cwy.googlegroups.com...
>
> I am interested in knowing the interrupt-latency "double-bounce" case
> and the
> performance conditions w.r.t it.
> Kindly share some links/docs/ideas regarding that.

Most but not all systems that have sources of interrupt have a 
characteristic minimum spacing between assertion of each interrupt.  For a 
communication peripheral, this might be the minimum spacing between the 
arrival of characters, data packets, CAN messages, etc.

Similarly, these systems tend to have the possibility that the interrupt can 
occur at the maximum rate indefinitely.

The system typically has to be designed so that if an interrupt is asserted, 
the ISR begins to run in time to avoid losing data.  For most types of 
peripherals (UARTS, etc.), this means that critical sections plus 
higher-priority interrupts can't add up to more than (for example) one or 
two received characters (depending on how deeply buffered the UART is).

Additonally, the ISR typically has to "consume" at a faster rate than the 
interrupt source can "produce".

What this means in practice is that it is fairly rare to have a system where 
repeating the ISR body more than once or twice has an effect on performance. 
If the system meets its real-time constraints to begin with (specifically, 
interrupt latency), then when the ISR begins to run, there can't be more 
than one or two characters queued up (in the case of a UART).  If such a 
scenario were possible, it contradicts a prudent real-time design.

There are exceptions, of course.  A _deeply_ buffered peripheral violates 
this rule of thumb.  This allows for a large interrupt latency.

For most ISRs, something like the following (a single repetition) will do.

ISR ()
   {
   if (INTERRUPT_FLAG = 1)
      {
      INTERRUPT_FLAG = 0;
      DO_ISR_ACTIVITY();
      }

   if (INTERRUPT_FLAG = 1)
      {
      INTERRUPT_FLAG = 0;
      DO_ISR_ACTIVITY();
      }
   }

This is, of course, not an immutable rule--just a practical tendency.  There 
are some very substantial exceptions.

Dave.