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

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.

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

"FreeRTOS.org" <n...@hotmail.con> wrote in message 
news:hxfgh.16138$k...@text.news.blueyonder.co.uk...
>
> "Rufus V. Smith" <n...@nospam.com> wrote in message 
> news:45817976$0$20219$8...@news.teranews.com...
>>
>> "Arlet" <usenet+5...@ladybug.xs4all.nl> wrote in message 
>> news:1...@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.

"Arlet" <usenet+5...@ladybug.xs4all.nl> wrote in message 
news:1...@j72g2000cwa.googlegroups.com...
>
> Rufus V. Smith wrote:
>
>> "Arlet" <usenet+5...@ladybug.xs4all.nl> wrote in message
>> news:1...@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