[ECOS] how to handle missed interrupt issue?

[ECOS] how to handle missed interrupt issue?

[Dave Milter]

Hello.

Some days ago I started development of ecos's driver for some device
which compatible with ARINC 429.
Processor is belong to ARM9 family, freq is 200Mhz.

The logic is simple. Driver has circular buffer, and when it receive
from device interrupt, which means that it ready
to go, driver send to device next 32bit word, then it recieves next
interrupt and send next word and so on.
When driver sends all characters from circular buffer, it start from
begining of buffer.

Now I want implement function to change circular buffer pointer,
but if I do such simple thing:
cyg_drv_isr_lock()
change pointer
cyg_drv_isr_unlock()

there is probability that I lost interrupt between cyg_drv_isr_lock()
and cyg_drv_isr_unlock(),
and this of cause a problem, I willl wait interrupt and it never happens.

I imagine such scheme:

isr handler each time call dsr handler (via return value),
dsr signal via condition variable about interrupt,

when I want to change pointer to circular buffer, I do
wait on condition variable, and then disable interrupt, change my
pointer and enable interrupt.

This will works, because of maximum bit rate  of ARINC 429 is 100Kb/s, and
before next interrupt I have many time to disable/enable interrupts.

But may be there is more clever way to handle such case?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] how to handle missed interrupt issue?

[Andrew Lunn]

> Now I want implement function to change circular buffer pointer,
> but if I do such simple thing:
> cyg_drv_isr_lock()
> change pointer
> cyg_drv_isr_unlock()
> 
> there is probability that I lost interrupt between cyg_drv_isr_lock()
> and cyg_drv_isr_unlock(),

You should not loose the interrupt. The interrupt controller will
still capture the interrupt during the period interrupts are
disabled. Once interrupts are enabled again you then get the
interrupt. 

The only problem you have is if more than one interrupt occurs from
the same device during the time interrupts are disabled. After
interrupts are enabled again you only get one interrupt from the
interrupt controller. 

          Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] how to handle missed interrupt issue?

[Nick Garnett]

Dave Milter <davemilter@gmail.com> writes:

> Hello.
> 
> Some days ago I started development of ecos's driver for some device
> which compatible with ARINC 429.
> Processor is belong to ARM9 family, freq is 200Mhz.
> 
> The logic is simple. Driver has circular buffer, and when it receive
> from device interrupt, which means that it ready
> to go, driver send to device next 32bit word, then it recieves next
> interrupt and send next word and so on.
> When driver sends all characters from circular buffer, it start from
> begining of buffer.
> 
> Now I want implement function to change circular buffer pointer,
> but if I do such simple thing:
> cyg_drv_isr_lock()
> change pointer
> cyg_drv_isr_unlock()
> 
> there is probability that I lost interrupt between cyg_drv_isr_lock()
> and cyg_drv_isr_unlock(),
> and this of cause a problem, I willl wait interrupt and it never happens.

You shouldn't lose any interrupts, the interrupt controller will
remember that the interrupt occurred and deliver it when interrupts
are unmasked. The worst that will happen is that the interrupt will be
delivered slightly late. What you propose above should work just fine.


-- 
Nick Garnett                                        eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com        The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales:                          Reg No: 4422071
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] how to handle missed interrupt issue?

[alys]

If one interrupt is "pending"(waits for enabling interrupts), and next
occurs, somewhere in status register should be a flag - interrupt
overflow.
If it is set - you have interrupts lost. So you can check this flag and
have a fun.
Best regards.
Alys.

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
> Sent: Thursday, February 05, 2009 6:00 PM
> To: Dave Milter
> Cc: ecos-discuss@sourceware.org
> Subject: Re: [ECOS] how to handle missed interrupt issue?
> 
> > Now I want implement function to change circular buffer pointer,
> > but if I do such simple thing:
> > cyg_drv_isr_lock()
> > change pointer
> > cyg_drv_isr_unlock()
> >
> > there is probability that I lost interrupt between
cyg_drv_isr_lock()
> > and cyg_drv_isr_unlock(),
> 
> You should not loose the interrupt. The interrupt controller will
> still capture the interrupt during the period interrupts are
> disabled. Once interrupts are enabled again you then get the
> interrupt.
> 
> The only problem you have is if more than one interrupt occurs from
> the same device during the time interrupts are disabled. After
> interrupts are enabled again you only get one interrupt from the
> interrupt controller.
> 
>           Andrew
> 
> --
> Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] how to handle missed interrupt issue?

[alys]

If you are waiting some external event, and it could never happens by
some reason - you must have timeout for you wait. And handle the timeout
case.  Else you could hang your system if you cable is broken(for
example).

Best regards.
Alys.


> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Dave Milter
> Sent: Thursday, February 05, 2009 5:51 PM
> To: ecos-discuss@sourceware.org
> Subject: [ECOS] how to handle missed interrupt issue?
> 
... 
> there is probability that I lost interrupt between cyg_drv_isr_lock()
> and cyg_drv_isr_unlock(),
> and this of cause a problem, I willl wait interrupt and it never
happens.
...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] how to handle missed interrupt issue?

[Paul D. DeRocco]

@ix.netcom.com
> From: Dave Milter
>
> Some days ago I started development of ecos's driver for some device
> which compatible with ARINC 429.
> Processor is belong to ARM9 family, freq is 200Mhz.
>
> The logic is simple. Driver has circular buffer, and when it receive
> from device interrupt, which means that it ready
> to go, driver send to device next 32bit word, then it recieves next
> interrupt and send next word and so on.
> When driver sends all characters from circular buffer, it start from
> begining of buffer.
>
> Now I want implement function to change circular buffer pointer,
> but if I do such simple thing:
> cyg_drv_isr_lock()
> change pointer
> cyg_drv_isr_unlock()
>
> there is probability that I lost interrupt between cyg_drv_isr_lock()
> and cyg_drv_isr_unlock(),
> and this of cause a problem, I willl wait interrupt and it never happens.
>
> I imagine such scheme:
>
> isr handler each time call dsr handler (via return value),
> dsr signal via condition variable about interrupt,
>
> when I want to change pointer to circular buffer, I do
> wait on condition variable, and then disable interrupt, change my
> pointer and enable interrupt.
>
> This will works, because of maximum bit rate  of ARINC 429 is 100Kb/s, and
> before next interrupt I have many time to disable/enable interrupts.
>
> But may be there is more clever way to handle such case?

This shouldn't happen. Is it possible that your interrupt source generates a
pulse, and your interrupt input is level-sensitive? That's a recipe for lost
interrupts.

I have no idea why you need to change the buffer pointer, but one
alternative is to have the interrupt handler do that for you, in response to
setting some request flag in the application.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] how to handle missed interrupt issue?

[Dave Milter]

On Thu, Feb 5, 2009 at 6:12 PM, Nick Garnett <nickg@ecoscentric.com> wrote:
> Dave Milter <davemilter@gmail.com> writes:
>
>> Hello.
>>
>> Some days ago I started development of ecos's driver for some device
>> which compatible with ARINC 429.
>> Processor is belong to ARM9 family, freq is 200Mhz.
>>
>> The logic is simple. Driver has circular buffer, and when it receive
>> from device interrupt, which means that it ready
>> to go, driver send to device next 32bit word, then it recieves next
>> interrupt and send next word and so on.
>> When driver sends all characters from circular buffer, it start from
>> begining of buffer.
>>
>> Now I want implement function to change circular buffer pointer,
>> but if I do such simple thing:
>> cyg_drv_isr_lock()
>> change pointer
>> cyg_drv_isr_unlock()
>>
>> there is probability that I lost interrupt between cyg_drv_isr_lock()
>> and cyg_drv_isr_unlock(),
>> and this of cause a problem, I willl wait interrupt and it never happens.
>
> You shouldn't lose any interrupts, the interrupt controller will
> remember that the interrupt occurred and deliver it when interrupts
> are unmasked. The worst that will happen is that the interrupt will be
> delivered slightly late. What you propose above should work just fine.
>
>

Thanks for reply,
property of what part of processor provide such behaviour?

arm core or interrupt controller?

I mean where I can read about it, I look at docs on arm site and at
documentation on my processor,
and nowhere this is mentioned explicity.

Or this possible by decisign, interrupt is clear by ecos in arm core,
interrupt controller still works, and it set IRQ or FIQ line in 1,
and when I reenable interrupts, interrupt is happened?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] how to handle missed interrupt issue?

[Dave Milter]

On Thu, Feb 5, 2009 at 9:29 PM, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
> @ix.netcom.com
>> From: Dave Milter
>>
>> Some days ago I started development of ecos's driver for some device
>> which compatible with ARINC 429.
>> Processor is belong to ARM9 family, freq is 200Mhz.
>>
>> The logic is simple. Driver has circular buffer, and when it receive
>> from device interrupt, which means that it ready
>> to go, driver send to device next 32bit word, then it recieves next
>> interrupt and send next word and so on.
>> When driver sends all characters from circular buffer, it start from
>> begining of buffer.
>>
>> Now I want implement function to change circular buffer pointer,
>> but if I do such simple thing:
>> cyg_drv_isr_lock()
>> change pointer
>> cyg_drv_isr_unlock()
>>
>> there is probability that I lost interrupt between cyg_drv_isr_lock()
>> and cyg_drv_isr_unlock(),
>> and this of cause a problem, I willl wait interrupt and it never happens.
>>
>> I imagine such scheme:
>>
>> isr handler each time call dsr handler (via return value),
>> dsr signal via condition variable about interrupt,
>>
>> when I want to change pointer to circular buffer, I do
>> wait on condition variable, and then disable interrupt, change my
>> pointer and enable interrupt.
>>
>> This will works, because of maximum bit rate  of ARINC 429 is 100Kb/s, and
>> before next interrupt I have many time to disable/enable interrupts.
>>
>> But may be there is more clever way to handle such case?
>
> This shouldn't happen. Is it possible that your interrupt source generates a
> pulse, and your interrupt input is level-sensitive? That's a recipe for lost
> interrupts.
>
> I have no idea why you need to change the buffer pointer, but one
> alternative is to have the interrupt handler do that for you, in response to
> setting some request flag in the application.
>

you think that settting flag on arm9 is atomic thing?

I look at code atomic in linux kernel, in case of arm9 (armv5 core) it
disable interrupts
set flag and then enable interrupts.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] how to handle missed interrupt issue?

[Paul D. DeRocco]

> From: Dave Milter [mailto:davemilter@gmail.com]
>
> you think that settting flag on arm9 is atomic thing?
>
> I look at code atomic in linux kernel, in case of arm9 (armv5 core) it
> disable interrupts set flag and then enable interrupts.

Unconditionally setting a byte flag is certainly atomic, on any CPU.
Incrementing a flag isn't, nor is testing it and setting, which means that
these things can only be done by something that isn't interruptible.

If the application stores 1 in a byte, the interrupt handler can safely test
and set it back to 0 it at the beginning. This should work even in an SMP
environment, because only one CPU will run the interrupt handler at a time.

Whether this solves the original problem, I have no idea.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss